Immutable Infrastructure: Treat Servers Like Cattle, Not Pets

WHY IT EXISTS: To solve the problem of 'configuration drift.' In traditional, mutable infrastructure, servers are updated and modified in place over their lifetime. These manual changes accumulate, making each server slightly different and impossible to reproduce reliably. This leads to deployment failures, security holes, and 'it works on my machine' bugs.

THE MENTAL MODEL: Treat your servers like cattle, not pets. A pet server is unique, hand-raised, and nursed back to health when it's sick. A server from the 'cattle' herd is identical to others and replaced if it fails. In practice, this means you never SSH into a production instance to apply a patch. Instead, you build a new, patched server image, deploy new instances from it, and terminate the old ones.

HOW IT WORKS: The process starts by defining a server's entire configuration as code using tools like Packer or Docker. This code builds a 'golden image'—a template like an AWS AMI or a container image. When a change is needed (like an application update or OS patch), a CI/CD pipeline automatically builds a new golden image. Deployment consists of launching new servers from this new image and decommissioning the old ones, often orchestrated with tools like Kubernetes or cloud provider auto-scaling groups.

WHEN TO USE IT: This pattern is ideal for stateless applications where instances can be terminated and replaced without data loss. Think web servers, API gateways, or containerized microservices. It dramatically improves deployment reliability, simplifies rollbacks (just deploy the previous image), and makes scaling predictable and safe.

WHEN NOT TO USE IT: Immutable infrastructure is difficult to apply naively to stateful services like databases. You cannot simply terminate a primary database server without a careful data replication and failover strategy. While the underlying OS of a database server can be immutable, the data itself is, by definition, mutable and persistent. Applying this pattern without accounting for state can lead to data loss.

ONE CANONICAL EXAMPLE: A web application on an AWS Auto Scaling Group (ASG). The ASG's Launch Template points to a specific Amazon Machine Image (AMI). To deploy an update, the CI/CD pipeline uses Packer to build a new AMI with the new code. It then creates a new Launch Template version pointing to the new AMI. Finally, it updates the ASG to use the new template and initiates a rolling refresh, which gradually replaces old instances with new ones for a zero-downtime deployment.