A Brief Look at Immutable Infrastructure and Why it is Such a Quest

You’ve probably heard a thing or three about immutable infrastructure. It’s all the rage, and honestly it should be. It’s changing the paradigm in which software is shipped, built, and managed in a dramatic way. But what exactly is immutable infrastructure? Let’s talk about that for a minute, as with anything that gets popular, there are some core ideas behind it and some that are a bit more superfluous.

Immutable simply means something that is created and left unchanged. Immutable things are understood as is, without need to mutate them, and by that have no need to be mutable. Infrastructure of course is word taken from the domain of architecture and physical design of space, for our virtual realms of servers and software applications. Combined we have a created and unchanged set or piece of architecture for hosting applications.

Unchanging infrastructure might sound like the opposite of what you’d want in an agile environment.  But what it means is that once the image is working, only a working image is deployed. When it’s time to make changes a new is created, but the previous image is still available for rollback of the environment itself. The fact that we can now create exact, versioned, timestamped versions of an entire environment removes troubleshooting broken instances almost entirely. And thanks to OS-level virtualization, which is spearheading the movement for immutable infrastructure, these images are extremely fast to deploy..

Even though one might think, well, OK,  deployment is faster, but what about actual performance? In some scenarios performance on an individual instance is slower than a dedicated box, but it makes efforts to scale-out horizontally dramatically easier, providing another way to build out faster environments, not just from a faster deployment, but actually adding more machines to make processing faster.

Immutable infrastructure came into existence because of the frightening ordeal of mutable infrastructure. The real world experience of system administrators managing servers that need to have logins and accounts, managed software with mutable updates that can succeed or fail, various states of repair or disrepair, and other frustrations in traditional styles of managing infrastructure. Setting up immutable servers that are configured and setup to work once, and then only deployed as is, removes many of those issues. If a patch or update is needed, the server image is updated and a full redeployment of everything is made from an immutable context. No servers in production are patched or manipulated in a mutable way.

Continuous Integration and Delivery

Traditionally, the integration and delivery of software from a developer’s machine to a production (or at least a staging) environment has been a tedious and time consuming process. It would usually involve setup of multiple servers — sometimes virtualized, sometimes not — various scripting, often extensive efforts around all of this, and it still took hours or days. Each time a system was deployed it meant running various scripts and other applications via a manually initiated process. If integration was in play, it frequently wasn’t connected to delivery in traditional environments, and still included manual intervention to get into a production environment.

With immutable infrastructure almost everything — sometimes even including production — is disposable. The idea is it can be deployed again in a matter of minutes. Sometimes a re-deployment through a complete integration cycle and delivery might take seconds. Some of the companies taking full advantage of this process include Codeship, Snap CI, CircleCI .

Application Deployment

With the advent of continuous delivery and integration as discussed above, application deployment via immutable infrastructure has become one of the best practices of application deployment. This generally involves being able to fully script and recreate a production (or staging or UAT or other) environment in minutes. This gives the ability to rollback and push deployments to production in a matter of seconds. By proxy of building on immutable infrastructure like this it dramatically increases the ability for a team to test deployments without fear.

Summary

What immutable infrastructure provides in this space truly disrupts the way applications are deployed. The capacity to increase reliability, efficiency, and consistency within a deployed environment so that it can be recreated within minutes is invaluable. To delay will only increase the cost and time to iterate. The idea to move forward with immutability is now.