Environment Consistency: Essential for Cloud-Native Computing
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.
Solving the Environment Consistency Problem
Assuring that two or more environments are as identical as they should be is the problem of environment consistency. Sometimes the environments must be identical down to the bare metal to be consistent, but more commonly, they must be logically identical, where we have fully abstracted away any infrastructure differences that might impact the code we want to deploy.
Traditionally (that is, without containers and Kubernetes), environment consistency is difficult and complex to achieve in practice. Basically, developers must account for all possible variations manually in their ‘infrastructure as code’ recipes – which as a result become more like applications themselves than the declarative manifests that are at the heart of immutable infrastructure.
Fortunately, better automation of environment consistency is one of the built-in features of Kubernetes. Kubernetes is able to automate deployment, application scaling, and the operations of application containers across clusters. As part of this functionality, Kubernetes is able to deliver environment consistency across development, testing, and production environments.
With Kubernetes, we can build a ‘golden image’ of the Kubernetes production deployment that we can use whenever we deploy containers regardless of the environment. The result is a consistent, production-like environment, regardless of whether we’re running the dev environment on a laptop, in a single cloud instance, or across a cluster of multiple pods.
Is Kubernetes all we Need to Guarantee Environment Consistency?
Kubernetes golden images have unquestionable advantages over virtual machine (VM) images like Amazon Machine Images (AMIs). While provisioning from an AMI will provide an immutable VM-based infrastructure, Kubernetes golden images deploy the entire Kubernetes stack onto abstracted infrastructure.
As a result, the Kubernetes approach tackles the problems with environment consistency that traditional (cloud-based but non-Kubernetes) approaches cannot.
The obvious question then is whether Kubernetes solves all of our Kubernetes problems. The answer: probably not. Even if we’re running a fully Kubernetes-centric cloud-native infrastructure, there are still situations where Kubernetes environments may experience drift or other issues that impact consistency.
Remember that Kubernetes and its ecosystem are still relatively immature, and thus the various open source project teams are rapidly innovating the core infrastructure code.
Even when Kubernetes matures, however, environment consistency can still be a challenge, largely because the assumption that our cloud-native infrastructure is fully Kubernetes-centric is unlikely to be true.
The reality for most (if not all) enterprises is that Kubernetes will never account for the sum total of all corporate IT infrastructure. In reality, hybrid IT – an intentional mix of cloud and on-premises infrastructure – will likely remain an enterprise reality for many years to come.
Environment Consistency in Practice
Cloud-native computing brings the best practices of the cloud to all of enterprise IT, including the way Kubernetes handles environment consistency. But observability-based management is also a fundamental enabler of cloud-native computing as well.
Cloud-native observability goes well beyond familiar monitoring dashboards to interactive controls that empower operators to both view and drill down into any aspect of the entire IT infrastructure – and furthermore, calls for that infrastructure to itself be instrumented to support such observability.
Modern cloud-native observability tools like Evolven are essential for ensuring environment consistency, both in pure Kubernetes deployments as well as the more common hybrid IT scenarios. With Evolven, operators can compare the configuration of both software and infrastructure components both within the same environment (like clustered servers) and across environments (dev/test/prod, for example).
Evolven can also compare environments with different physical but identical logical architectures, thus supporting the complex abstraction at the heart of cloud-native computing.
The Intellyx Take
One way to think about how DevOps and cloud-native computing work together is to take anything you’re doing and ask yourself how to scale it.
Scalability of infrastructure is a given, of course. But you also need to scale your teams. Your configurations. And how you deal with change itself.
Unless you think along these lines, the promise of immutable infrastructure soon collapses under issues of drift and other environment consistency challenges. Or perhaps you’re steadfast in your immutable infrastructure commitment, thus preventing you from scaling in one or more of these fundamental ways.
The answer is to apply the cloud-native principles of observability as well as configuration-based automation and immutable infrastructure to take a proactive approach to environment consistency.
True, it will never take care of itself in a fully automated fashion – but with the proper tooling, your operators have a good shot of maintaining consistent environments as you scale up your cloud-native efforts.
Copyright © Intellyx LLC. Evolven is an Intellyx customer. Intellyx retains final editorial control of this article.