The greatest challenge in managing hybrid IT environments is that they’re, well... hybrid! By definition, you’ve got multiple distinct categories of infrastructure, and for most people, this means at one end of the spectrum you’re dealing with heritage (or “legacy” if you prefer the more negative term) applications and infrastructure that work, deliver value for the business but aren’t particularly flexible or efficient operationally.
Heritage environments themselves almost always consist of multiple archaeological layers that have different operational capabilities and characteristics. At the other end of the spectrum, you have your more recently built infrastructure, taking advantage of cloud-native practices and methodologies, and that almost certainly has a greater dependency on external SaaS services.
The challenge is not just that the technical capabilities differ immensely across this spectrum of infrastructure, but that in any large organisation that has been around for a while, you also have historical layers of processes and practices that have been invented at different points in time, with different teams used to working in different ways.
Infrastructure-as-code (IaC) unlocks opportunities to improve IT environments
You can’t simply apply the same solutions to the wildly different domains across your hybrid IT landscape, but at the same time, it’s a massively wasted opportunity to not look for commonalities, learn from your newest deployments, and modernise the way your teams work with your heritage infrastructure. The industry-standard way of approaching this problem is to invest heavily in an infrastructure-as-code approach.
At its most basic, infrastructure-as-code (IaC) is about being able to treat your infrastructure as if it is software, and to implement an API around it, just like software does. By making your infrastructure programmable, you open up all sorts of opportunities to automate processes, improve the speed of delivery, improve the speed of recovery and increase the consistency of your IT environment.
However, when we talk about IaC, we’re usually referring to not just having a programmable interface for your infrastructure - we’ve had capabilities like automated network booting, shell scripting and batch files for a very long time, well before the IaC movement.
IaC is not just about making your infrastructure programmable, it’s about being able to take the rest of the lessons we’ve learnt from decades and decades of software engineering and applying them to the problem of managing infrastructure.
Key concepts of IaC
Two of the key concepts of IaC that distinguish software configuration management tools from shell scripting are declarative configuration management and run-level idempotence. Being declarative means that you focus on declaring the state you want infrastructure components to be in, rather than the process of how they should get into that state.
This allows you to say “Ensure this package is installed” rather than “check if this package is installed, and if it isn’t, install it”.
Being able to express intent in this manner means that you can take infrastructure from an unknown state, and converge it to a known, desired state, all without requiring expert knowledge of how it is currently configured.
Run-level idempotence means that no matter how many times you apply a given declarative configuration, you will achieve the same outcome, and with minimal side effects. This makes a good IaC system naturally self-healing in that configurations can be reapplied safely, which is critical when operating a large, hybrid environment.
When you’re applying a configuration change to lots of hosts in different locations and with different underlying dependencies, it’s common to see failures on a small subset because they’re rebooting, a network link temporarily failed, an HA process is underway, or any similar temporary issue.
An idempotent IaC solution will let you safely reapply the desired configuration at frequent intervals, ensuring convergence on the desired state as quickly as possible.
IaC also involves using other common practices from software engineering; unit testing, acceptance testing, integration testing and all the other practices that cluster around continuous integration and continuous delivery, and all of these are important practices to increase confidence and velocity when applying changes.
Perhaps the most important capability of a great IaC system however is abstraction, the ability to take the complexity and wrap it up in a simple interface. Abstraction is what enables us to declare “ensure the user Nigel exists” without having to worry about the differences between different operating system installs and the different commands required to create and modify a user account.
The ability to create abstractions in an IaC system allows you to create consistent, standardised interfaces for users that underneath is powered by automation developed by subject matter experts for different environments. This enables much greater scale and leverage from your experts, they can define how automation should work, and the rest of your IT teams can choose when this automation is deployed.
To conclude
Investing in an IaC approach not only enables you to scale efficiently and consistently manage hybrid infrastructure at scale, but it also enables you to do this in a way that is aligned tightly with the way we build, test, and maintain the software that relies upon that infrastructure.
In the end, it’s all about the applications, and the more we align the way we think about infrastructure to the way we think about software, the better those applications will be for our users.
