The Old Way: Mutable Infrastructure
Imagine you have a beloved houseplant named "Fern." When Fern gets sick, you diagnose the problem, adjust the watering schedule, add fertilizer, and nurse it back to health. You would never throw Fern away and buy a new one — Fern is irreplaceable. For decades, managing servers worked exactly this way. Servers had names like zeus or apollo, and when they broke, engineers logged in, diagnosed the problem, and applied fixes by hand.
The technical term for this pattern is mutable infrastructure — infrastructure that is modified in place after it is deployed. Over time, this creates a serious problem called configuration drift. Server A gets a security patch on Monday. Server B gets a different patch on Wednesday. A week later, both servers are supposed to be identical web servers, but they have subtly different configurations. One works fine; the other fails mysteriously at 2 AM. Debugging drift is notoriously difficult because the differences are often invisible until something breaks.
The New Way: Immutable Infrastructure
Immutable infrastructure treats servers like cattle, not pets. You do not name them, you do not nurse them, and you do not modify them after deployment. If a server needs a change — a security patch, a new application version, a configuration update — you build a brand new server image with the change baked in, deploy new servers from that image, and terminate the old ones. The running servers are never touched.
The word immutable comes from mathematics and means "cannot be changed." Once a server is deployed from an image, it is frozen. This guarantee is what makes the pattern powerful: every server running version 1.4.2 of your application is byte-for-byte identical to every other server running 1.4.2. There is no drift, no snowflake servers, and no "works on my server" debugging sessions.
In practice, this workflow looks like:
- A developer merges a code change.
- A CI/CD pipeline builds a new machine image with the updated application baked in.
- The pipeline deploys new servers from the new image.
- Traffic is shifted to the new servers (blue/green or rolling).
- Old servers are terminated.
Interviewers often ask: "What is configuration drift and how do you prevent it?" A weak answer defines drift but stops there. A strong answer explains that drift is the inevitable divergence of server state from its intended configuration when servers are modified in place — and that the architectural solution is immutable infrastructure, where servers are replaced rather than modified, making drift structurally impossible rather than just monitored.
Key Point: Immutable infrastructure eliminates configuration drift by treating servers as disposable artifacts. The unit of change is the image, not the running server. This shifts operational complexity from "how do we safely modify live systems?" to "how do we build and ship images reliably?" — a much more tractable problem.