Image for post
Image for post

DevOps Concepts: Bake vs Fry 2

Part 2: Configuration Methods during the Cloud Age

In the last article we introduced the concept of system configuration using baking and frying, and we covered ways this was applied during the Iron Age.

  • Provisioning Server Systems (frying)
  • Change Configuration (frying)
  • Application Deployments (frying)
  • Service Discovery (frying)

Previous Article

The Cloud Age

With the arrival of the Cloud Age, the entire data center was virtualized, not just the virtual machine instances, but storage and network infrastructure as well.

Provisioning Instances (Frying)

Configuring systems with virtualization on your own hardware or cloud virtualization are virtually the same. The one exception is that you can no longer use network booting for early stage provisioning. Instead, with a new virtual machine instances, you select a pre-baked image, supplied by the cloud provider, such as Debian, RedHat, or Ubuntu.

Image for post
Image for post
Frying Components on Cloud Instances
  • Mixed Approach where provisioning installs an agent (like Puppet agent or Chef client) that is later used to configure remaining components through convergence.
  • Change Configuration is used configure the whole system after launch. The system will have to use push-based remote execution to either install an agent or configure the system, like Chef Knife or Ansible.

Making Images (Baking)

Instead of the selection of images from the cloud provider, you can decide to bake your own images with tools like:

To Bake or Not to Bake?

Despite higher costs to build and maintain baked images, the costs for deployment and remediation (repairing systems) goes down dramatically when using images. The systems are disposed and replaced when they need to be upgraded or repaired, a pattern called immutable infrastructure.

Image for post
Image for post
  • Frying in Stages: illustrates four artifacts: system image, provisioning scripts, change configuration scripts, and application deployment scripts, which are all used in conjunction to support the application.

Self Healing Managed Instances

Wouldn’t it be great if we don’t have to configure the systems each time and every time? Maybe we just set them up once, and afterward, they managed themselves? Or if they fail or crash, just replace themselves?

Image for post
Image for post
Cloud Managed Groups

Cloud Provisioning (Frying)

We discussed configuring systems through baking or frying, but what about configuring the cloud itself?

Image for post
Image for post
  1. Cloud Formation (2011) for only AWS
  2. Ansible Cloud Modules (2014): AWS, Google Cloud, Azure, OpenStack, others

Service Discovery (Frying)

The previous article introduced service discovery for cluster membership or external services during the Iron Age. The application itself can query a discovery services to find other members in its set as well as external services, such as a database or message queue.

General Discovery Solutions (any cloud)

I am repeating the list from the last article. These can be implemented on any cloud platform.

  • AirBnB Smart Stack (2012): service discovery, key-value store, health checking
  • CoreOS Etcd (2013): service discovery, key-value store, events
  • Hashicorp Serf (2013): node discovery, group membership, failure detection, events
  • Hashicorp Consul (2014): service discovery, key-value store, health checking

AWS Discovery Solutions

These are two built for only AWS.

  • Cloud Map (2018): service discovery that can register resources and broadcast events on availability of those registered resources.

Cloud Metadata (Frying)

As an alternative to using service discovery, you can use cloud metadata.

Google Cloud Metadata

  • Instance Tags: list of values that can be added to an instance
  • Resource Labels: key-value pairs that serve as lightweight method to group resources together
  • Instance Metadata: information about running instance such as IP address, machine type, zone, networks, and other information.
  • Project Metadata: grants applications shared environment variables and configs that can be accessed securely.

Azure Metadata

AWS Metadata

Disposability Patterns

With all these technologies and methods, there comes the question to how to go about managing systems, from single systems to fleets of systems?

Pets vs. Cattle

In the pets vs cattle centers around instances that are managed group (cattle) or managed as single instances (pets). When managed as a group, the instances are replaceable, but when managed individually, they are irreplaceable.

Snowflake Server vs. Pheonix Server

In snowflake server vs pheonix server concept centers are around configuration drift and disposibility of instances.

Combining the Concepts

The illustration below shows the two concepts combined and illustrates whether baking or frying are applicable.

Image for post
Image for post
Image for post
Image for post

Conclusion

In the Cloud Age, we saw further virtualization of all resources besides instances of virtual servers, and new opportunities for automation, using infrastructure as code to not only configure components in the operating system, but for components in the cloud, such as networks and storage.

References

Immutable Infrastructure

Infrastructure as Code (IaC)

Pheonix vs. Snowflake

Google Cloud Topics

AWS Topics

Written by

Linux NinjaPants Automation Engineering Mutant — exploring DevOps, Kubernetes, CNI, IAC

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store