Infrastructure as Code: The Cornerstone for DevOps & Multicloud

One key concept to master when dealing with cloud, containerized, or otherwise software-defined infrastructure is Infrastructure as Code. This may seem strange at first. After all, your code runs on top of infrastructure, right?

Infrastructure as code (IaC) works in practice by managing your computing resources — virtual machines, storage, networking, and all the associated policies for security and such — in the same manner as you treat your code. This packages everything necessary for your application, from the code and assets to the underlying infrastructure itself, together into what works functionally as a single deployment.

Just as DevOps combined development and operations into one entity, IaC combines code and infrastructure as one.

Version control, systems testing, QA, and monitoring are all essential components of IaC. You use underlying code to configure and deploy new virtual machines and associated infrastructure components rather than configuring each VM from documentation.

A well-optimized cloud environment is inherently Infrastructure as Code, because a single cloud operations team member can spin up large quantities of VMs with just a few clicks, and have them all adhere to company policy while also being ready to work in concert with existing infrastructure from the get-go, including network settings, identity management (Active Directory), security configuration, and so forth.

Cloud Automation vs. Infrastructure as Code

Sounds a lot like cloud automation, right? Not exactly. Embracing IaC is a mindset much like DevOps – and indeed, DevOps initiatives really have IaC as a cornerstone. The two are synergistic concepts. Your IaC code should be subject to DevOps practices itself, so your automation scripts are constantly iterated, tested, and improved alongside new technologies and growing environments. Your infrastructure itself should be accessible by development, testing, and operations teams alike — and perhaps even beyond the core infrastructure teams into IT as a whole or other departments who may need servers of their own.

IaC also differs from automation in that your infrastructure itself uses source control. This is a vital trail of evidence for audits and changelogs should you need to perform some detective work down the line or rollback to a previous version of infrastructure that you knew to be stable.

Continuous improvement and testing are included under IaC, so your servers and supporting infrastructure themselves are constantly being tested, monitored, and iterated. Individual units, functional groups, and integration should all be tested before going to production.

What tools enable IaC?

Emerging leaders like Puppet are designed for infrastructure as code specifically. Puppet takes your provided definition of a desired infrastructure state and automatically enforces it, remediating any changes. It generates detailed reports or graphs of the state of infrastructure that includes any changes made. Anything outside of policy is automatically shifted to a the predetermined state.

This differs from change management and using a change management tool for IaC could get messy. While you can have some success enabling IaC-like practices via change management, the two differ fundamentally in that change management tools will query all conditions multiple times until convergence is reached (all conditions are reported as true). This leads to slower performance and slower time to resolution as well. Change management tools are unlikely to have the ability to define multi-step processes in a desired order; they also may not be able to store and compare a current model of your desired deployment.

When you introduce containers, you may have already solved for many of the problems addressed by IaC and change management alike. After all, containers have everything needed to run the app within the Dockerfile shell script. But now you have to orchestrate the relationships between containers and their overarching services.

This can be accomplished with version controlled native tools like Docker Compose and Docker Swarm, which describe the relationship states and desired run time state of containers in clusters. Third party tools that can manage more than just Docker containers exist as well — like Kubernetes. You can use IaC concepts to manage these container orchestration platforms with source control as well.

Many IaC platforms use YAML (YAML Aint Markup Language) code as their base. Image from this explanation of YAML.

How does this help multicloud?

Okay, so IaC is great for DevOps. But it is also essential for multicloud deployments. A well-orchestrated IaC platform helps you abstract from vendor native tools and, using software-defined APIs, manage across different platforms using a single set of “known good” configurations.

IaC makes the difficult process of provisioning and configuring hardware (or more likely, virtual hardware), software stacks, Active Directory, security policy, and various interdependencies much faster and simpler. It has advantages over scripting in that scripts are generally linear and inflexible. In the cloud, IaC is almost essential. Have you taken advantage of IaC practices yet?