Ever had to SSH into a production server to manually copy over files, or to run a command? Palms sweaty and shaking. You don’t know what the outcome of the update will be, and if something goes wrong the system could go down? If you haven’t, you’re one of the lucky ones!
Making manual changes onto an existing server means you’re likely operating with “mutable infrastructure” — whether you know it or not. But, there is another way. And that’s immutable infrastructure. And today we’re discussing exactly that, what immutable infrastructure is, the benefits and the tools you can use to implement it.
By the end of this article you’ll have a clear understanding of what immutable infrastructure is and why it’s important, the pro’s, con’s and trade offs.
Let’s begin with a definition…
Immutable infrastructure is an architectural paradigm applied to software servers and operations. When a software server requires an update as part of a code release or operating systems patch, servers are re-created from scratch rather than being modified in-place.
I know definitions can be dry — so let’s break the concept of Immutable Infrastructure down. Let’s start by looking at the anti-thesis, mutable infrastructure.
Mutable infrastructure originates from a pre-cloud era.
In the pre-cloud era, it was very common for companies to run their workloads within their own data centres. In a data centre, deploying by using a new server, and swapping over with an existing server wasn’t a viable option. Because to do so, the company would need multiple physical copies of their hardware.
Rather than run two servers, to make life simpler an individual, typically a system administrator, would log onto a running server and manually update it. And over time the system would be evolve with each update that’s applied. As time passes, more and more updates are added and the server becomes more and more unique.
But then cloud software changed everything…
Remember the problem about needing multiple bits of hardware? For those companies who started operating in the cloud, that problem went away.
With on-demand servers in the cloud, a new server can be used temporarily to load up a new change, before it is swapped with the running server. And then the old one can be shut down to save unnecessary cost. But whilst many companies did move to the cloud, so too did their old data centre oriented practices.
Does the mutable infrastructure pattern sound similar to you? If it does let’s take a look at the benefits of immutable infrastructure as it might be a pattern that you want to adopt.
Mutable software struggles to maintain a paper trail of how it got to its current state. The only one that knows is the system administrator, and it’s likely they can’t even remember what they did.
A company that operates immutable infrastructure will benefit from increases in traceability. It’s possible to know the steps that a server went through in order to get to it’s current state, usually through implementing infrastructure as code and storing those steps in version control.
Better understanding of how servers got to their current state makes it easier for new joiners to learn your infrastructure and to mitigate the risk of having the omniscient system administrator leaving and taking their knowledge with them.
If you are new to Infrastructure As Code, check out this article: Infrastructure As Code: A Quick And Simple Explanation.
Immutable infrastructure can help mitigate risk. It’s important for our businesses to be able to deploy quickly to release new features or changes when needed. But each time we release our software the risk of breaking existing code is tested.
With immutable infrastructure it’s easier to build replica environments for testing changes prior to release. Test environments are more likely to represent the running production servers and therefore will create higher confidence in release success.
To allow immutable infrastructure, servers need to be stateless. Why? Because managing state across two machine as you delicately swap one for the other is made infinitely harder by state. Instead state should be pushed out to some shared persistent storage that allows multiple servers to re-use it.
And because of the focus on stateless, immutable infrastructure is usually easier to scale implementing horizontal scaling. Horizontal scaling is the practice of adding more servers to cope with increases in load. Horizontal scaling is often preferable to vertical as it means you can scale only the parts of your system you require, rather than everything.
Okay, so far the article has been quite abstract. We’ve talked a lot about the outcomes of immutable infrastructure, but not how to implement it.
So let’s do that now, and explore some of the different tools we can use to help implement immutable infrastructure.
Docker is a tool for creating software containers. One of the main advantages of containers is having the Dockerfile which details the steps taken in order to create the running artifact. Rather than updating an existing container, you’d update the Dockerfile and create a new image. Images can then be swapped out with running containers to achieve immutability.
Similar to Docker, Packer is a tool that allows you to easily create machine images from a template. Whilst Docker allows you to package up a container, packer allows you to create images for the machines that run your applications (which can include Docker).
Terraform is an infrastructure as code tool. Whilst the tool is agnostic to whether you do or do not perform updates on the provisioned servers via an immutable infrastructure paradigm, the declarative nature of Terraform lends itself to an Immutable infrastructure paradigm.
If you’re not already a Terraform fanatic, check out this article to find out why you’re missing out: 5 Important Reasons To Learn Terraform Before Cloud Computing.
Or if you’re already keen on the idea of Terraform be sure to check out the article: Learn The 6 Fundamentals Of Terraform — In Less Than 20 Minutes
Immutable infrastructure is a fairly simple concept on paper. Rather than updating servers in place, we create new copies and releasing those new ones.
With immutable infrastructure we reduce the chance that servers become undocumented and unknown, we reduce risk in deployment and increase the speed of our on-boarding.
If your company is operating with mutable practices, it might be worth experimenting with some of the tools above to see what benefits you can reap if you move away from the pattern of mutability.
Speak soon Cloud Native friend!
Lou is the editor of The Cloud Native Software Engineering Newsletter a Newsletter dedicated to making Cloud Software Engineering easier, every 2 weeks you get news and articles that cover the fundamental topics of Cloud Native in your inbox.