By Jason Bloomberg
This content is brought to you by Evolven. Evolven Change Analytics is a unique AIOps solution that tracks and analyzes all actual changes carried out in the enterprise cloud environment. Evolven helps leading enterprises cut the number of incidents, slash troubleshoot time, and eliminate unauthorized changes. Learn more
Immutable infrastructure is a core tenet of DevOps. Instead of configuring environments manually, the story goes, we represent them as a manifest or some other declarative representation.
Our DevOps tooling is then able to build the entire environment from scratch simply by following the manifest – and furthermore, every time we provision an environment, it turns out exactly the same as every other time.
At least, that’s a high-level picture of how the ‘cattle, not pets’ theory of immutable infrastructure is supposed to work. Look more closely, however, and cracks soon develop in its seamless façade.
A Proliferation of Environments
There are many reasons why supposedly identical environments aren’t quite the same. The most obvious: differences among dev, test, staging, and production environments.
Ideally, the code we place in each environment is identical to the others, but there will necessarily be differences in infrastructure – differences that subtly impact the code we write.
The second problem: just because an environment’s infrastructure is immutable doesn’t mean it never changes. ‘Immutability’ in this context means that we make changes by reprovisioning – but there are several reasons why we might want to do just that.
For example, we may want to tweak our manifest and reprovision to account to include a security patch or an updated version of a library or any number of other reasons.
If we were working alone, these updates might not be a problem – but what if we’re in a large organization with multiple development teams working in parallel? One team may want to reprovision an environment unbeknownst to other teams – or even if they know what’s going on, they may not be ready for the new library or patched software.
We may also have a situation where we have multiple supposedly identical environments for horizontal scalability purposes, either as part of a traditional autoscaling group, or in order to support clustering. In either situation, we want to avoid drift – the fact that patches or other small changes can bring supposedly identical environments into an inconsistent state.
