Immutable Infrastructure: what is it?

A pattern or strategy for managing services in which infrastructure is divided into “data” and “everything else”

If you haven’t read our first post Immutable Infrastructure: 6 questions to 6 experts containing the context and the full highlights of our little Q&A with 6 experts I suggest you do that first. Also remember you can always download the full 14-page PDF with the full transcript at the bottom of this page.

So what is an Immutable Infrastructure?

“A pattern or strategy for managing services in which infrastructure is divided into “data” and “everything else”. “Everything else” components are replaced at every deployment, with changes made only by modifying a versioned definition, rather than being updated in-place.”

Kief: I see it as conceptually dividing your infrastructure into “data” and “everything else”. Data is the stuff that’s created and modified by the services you’re providing. The elements of your infrastructure that aren’t managed by the services can be treated as immutable: you build them, use them, but don’t make changes to them. If you need to change an infrastructure element, you build a new one and replace the old one.

Andrew: To me, II describes a pattern or strategy for managing services in which changes (patches, application upgrades, configuration changes etc.) are made only by modifying a versioned service definition and updating running services instances to the new definition version. This as opposed to making changes to running instances directly.

Florian: Immutable infrastructure is comprised of immutable components that are replaced for every deployment, rather than being updated in-place. Those components are started from a common image that is built once per deployment and can be tested and validated. The common image can be built through automation, but doesn’t have to be. Immutability is independent of any tool or workflow for building the images.
Its best use case is in a cloud or virtualized environment. While it’s possible in non-virtualized environments, the benefit doesn’t outweigh the effort.

Julian: Immutable infrastructure to me basically means, “build once, run once”. After that, you never mutate the running system; changes require a rebuild. Although containerization (e.g. Docker) is an example of immutable infrastructure, it’s not the only possibility. Companies like Netflix that deploy by creating fresh AMIs and blowing away machines running the old one can also be considered to be using “immutable infrastructure”.
If you’ve ever been a Java application developer, the WAR or EAR that Maven generates for you can also be considered “immutable”; it’s a runnable artifact. If you want to make changes to the application, you update the Java source code, recompile into classes, and get a new deployable artifact. That’s the general idea.

Matthew: The drive behind Immutable Infrastructure is to configure and test infrastructure *before* it is deployed in place to a Production environment, rather than using in-place configuration. Think using Chef Zero or masterless Puppet to generate versioned templates or configuration sets which are then ‘flowed down’ the deployment pipeline. The goal is to increase test coverage up front and to try to avoid side-effects or accidental misconfigurations such as an in-place upgrade of Ruby or npm packages.

Ben: Server configuration is a one-off event when a server is first provisioned. After that the configuration is never updated — the only thing that changes on the server is application data. When the configuration needs to change, the server is discarded and replaced with another freshly built one.

Full transcript PDF

Download the free, 14-page PDF that includes both the highlights and the full transcript of all the answers grouped by questions here:

Your Email (optional*)

*only if you want to receive updates on the topic