DevOps Concepts: Bake vs Fry
Methods for Provisioning and Configuring Infrastructure
When searching for the “bake vs fry” concept in DevOps, you might stumble upon a lot of culinary references — especially if you include the change configuration platform “Chef” in your search. Though this concept has been around for a long time, it has unfortunately fallen off the radar in many search results.
In DevOps, “bake vs fry” describes two different approaches to system setup. “Bake” refers to the practice of building everything into an image beforehand — essentially, preparing a fully configured, ready-to-deploy system image. On the other hand, “fry” refers to configuring the system after it has been deployed (or during deployment), allowing for more flexibility and on-the-fly adjustments.
This concept has evolved through different technological eras — from the Iron Age of bare metal, rack-mounted servers, to the Cloud Age, where virtualized servers can be quickly spun up and configured through a web console or API.
📓 **SEGUE**: This "bake vs fry" concept isn't limited to infrastructure alone;
it also applies to other contexts, such as website rendering. In this context,
"bake" refers to static sites, where the content is pre-rendered and
delivered as-is to users. On the other hand, "frying" involves using
templates to dynamically generate pages on the fly, allowing for real-time
customization and updates.The Iron Age
During the Iron Age of server systems, the “fry” method was the standard approach to configuration. Administrators used tools like Kickstart (introduced in 1999) to automate the installation and initial setup of systems. As the need for more sophisticated management grew, managed change configuration platforms like CFEngine (1993), Puppet (2005), and Chef (2009) became essential for maintaining consistency and control over server environments.
The Cloud Age
As we moved from the Iron Age of computing into the Cloud Age, virtualization technologies advanced, leading to the rise of robust automation. This made the “bake” method — creating pre-configured images — more popular. However, the “fry” method remained dominant, especially with the advent of change configuration tools that supported remote execution, such as Salt Stack (2011) and Ansible (2012).
One of the challenges in adopting the “bake” method is the so-called golden image problem. This issue arises when organizations need to maintain a library of images tailored to different server configurations, each containing various software versions. The complexity of managing these images can become overwhelming, making the “fry” method an attractive alternative for its flexibility and ease of updating.
The Arrival of Containerization
Linux introduced new features that enabled the segregation of system resources without the need for full virtualization. This gave rise to the container revolution with toolchains like Docker (2013) and LXC (2014).
Docker revolutionized system configuration by introducing a layered imaging approach within its toolchain. This method allows for the creation of images without the typical challenges of the golden image problem, as each layer can independently contain different configurations and software components, each identified by a unique digest code. This innovation made the “bake” method significantly more manageable.
With these advancements, building images became significantly easier using tools like Docker (2013) and Packer (2013). As a result, the “bake” method became increasingly popular for creating container images. This shift also led to the widespread practice of building system images for virtualization environments that contained just enough to run the container solution efficiently.
Immutable or Mutable Infrastructure?
Immutable infrastructure is “a model that mandates no updates, security patches, or configuration changes occur in place on production workloads”. When a change is needed, the existing workloads are destroyed and redeployed with a new, updated workload that includes the desired configuration changes.
At first glance, this might seem to imply that only the “bake” method is used, but that’s not always the case. Configuration often occurs during deployment, even within an immutable infrastructure model.
Configuration can occur at various stages:
- Build time (“bake”): Configuration is embedded into the image itself. Applications may fetch additional configuration from a remote key-value (K/V) database. This approach aligns with the principles of immutable infrastructure.
- Deploy time (“fry”): Configuration is added during deployment, such as through environment variables or a mounted configuration file. This also qualifies as immutable infrastructure.
- Runtime (“fry”): Configuration changes are made after the system is deployed. This approach is characteristic of mutable infrastructure.
Conclusion
In today’s data centers, whether you manage them yourself or rely on a cloud provider, some form of “frying” is typically used to set up the baseline system and virtualization solutions like Xen (2003) or KVM (2007). This setup can be part of an IaaS management platform offered by the cloud provider, or it can be a self-managed solution, such as OpenStack (2011). Once this foundation is in place, further layers often rely on “baking” to deploy virtual machines from system images and containers from container images.
In increasingly complex environments like microservices or serverless architectures, service discovery plays a crucial role in dynamically managing and configuring workloads. Service discovery allows systems to automatically locate services and retrieve the necessary configuration data, simplifying maintenance and scalability. In these scenarios, “frying” is typically used to register the service, while the service itself is often “baked” into a ready-made image. The frying process can also be used to update an external configuration, such as a K/V database, that will be fetched by the workload.
Advanced container orchestration platforms like Kubernetes (2015) come with built-in service discovery. Similarly, tools like Consul (2014) extend these capabilities to traditional virtualization in addition to containerized environments, offering flexible solutions for dynamic infrastructure needs.
Additionally, service mesh solutions such as Linkerd (2016) or Istio (2017) further enhance service discovery by managing service-to-service communication, adding layers of security, and ensuring reliability. These advancements empower organizations to build resilient, scalable systems capable of adapting to the ever-changing demands of modern software development.
As the DevOps landscape continues to evolve, understanding and leveraging these methods and tools will be essential for building efficient, reliable, and scalable infrastructure.
Previous Articles
Pets vs Cattle
References
General Concepts
- What is a service mesh? by Hashicorp, access on Aug 21, 2024
- Service Discovery in Microservices by Simone Cusimano, updated on May 29, 2024
- What Is Immutable Infrastructure? by Hazel Virdó (Digital Ocean) on September 25, 2017
- Deploy using immutable infrastructure from AWS documentation, accessed on Aug 21, 2024
- A guide to golden images by Joanne Yip on April 25, 2024
- What is a golden image? by Red Hat on August 31, 2022
Client Imaging
- Ghost by Wikipedia, accessed on August 21, 2024
- ghost imaging (disk imaging) by Robert Sheldon (TechTarget), accessed on August 21, 2024
Other Contexts
- Bake, Don’t Fry by Aaron Swartz on July 9, 2002.
