Immutable Infrastructure

Server A was set up in January. In March, someone SSHed in and installed a debugging tool. In May, a hotfix was applied directly in production. In August, a config file was edited by hand. By December, server A is a unique snowflake, its state is the cumulative result of months of ad-hoc changes, and nobody can reproduce it.

Now server A crashes. You try to rebuild it. The new server doesn't work the same way. Some package version is different. The config file edit is missing. The debugging tool that someone forgot they installed had a side effect that the app depends on. You spend days reconstructing the snowflake.

Immutable infrastructure eliminates this. Instead of modifying running servers, you never touch them. Every change, every security patch, configuration update, and code deployment, produces a new server image. The old servers are destroyed and replaced with new ones built from the updated image. Every server in production is identical, reproducible, and disposable.

Containers are immutable infrastructure by default. You don't SSH into a container and edit files. You build a new image with the change and deploy it. The old container is killed and replaced. This is why containers and immutable infrastructure go hand in hand.

The immutable workflow:

1. Code change merged to main
2. CI builds a new container image (or VM image)
3. Image is tested in staging
4. New image replaces old image in production
5. Old instances are terminated
6. If something breaks, deploy the previous image

Tools enabling immutable infrastructure: