The Benefits of Immutable Infrastructure

In case you haven’t seen it, my first post outlined Immutable Infrastructure, which stems from the use of container technology. The TL;DR (too long; didn’t read) is that Immutable Infrastructure does not change significantly from its initial deployment. Some minor configuration changes are stored in the state of the infrastructure, but the underlying operating system and application are not patched or upgraded. Which leads me to the first major benefit of Immutable Infrastructure.

No more in-place patching and updating

In some ways, you may already do this. When it’s time to upgrade an ESXi host, my usual process is to reinstall ESXi on the hardware with the latest available version. If you happen to be using VMware auto-deploy, you are literally redeploying an immutable copy of ESXi each time a system boots. This means you always have a simple path to let you roll back a new version to the previous one, should things go wrong. It also forces you to store your state and configuration data in a shared repository, rather than on a local system. Each time a system is deployed, it pulls its configuration data from the store and coalesces it with an immutable image to create a running instance of the application.

Simplicity of deployment

If you redeploy your operating system and application for each upgrade and patch, then you are going to get really good at deploying that environment. Hopefully, you have the whole process scripted out or automated in some other way such that the process for deploying a new version of the application will seem simple and straightforward: just run the process. Of course, under the covers the actual deployment process may be fairly complex. Once you have conquered this particular monster, the day-to-day systems operation will seem trivial by comparison. Which leads me to my next point.

Deeper understanding of applications and services

The best way to truly understand a subject is to teach it to someone else. You may think you have a firm grasp on things, but someone who lacks your level of context will quickly expose any gaps in your knowledge. Teaching a computer to do something is even harder, since it has no context for anything and will only do exactly what you ask. When attempting to automate a deployment, you are going to uncover all the assumptions an installer or GUI makes for you. Digging through the assumptions and cobbling together a working deployment will yield deep insight into the components of your application and how they interact. This knowledge is invaluable when things go wrong, as they invariably do.

Self-documenting deployment process

What you are really doing when you fully automate a deployment is creating a document of how the application should be properly deployed. Not a step-by-step Word document with pretty diagrams and process flow charts but an accurate, detailed blueprint of how your application is deployed. For most people, the scripts and configuration files alone are worth their weight in gold (unlike the unread and immediately outdated documentation you didn’t have time to write).  Even better, as the deployment process changes over time, your documentation stays in lockstep as a matter of consequence.  Well done, you deserve a reward!

Consistency of environments

How close does your Development environment mirror QA? How close is Staging to Production?  Chances are those environments have drifted apart over time. It would take a Herculean effort to bring everything back into alignment. On the other hand, deploying Immutable Infrastructure ensures that each environment is deployed and maintained at the same code and operating system level, and that variations of each environment are held within a configuration file (of some kind). Naturally, your Development environment won’t be as robustly configured as Production. Defining the differences in code can be incredibly helpful during troubleshooting. It also makes the deployment simple and consistent if you need more copies of an environment for testing.

Confidence in your ability to recover

Most organizations only test their DR once a year, if ever. More advanced organizations might test quarterly, but this is a rarity at best. The problem with disaster recovery is similar to the problem with documentation: it’s out of date before the test is even complete. Systems and applications are constantly changing, so you want to be sure that in a recovery situation you will have no trouble recreating your environment. By requiring you to constantly redeploy your environment, Immutable Infrastructure makes you really good at doing it. So good in fact, you will be stone-cold confident you can recover from any failure or disaster.

By now, I’m sure you’re feeling super pumped about Immutable Infrastructure. You probably want to know what magical tools people use to accomplish such amazing feats. Fret not, dear reader! The next post will cover some of the more common toolsets, and will explain how they might fit into your own environment.