Introduction to Immutable Infrastructure

Immutable infrastructure has gained immense popularity in the last few years, particularly in the cloud native realm—and deservedly so. Immutable infrastructure is dramatically changing the way software is shipped, built, and managed, speeding up development releases. Let’s take a look at immutable infrastructure, including how it compares to mutable (traditional) infrastructure, and how its benefits make it less a trend and more a new standard for software deployment.

Mutable infrastructure: an overview

In order to understand immutable infrastructure, let’s step back and explore mutable infrastructures. This is, until recently, how ops teams handled infrastructure.

“Mutable” is defined as anything that’s capable of being changed. So, mutual infrastructure is capable of being changed when needed. Traditional, or mutable, servers are servers that are continually updated and modified in place. Systems engineers and admins spent time secure shelling (SSH) into servers, upgrading/downgrading packages manually, and tweaking configuration files as needed, server by server. These servers required dozens of logins and accounts, could be in any state of repair or disrepair, and managed software with updates that might succeed—or fail.

With my systems engineering background, I remember the days of installing a server: I’d order a Dell server, wait a couple weeks for arrival, provision the server over a few days, then take it to the data center to rack. This process took a lot of time—and for only a single server. Now, imagine doing this for multiple servers! Of course, the server work is not done: you must patch weekly to ensure that servers are updated during production.

There are a lot of problems with this approach. These ongoing changes mean it’s nearly impossible to have identical servers in a cluster-like environment, particularly after deployment. Further, there are no fast and effective ways to replace an existing server with something identical in case of issues.

To solve the problems of mutable infrastructure, infrastructure-as-code tools like Chef were created to get servers up-to-date quickly. Still, drifts in configuration could create a debugging nightmare when things go wrong in production.

What is immutable infrastructure?

Recently, the emergence of cloud services has given rise to immutable infrastructure. Immutable infrastructure refers to servers (or VMs) that are never modified after deployment. With an immutable infrastructure paradigm, servers work differently. We no longer want to update in-place servers. Instead, we want to ensure that a deployed server will remain intact, with no changes made.

When you do need to update your server, you’ll replace it with a new version. For any updates, fixes, or modifications, you’ll:

• Build a new server from a common image, with appropriate changes, packages, and services included
• Provision the new server to replace the old one
• Validate the server
• Decommission the old server

Every update (environment) is exact, versioned, timestamped, and redeployed. The previous servers are still available if you need to roll back your environment. This change almost entirely removes troubleshooting for broken instances, and these new servers are quick to deploy thanks to OS-level virtualization.

So, immutable infrastructure can speed up deployment, but is the actual performance enhanced? Generally, yes. Performance on an individual instance can occasionally be slower than a mutable server, but it’s rare. Importantly, horizontal scaling is significantly easier, supporting quicker environment building with both more machines and speedier deployments.