In the words of Kief Morris in his post on immutable infrastructure,
“Automated configuration tools (such as CFEngine, Puppet, or Chef) allow you to specify how servers should be configured, and bring new and existing machines into compliance. This helps to avoid the problem of fragile SnowflakeServers. Such tools can create PhoenixServers that can be torn down and rebuilt at will. An Immutable Server is the logical conclusion of this approach, a server that once deployed, is never modified, merely replaced with a new updated instance.” – Kief Morris, ImmutableServer
In essence, an immutable infrastructure treats its deployed components (things like EC2 instances and production code packages) as static, completely unalterable. They are essentially solid objects in the environment. Therefore change can only be introduced by tearing down these objects and replacing them (perhaps even replacing the entire environment, depending upon one’s approach) with their next iteration.
This is an approach to change
As with many things having to do with “ops”, this is obviously an approach to change. And it’s very well suited to cloud resources and containerized deployments (which together already put us in the practice of programmatically tearing down, spinning up, or otherwise manipulating objects which themselves do not require lower-level intervention such as is performed by live-running configuration management engines).
The immutable infrastructure approach is very well suited to cloud resources and containerized deployments
Instead of deploying and exploding individual code packages on existing instances, and instead of deploying new instances which are configured slowly by tools such as Puppet or Chef as they come online, and certainly instead of ssh’ing into hosts and fixing problems ad-hoc in a non-repeatable fashion, we prepare our base objects (AMIs, Docker containers, etc) and perform a blue-green deployment, canary deployment, or some other form of deployment of these objects themselves, replacing the old with the new in more or less wholesale fashion.
Immutable infrastructure seeks to reduce or eliminate configuration management requirements
In this way, everything we send into an environment, and everything we leave running in an environment, undergoes fewer changes both throughout the entire pipeline process and during actual production operation. And we reduce, possibly even eliminate entirely, the overhead of configuration management. Immutable infrastructure thus has the potential to simplify the environment (which now becomes a collection of static objects) and both speed up and simplify the deployment process (which now entails merely moving static objects which require little or no further manipulation in and of themselves) while removing a chunk of configuration management complexity (a significant moving part) from our cloud universe.
What about data? Of course, data must be accounted for and can easily be pushed off-instance into storage services such as S3, DynamoDB, and Aurora and accessed as necessary by all instances in an environment. This isn’t the hard part. The genuinely difficult aspect of immutable infrastructure is people.
Immutable infrastructure requires DevOps discipline.
By way of illustration…
I had the pleasure of leading a rather large project which embraced immutable infrastructure as one of its guiding principles and which leveraged Amazon’s Elastic Container Service (ECS) and a Dockerized continuous delivery pipeline to make it a reality. The technology and processes performed beautifully. But people are used to doing things a certain way. So various members of the team would naturally deviate back to old incompatible habits temporarily and especially while under tight deadlines. An out-of-process change here, a midnight tweak there. It sometimes felt like 2 steps forward, 1 step back to reach our goal while the team wrapped its head and its daily practices around the new approach. After all, this approach requires a discarding of old “ops” habits, as any change introduced into a truly immutable environment is bound to be wiped away and instead must be captured and made repeatable (a hard daily practice for many…but one that is crucial if Infrastructure-as-code is truly to be adopted). The team ultimately took leaps and bounds in their knowledge of modern cloud architectures and Infrastructure-as-Code patterns, and the project was a success. But the lesson, as always, is that the key to success isn’t the technology, it’s the people. And change is hard.
There is much more to say on the topic of immutable infrastructure. Want to keep the conversation going? Leave a comment below or contact me for a chat on the topic. I’m happy to share my experiences and help in any way possible.