What is infrastructure as code? Automating your infrastructure builds

As more and more organizations move to the cloud, the skill of knowing how to provision and configure a physical server is becoming less relevant to how modern software is built and deployed.

In today’s complex, software-driven world, where computing infrastructure is often neither seen nor heard, being able to provision and manage that infrastructure using declarative code, rather than manual configurations or even scripts, is imperative to running applications at web scale.

A brief history of infrastructure as code

While systems administrators have been using scripts to manage their infrastructure since the 1990s, the practice of treating infrastructure as code (IaC) didn’t fully coalesce until the end of the 2000s, when engineers like devops pioneer Andrew Clay-Shafer, Chef cofounder Adam Jacob, and Puppet founder Luke Kanies started to use the terminology.

In a world of distributed applications, hand-tuning servers was never going to scale, and scripting had its own limitations, so being able to automate infrastructure provisioning became a core need for many first movers back in the early days of cloud.

Today, that underlying infrastructure is more commonly provisioned as code, thanks to popular early tools in this space such as Chef, Puppet, SaltStack, and Ansible. But technology moves fast, and things have advanced since then. Here, we explain the fundamentals of infrastructure as code, and why it is the bedrock of modern software development practices today.

Infrastructure as code defined

In Infrastructure as Code: Dynamic Systems for the Cloud Age, Kief Morris explains that infrastructure as code boils down to three core practices: “Define everything as code, continuously test and deliver everything as you work, and build your system from small, loosely coupled pieces.”

In terms of a working definition, Morris offers that IaC “is an approach to infrastructure automation based on practices from software development. It emphasizes consistent, repeatable routines for provisioning and changing systems and their configuration.”

In practice, this typically sees devops teams make changes to an environment description and the version of the configuration model using a well-documented language like JSON or YAML. Once that environment is configured, changes can be made to the source, not the target, allowing for safer, more regular changes to be made to infrastructure on a vastly larger scale.

Where infrastructure as code and devops meet

As a way to automate initial configuration and subsequent changes, infrastructure as code is a key part of modern devops practices, where developers and operators are expected to work hand-in-hand to deploy software more quickly and more often. By automating and versioning infrastructure builds, IaC tools can help free up application developers to focus on what they do best and liberate system administrators from toiling over manual processes.

Using code to provision and maintain infrastructure helps to bring developers and operations specialists closer together earlier in the software development lifecycle, and helps to instill the discipline, clarity, and repeatibility of software development in operations. With automation and collaboration being key tenets of devops practices, IaC tools also become a central hub for how that team works together effectively.

The benefits of infrastructure as code

The key benefits to treating infrastructure as code hinge on the shift away from manual processes and the freedom that automation provides to devops teams. This brings with it a degree of cost savings and can also boost the velocity at which these teams can safely deliver changes to their applications.

As Simple Thread cofounder Justin Etheredge wrote in a 2020 blog post, “Infrastructure as code gives you the freedom to make changes without the fear that you’ll put things in an unrecoverable state. And it gives you a better understanding of how the environment came to be the way it is, which allows you to be more confident to make the changes you need.”

In his book, Morris outlines seven key benefits to IaC over traditional provisioning methods. These are:

• Using IT infrastructure as an enabler for rapid delivery of value
• Reducing the effort and risk of making changes to infrastructure
• Enabling users of infrastructure to get the resources they need, when they need them
• Providing common tooling across development, operations, and related functions
• Creating systems that are reliable, secure, and cost-effective
• Making governance, security, and compliance controls visible
• Improving the speed to troubleshoot and resolve failures

Infrastructure-as-code tools

The tools required to implement infrastructure as code tend to land in two camps: configuration orchestration and configuration management.

The most popular orchestration tools are AWS CloudFormation, Google Cloud Deployment Manager, HashiCorp Terraform, Microsoft Azure Resource Manager, and Pulumi, which all variously allow developers to automate the deployment of infrastructure.

On the configuration management side, third-party tools like Ansible, Chef, Puppet, and SaltStack remain popular ways of configuring, storing, and automating builds of virtual server environments, while many developers use Docker for their container images.

Many of these tools can be used in tandem, as the likes of Ansible, Chef, Puppet, and SaltStack focus on managing configurations on infrastructure that already exists, while the provisioning tools like Terraform abstract that infrastructure layer away.

Getting started with infrastructure as code

Adopting infrastructure as code will typically be part of a broader organizational shift towards the cloud and devops practices. While much of this shift can sound pretty intimidating, implementing infrastructure as code is key to modernizing your approach to building and running software.

“Sometimes it can take a bit longer to make changes with infrastructure as code,” Etheredge warns, “but this is one of those situations where you need to slow down to speed up. Being diligent about making changes through your scripts will undoubtedly save you countless hours during an outage or when troubleshooting. And you’ll be so much more confident in your changes because you can test that change against a test environment instead of crossing your fingers and running the update straight against production. Even in small environments the payoffs can be enormous.”

Or, as Morris wrote, “Automating your infrastructure takes work, especially when you’re learning how to do it. But doing it helps you to make changes, including building the system in the first place.”