DevOps Concepts: Bake vs Fry

Methods for Provisioning and Configuring Infrastructure

6 min readAug 22, 2024

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.

Understanding how we got here requires looking at how our tooling evolved across three distinct eras of computing:

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 (1999) or FAI (1999) to automate the 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 into the Cloud Age, virtualization advanced, making the “bake” method, creating pre-configured images, more popular. However, the “fry” method remained dominant, especially with tools Salt Stack (2011) and Ansible (2012).

One of the challenges of “baking” virtual machines was the golden image problem, where managing a massive library of slightly different images became overwhelming, making the “fry” method an attractive alternative for its flexibility.

💡 Modern Reality: “Frying” bare metal is still the secret engine of the cloud. Hyperscalers (like Meta) and cloud platforms use tools like cloud-init (2007) or Salt Stack to fry configurations onto raw hardware before any virtual machines or container platforms can even run. Many companies still use this approach to build cost-effective, in-house bare-metal platforms for testing.

The Container Revolution: Immutable Baking

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. This allowed engineers to build images without the typical challenges of the gold image problem, as each layer can independently contain different configurations and software components, each identified by a unique cryptographic digest. 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 skyrocketed in popularity for container images. This shift also birthed a new standard for underlying infrastructure: building minimal, stripped-down system images for virtualization environments that contain just enough operating system (JeOS) to run the container runtime 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.” — DigitalOcean

When a change is needed, existing workloads are destroyed and redeployed with a new, updated workload containing the desired changes.

At first glance, this might seem to imply that only the “bake” method is used, but that’s not the case. Configuration often occurs during deployment, even within an immutable infrastructure model.

We can categorize configuration into three distinct 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 aligns perfectly with immutable infrastructure principles.
Deploy time (“fry”): Configuration is injected during deployment, such as through environment variables or mounted configuration files. As the underlying image remains untouched, this still 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 stand up the baseline system and virtualization solutions like Xen (2003) or KVM (2007). This setup might live inside a cloud provider’s proprietary IaaS engine, or within a self-managed solution like OpenStack (2011). Once that foundation is in place, the higher layers of the stack rely heavily on “baking” to deploy virtual machines or containers from images.

However in highly distributed microservices or serverless architectures, static baking isn’t enough. This is where service discovery becomes critical, where such environments rely on a hybrid approach:

Baking: The core application service is frozen into a immutable container image.
Frying: Dynamic runtime frying is used to automatically register the service, update key-value databases, and locate external dependencies on the fly.

Advanced container orchestration platforms like Kubernetes (2015) handle this out of the box. Similarly, tools like Hashicorp Consul (2014) extend these dynamic capabilities to traditional virtual machines alongside containerized environments.

To take it a step further, service mesh solutions such as Linkerd (2016) or Istio (2017) act as an advanced layer of dynamic runtime configuration. Instead of forcing developers to manually program complex security, routing, and encryption logic into every single application, the service mesh handles it automatically at the platform layer. Without touching your underlying baked application code, it can dynamically enforce mutual TLS (mTLS) encryption between services, manage granular access tokens, and precisely route traffic to support advanced deployment strategies like canary rollouts or blue-green testing.

Ultimately, baking and frying are not competing ideologies; they are complementary dimensions of modern system design. Engineering successful infrastructure means knowing exactly where to draw the line between a static, predictable image and a dynamic, adaptable runtime.

Previous Article: Pets vs Cattle

DevOps Concepts: Pets vs Cattle

Operational Service Models

joachim8675309.medium.com

Next Article: Snowflake vs Phoenix

DevOps Concepts: Snowflake vs Phoenix

Summary of Snowflake vs Phoenix Server Patterns