Infrastructure as Code in a Private or Public Cloud

As technology advances, our tools change. But because most people resist change it often takes some type of failure—a system outage, a failed disaster recovery event, etc.—to get us to change our governance practices.

For example, as companies move their operations to the cloud they tend to manage their cloud infrastructure the same way they managed their on-premise physical hardware, by logging into their virtual infrastructure’s web interface, or directly onto a system and applying changes via GUI or CLI. These users haven’t adopted the use of infrastructure as code (IaC) through the use of tools like HashiCorp Terraform.

What is IaC? It is infrastructure (CPUs, memory, disk, firewalls, etc.) defined as code within definition files. But why change how we define and build infrastructure?

Virtual compute enabled us to build and apply configuration changes to infrastructure via software commands. While these commands were often scripted, they were still hard for humans to read. More modern tools accepted code that was both human and machine readable, and provided additional benefits. They simplified code testing, could apply and track the changes between iterations, and most importantly they enabled teams to reuse components (e.g. modules) of code across different projects. It’s no wonder that IaC has developed such a significant following and adoption.

»IaC and the Infrastructure Lifecycle

So how does IaC fit into the infrastructure lifecycle? IaC can be applied throughout the lifecycle, both on the initial build, as well as throughout the life of the infrastructure. Commonly, these are referred to as Day 0 and Day 1 activities. “Day 0” code provisions and configures your initial infrastructure.

If your infrastructure never changes after the initial build (no OS updates, no patches, no app configurations, etc.) then you may not need tools that support subsequent updates, changes, and expansions. “Day 1” refers to OS and application configurations you apply after you’ve initially built your infrastructure.

IaC makes it easy to provision and apply infrastructure configurations, saving time. It standardizes workflows across different infrastructure providers (e.g., VMware, AWS, Azure, GCP, etc.) by using a common syntax across all of them.

IaC makes it easy to understand the intent of infrastructure changes, because it can span multiple files, allowing human operators to organize the code based on the intent. For example, an operator could create different files to define different infrastructure components, or separate variables definitions from execution blocks without affecting the execution.

Here is an example of code that the IaC tool Terraform would use to provision an Amazon VPC. Notice that the code is both human and machine readable.

resource "aws_vpc" "default" {
  cidr_block = "10.0.0.0/16"
}

Tools like Terraform often include libraries of providers and modules to make it easy to write the code to provision and apply configurations. With Terraform, especially when the need is Day 0 only, it is common to apply initial configurations like the ones below which install and start a web server:

provisioner "remote-exec" {
  inline = [
    "sudo apt-get -y update",
    "sudo apt-get -y install nginx",
    "sudo service nginx start"
    ]
}

If it is necessary to apply Day 1 through Day N configurations, the code might leverage a tool like Chef, Ansible, Docker, etc.

provider "chef" {
  server_url = "https://api.chef.io/organization/example"
  run_list = [ "recipe[example]" ]
}

You can find a more complex example of Terraform IaC that provisions a two-tier application in this Hashicorp Learn tutorial: Deploy Federated Multi-Cloud Kubernetes Clusters.

»IaC Makes Infrastructure More Reliable

IaC makes changes idempotent, consistent, repeatable, and predictable. Without IaC, scaling up infrastructure to meet increased demand may require an operator to remotely connect to each machine and then manually provision and configure many servers by executing a series of commands/scripts. They might open multiple sessions and move between screens, which often results in skipped steps or slight variations between how work is completed, necessitating rollbacks. Perhaps a command was run incorrectly on one instance and reverted before being re-run correctly.

These process inconsistencies can result in slight differences between servers that compound over time and could impact their performance, usability, or security. If a large team is applying changes, the risks increase because individuals don’t always follow the same instructions identically.

With IaC, we can test the code and review the results before the code is applied to our target environments. Should a result not align to our expectations, we iterate on the code until the results pass our tests and align to our expectations. Following this pattern allows for the outcome to be predicted before the code is applied to a production environment. Once ready for use, we can then apply that code via automation, at scale, ensuring consistency and repeatability in how it is applied.

Since code is checked into version control systems such as GitHub, GitLab, BitBucket, etc., it is possible to review how the infrastructure evolves over time. The idempotent characteristic provided by IaC tools ensures that, even if the same code is applied multiple times, the result remains the same.

»IaC Makes Infrastructure More Manageable

Leveraging HashiCorp Terraform IaC provides benefits that enable mutation, when necessary, via code. Consider an environment has been provisioned that contains a couple servers and a load balancer. To address increased load, additional servers are needed. The IaC can be revised, with minimal changes, to bring new servers online using the previously defined configuration.

During execution, Terraform will examine the state of the currently running infrastructure, determine what differences exist between the current state and the revised desired state, and indicate the necessary changes that must be applied. When approved to proceed, only the necessary changes will be applied, leaving existing, valid infrastructure untouched.

»IaC Makes Sense

Successfully managing the lifecycle of infrastructure is hard, and the impact of poor management decisions can be significant, ranging from financial and reputational losses to even loss of life when considering government and military dependencies on infrastructure. Adopting the use of an IaC tool such as HashiCorp Terraform, in conjunction with related and established tools, processes, and workflows, is a necessary step in mitigating these risks.

To learn more about Terraform and HashiCorp’s other infrastructure tools, visit the Terraform documentation and check out our learning tracks on HashiCorp Learn.