Immutable Infrastructure

The core tenet of immutable infrastructure is the absolute prohibition of changes to a running server. Once a component is deployed, its configuration, application code, and operating system are frozen. This means no SSH access, no configuration management agent runs, and no manual hotfixes. If a change is required, a new artifact is built and deployed, ensuring that the running state always matches a known, version-controlled definition. This directly eliminates the configuration drift that plagues long-lived, mutable servers.

Immutable infrastructure relies on pre-built, machine-readable images (e.g., Amazon Machine Images, Docker containers, or OCI-compliant images) as the single source of truth. These images are created via an automated pipeline, often using tools like Packer or Docker Build. The provisioning process involves instantiating a new resource from this golden image, applying runtime-specific parameters (like IP addresses) through environment variables or a metadata service, and then registering it with a load balancer. This guarantees that every instance of a service is identical.

Components in an immutable infrastructure are treated as cattle, not pets. They are designed to be ephemeral and disposable. When a new version is deployed, the old instances are simply terminated. This disposability forces a design where state is strictly externalized to persistent data stores (databases, object storage). The application tier becomes stateless, enabling seamless horizontal scaling, self-healing, and zero-downtime deployments through strategies like blue-green or canary rollouts.

The entire lifecycle of immutable infrastructure is managed declaratively through Infrastructure as Code (IaC) . Tools like Terraform, Pulumi, or CloudFormation define the desired state of the infrastructure. A reconciliation loop continuously compares the declared state with the actual state, automatically creating or destroying resources to correct any divergence. This automation extends to Day 2 operations, where scaling events trigger the provisioning of new, identical instances rather than modifying existing ones.

Rolling back a failed deployment is a simple, low-risk operation. Because the old version's artifacts are never overwritten, a rollback involves pointing the traffic router back to the previous, known-good version of the infrastructure. This is an atomic operation with no complex database schema downgrades or configuration reversals. The failed version is simply decommissioned, leaving no residual artifacts. This pattern is fundamental to Continuous Deployment (CD) pipelines, enabling high-velocity release cycles with minimal risk.

The contrast between the two paradigms is stark:

• Mutable (Traditional): Servers are long-lived, updated in-place via SSH and configuration management tools (Ansible, Puppet). This leads to configuration drift, where each server becomes a unique snowflake, making disaster recovery and scaling unpredictable.
• Immutable (Modern): Servers are never changed; they are replaced. This guarantees idempotency and consistency across all environments. Debugging is simplified because the exact build artifact can be reproduced locally, eliminating the "works on my machine" problem.