What is Infrastructure as Code (IaC)?

This automation eliminates the need for developers to manually provision and manage servers, operating systems, database connections, storage, and other infrastructure elements every time they want to develop, test, or deploy a software application.

In an era when it’s not uncommon for an enterprise to deploy hundreds of applications into production every day—and when infrastructure is constantly being spun up, torn down, and scaled up and down in response to developer and user demands—it’s essential for an organization to automate infrastructure in order to control costs, reduce risks, and respond with speed to new business opportunities and competitive threats. IaC makes this automation possible.

IaC is also an essential DevOps practice, indispensable to a competitively paced software delivery lifecycle. It enables DevOps teams rapidly create and version infrastructure in the same way they version source code and to track these versions so as to avoid inconsistency among IT environments that can lead to serious issues during deployment.

Provisioning traditional IT is a time-consuming and costly process, requiring the physical setup of the hardware, installation and configuration of operating system software, and connection to middleware, networks, storage, etc. by expert personnel.

Virtualization and cloud native development eliminate the problem of physical hardware management, enabling developers to provision their own virtual servers or containers on demand. But, provisioning virtualized infrastructure still distracts developers’ focus from coding, still requires them to repeat provisioning work for every new deployment, and doesn’t provide an easy way to track environment changes and prevent inconsistencies that impact deployments.

Infrastructure as Code (IaC) goes the final step of enabling developers to effectively ‘order up’ fully documented, versioned infrastructure by executing a script. The benefits are exactly what you might imagine:

• Faster time to production/market: IaC automation dramatically speeds the process of provisioning infrastructure for development, testing, and production (and for scaling or taking down production infrastructure as needed). Because it codifies and documents everything, IaC can even automate provisioning of legacy infrastructure, which might otherwise be governed by time-consuming processes (like pulling a ticket).
  
  
• Improved consistency—less ‘configuration drift’: Configuration drift occurs when ad-hoc configuration changes and updates result in a mismatched development, test, and deployment environments. This can result in issues at deployment, security vulnerabilities, and risks when developing applications and services that need to meet strict regulatory compliance standards. IaC prevents drift by provisioning the same environment every time.
  
  
• Faster, more efficient development: By simplifying provisioning and ensuring infrastructure consistency, IaC can confidently accelerate every phase of the software delivery lifecycle. Developers can quickly provision sandboxes and continuous integration/continuous deployment (CI/CD) environments. QA can quickly provision full-fidelity test environments. Operations can quickly provision infrastructure for security and user-acceptance testing. And when the code passes testing, the application and the production infrastructure it runs on can be deployed in one step.
  
  
• Protection against churn: To maximize efficiency in organizations without IaC, provisioning is typically delegated a few skilled engineers or IT staffers. If one of these specialists leaves the organization, others are sometimes left to reconstruct the process. IaC ensures that provisioning intelligence always remains with the organization.
  
  
• Lower costs and improved ROI: In addition to dramatically reducing the time, effort, and specialized skill required to provision and scale infrastructure, IaC lets organizations take maximum advantage of cloud computing’s consumption-based cost structure. It also enables developers to spend less time on plumbing and more time developing innovative, mission-critical software solutions.

An important decision to make when automating infrastructure with Infrastructure as Code (IaC) and when choosing an IaC solution is whether to establish mutable or immutable infrastructure.

Mutable infrastructure is infrastructure that can be modified or updated after it is originally provisioned. Mutable infrastructure gives development teams the flexibility to make ad hoc server customizations to, say, more closely fit development or application requirements or respond to an emergent security issue. But, it also undermines a key IaC benefit—the ability to maintain consistency between deployments or within versions—and can make infrastructure version tracking much more difficult.

For these reasons, most IaC is implemented as immutable infrastructure—infrastructure that cannot be modified once originally provisioned. If immutable infrastructure needs to be changed, it has to be replaced with new infrastructure. Because new infrastructure can be spun up quickly on the cloud—particularly with IaC—immutable infrastructure is much more feasible and practical than it sounds.

Immutable infrastructure takes IaC to a next logical step, essentially hardening IaC to further ensure the benefits it offers. It all but eliminates configuration drift and makes it even easier to maintain consistency between test and deployment environment. It also makes it easier to maintain and track infrastructure versions and to confidently roll back to any version when necessary.

When choosing an IaC solution, it’s also important to understand the difference between a declarative or an imperative approach to infrastructure automation.

In most organizations, the declarative approach—also known as the functional approach—is the best fit. In the declarative approach, you specify the desired final state of the infrastructure you want to provision and the IaC software handles the rest—spinning up the virtual machine (VM) or container, installing and configuring the necessary software, resolving system and software interdependencies, and managing versioning. The chief downside of the declarative approach is that it typically requires a skilled administrator to set up and manage, and these administrators often specialize in their preferred solution.

In the imperative approach—also known as the procedural approach—the solution helps you prepare automation scripts that provision your infrastructure one specific step at a time. While this can be more work to manage as you scale, it can be easier for existing administrative staff to understand and can leverage configuration scripts you already have in place.

Choosing a declarative or imperative approach is analogous to using a GPS or following turn-by-turn instructions. With a GPS, you enter an address and the GPS does the rest, plotting the fastest route and avoiding traffic for you—but you probably need an expert to tell you why it made the choices it made. The turn-by-turn instructions are based on personal experience; the provider knows the route and why he/she chose it, but if you encounter obstacles or want to optimize the route, you have to call for help or do the work yourself.

While many open-source IaC tools are available, the most commonly adopted tools are Ansible and Terraform:

Ansible is an open source community project sponsored by Red Hat that is designed to help organizations automate provisioning, configuration management, and application deployment. A declarative automation tool, Ansible lets you create ‘playbooks’ (written in the YAML configuration language) to specify the desired state for your infrastructure and then does the provisioning for you. Ansible is a popular choice for automating provisioning of Docker containers and Kubernetes deployments.

Terraform is another declarative provisioning and infrastructure orchestration tool that lets engineers automate provisioning of all aspects of their enterprise cloud-based and on-premises infrastructure.

Terraform works with all the leading cloud providers and lets you automate the build-out of resources across multiple providers in parallel, regardless of where physical servers, DNS servers, or databases reside. It can also provision applications written in any language.

Unlike Ansible, Terraform does not offer configuration management capabilities, but it works hand-in-hand with configuration management tools (e.g., Cloud Formation) to automatically provision infrastructure in the state described by configuration files and to automatically change update provisioning when necessary in response to configuration changes.

For a deeper dive into choosing an IaC tool, see “Infrastructure as Code: Chef, Ansible, Puppet, or Terraform?”