What is Infrastructure as Code? An Introduction to IaC

Infrastructure as Code, or IaC, is the practice of automatically provisioning and configuring infrastructure using code and scripts. IaC allows developers to automate the creation of environments to generate infrastructure components rather than setting up the necessary systems and devices manually.

In the past, system administrators had to painstakingly provision and configure all the hardware and software required to run applications by hand. This process is untenable in modern software delivery and software development where teams are expected to deploy hundreds of apps a day. IaC lets teams automatically spin up networks, databases, virtual machines and any other infrastructure components to create the cloud environment they need to test and run their apps. 

IaC is an essential DevOps practice. Automation and agile processes need available IT infrastructure to run and test code. Having to physically configure an environment every time a developer wants to develop, test or deploy software would counteract the speed that DevOps practices bring. With IaC, developers can set up infrastructure in minutes, with all of its configuration files versioned to ensure consistency across IT environments.

In the following sections, we’ll look at why IaC is important for organizations, the many benefits it offers and how you can get started implementing it in your company.

The Importance of Infrastructure as Code

IaC is important because it makes the provisioning of infrastructure easier, faster and more scalable. To understand this, it’s necessary to look at the workings of infrastructure management.

Historically, developers, testers and other infrastructure consumers had to file a ticket or email a request whenever they wanted to provision infrastructure resources. The IT operations team would review and log all the tickets in the queue, then manually allocate the requested resources for each one. While time-consuming, the process was sufficient because most organizations didn’t have a lot of infrastructure to manage. It wouldn’t be uncommon for a single virtual machine, for example, to live in a company’s data center for years or for teams to conduct manual configuration of infrastructure or other manual processes in the environment. 

Infrastructure today is much more dynamic, thanks to automation tools and API-driven cloud infrastructure that enable resource provisioning in days or weeks instead of months and years. Organizations can scale up infrastructure for peak hours or seasons and scale it back down when demand returns to normal levels. This elasticity makes it impractical to manage infrastructure manually, as it would require submitting thousands of tickets every day to increase or decrease workload capacity as needed and waiting for admins to fulfill those requests.

IaC solves this problem by replacing manual interaction with an interface that automatically provisions and configures infrastructure. Users can run a script to spin up a thousand machines for peak workload times and run it again to tear them down when demand is lower. With this approach, DevOps teams can create servers, deploy operating systems, set up data storage and configure all other infrastructure components they need on demand.

The increasing need for building and deploying applications and delivering customer value more quickly makes IaC a critical tool for most organizations.

Common Benefits of Infrastructure as Code

IaC offers many benefits to organizations, including:

• Increased speed and efficiency: IaC automates provisioning and configuration of the entire infrastructure architecture (network, production environments, virtual servers, databases, etc.). With infrastructure automation, users can create development, testing and staging environments with more speed and reliability.
• Better documentation: The code that describes an infrastructure also documents how it should be provisioned, representing additional insurance should employees exiting the company take their institutional knowledge with them. If necessary, infrastructure code can be version controlled to document every server configuration change to be tracked, managed and restored.
• Increased scalability: IaC allows you to easily add resources to the existing infrastructure. Users can scale up quickly during peak workload times and back down when demand subsides.
• More reusability: DevOps teams are often required to provision the same combination of resources for development, staging and production. They can reuse IaC scripts across multiple environments, rather than creating new infrastructures from the ground up.
• Better collaboration: Version-controlled code allows multiple users to work on different parts of the infrastructure without having to directly communicate with each other.
• Less human error: IaC always applies configurations the same way and without introducing coding errors, ensuring consistency across IT environments.
• Better disaster recovery: To quickly recover systems after a disaster, organizations only need to run the same code to bring systems back online at different locations. Alternatively, developers can provision several environments simultaneously in different locations to provide continuous delivery and better failover services.
• Reduced costs: IaC eliminates the costs of manually setting up infrastructure components. It’s also more cost-effective in the long run as most IaC platforms charge only for the resources used.
• Improved customer experience: IaC subjects infrastructure to the same well-established practices — code reviews, testing, versioning — used to manage source code, resulting in fewer errors, better performance and less downtime.
  

Mutable vs Immutable Infrastructure: What's The Difference?

Mutable and immutable are two different types of infrastructure environments. Mutable simply means the infrastructure can be modified after it has been provisioned — to accommodate a new server, for example — while immutable means it can’t. 

The main advantage of a mutable infrastructure is that it allows developers to customize existing servers to specific apps or development needs rather than requiring them to establish new ones. By extension, this allows the infrastructure to meet the needs of each user.

But this changeable nature sets up some significant drawbacks. Because each server is uniquely configured, it’s more difficult to diagnose and manage each one, a condition called “configuration drift.” Also, because server changes aren’t typically documented, it also hinders version tracking, making it harder to find and reproduce technical issues.

Immutable environments are more rigid, requiring infrastructure components to match particular specifications. Once the infrastructure is built, ad-hoc modifications can’t be made; any needed server changes will necessitate construction of entirely new infrastructure based on updated requirements and the removal of the old infrastructure. This practically eliminates the problem of configuration drift, while making it easier to identify and resolve technical issues, and ensuring testing consistency from development through production.

Immutable IaC is increasingly essential for DevOps teams. Together, the concepts of immutable infrastructure and IaC enable consistent environments that accelerate the DevOps process and reduce delays in the delivery pipeline. This allows teams to focus more on innovating than spending time taking care of infrastructure.

Open-Source Infrastructure as Code

IaC is supported largely by open-source tools such as HashiCorp Terraform, Red Hat Ansible and Helm, as well as Chef, Puppet and Salstack. Open-source IaC tools use coding language that allows users to provision and manage infrastructure across multiple cloud vendors and that are compatible with other open-source solutions. By contrast, the big cloud vendors include proprietary IaC code tools as part of their cloud computing ecosystems, such as AWS CloudFormation for AWS Cloud and Azure Resource Manager for Microsoft Azure. These tools have the advantage of being designed specifically for their respective cloud platforms, but their closed approach can result in vendor lock-in for the user.

Using Infrastructure as Code to Automate Deployments

IaC tools vary in the details of how they work, but they all take one of two approaches to infrastructure automation — declarative or imperative. It’s important to understand the differences between these two programming language styles when selecting an IaC tool.

With the declarative approach, the user “declares” what the provisioned infrastructure should look like by specifying a list of resources and required properties. Then the IaC tool installs and configures all the infrastructure components and manages code versioning. With the imperative approach, users specify a list of commands they want the IaC to run so the infrastructure will be provisioned step by step. Put simply, declarative programming lets users say what infrastructure resources they want, and imperative programming lets them say how they want the infrastructure resources created.

Although both approaches can be used to create the desired infrastructure, there are some differences to consider. To understand them clearly, let’s discuss how each approach handles instructions illustrated by the example of taking a taxi to the airport. A declarative instruction would be to tell the driver, “Get me to the airport by 11 a.m.” Here, you’ve stated your desired outcome, and it’s up to the taxi driver to determine the best route, speed and other factors to get you there on time. 

An imperative approach, on the other hand, would be to give the driver explicit instructions on how to get you to the airport by 11 a.m. For example, “Pick me up at 10:15 a.m., take a left at the corner, get on the freeway and accelerate to 65 mph … ” Both of these approaches will get you where you need to go, but the second approach doesn’t leave much wiggle room if the driver encounters an unexpected obstacle, like a road detour or a car accident on the freeway. Declarative and imperative instruction work much the same way in IaC.

Declarative tools handle all the complexities of provisioning your desired infrastructure. However, you’ll have little insight into why it made the choices it did without consulting the tool’s administrator. An imperative approach gives you more control over how your infrastructure is provisioned, but it requires more work from the developer, and its reliance on explicitness means if it encounters an obstacle at any step, you’ll have to stop and work out the solution — which can make this approach tough to manage at scale. The “best” style depends on several factors, such as how much code you’re writing, the likelihood you’ll be updating the infrastructure down the road, and how much control you require over the way changes are made to your cloud services.

The Importance of Terraform

Terraform is a popular open-source, cloud-agnostic IaC tool that uses declarative programming and a high-level configuration language called HCL (HashiCorp Configuration Language) to define and provision infrastructure for running an application. 

In essence, Terraform works by reading the code describing the infrastructure’s “end state” and creating a graph depicting the listed resources and their relationships to each other. It then compares this graph against the resources in the cloud and generates a plan that outlines what changes will be applied to the cloud and in what order to achieve that state, then executes that plan to provision the infrastructure.

Terraform is popular with developers for several reasons:

• It’s open source: Terraform is supported by a large community of contributors and organizations. Plugins, extensions and professional support are available for just about every major cloud provider and service including Microsoft Azure, AWS, Google Cloud Platform and Kubernetes — and improvements are added regularly.
• It’s platform-agnostic: Unlike proprietary tools like AWS CloudFormation and Azure Resource Manager, which are designed solely for use with their respective cloud providers, Terraform can be used with any cloud service provider.
• It provisions immutable infrastructure: As mentioned earlier, immutable infrastructure is increasingly important for DevOps. Terraform reprovisions the infrastructure each time a change is made to the environment, replacing the current configuration with a new one that reflects the change. It can retain prior configurations as versions for rollback when needed.
  

Using Terraform as a Team

Terraform uses a three-step core workflow. The workflow is the same whether an individual is working alone on infrastructure or collaborating with a team, but there are additional practices in each step when multiple people are working together. 

• Step 1: Write. The first step is to author the Infrastructure as Code. When a team is working together, individuals make changes to the Terraform configuration in their preferred editor as if they were working alone. However, they each save their changes to version control branches to prevent overwriting each other’s work. Team members run plans iteratively to help identify syntax errors and test the configuration, creating a feedback loop.
• Step 2: Plan. Once the “write” step’s feedback loop produces a workable change, Terraform allows team members to review each other's work and ensure that no potentially harmful changes are made when code is merged from an individual’s working branch to the shared team branch. The team can also determine whether they want to merge the change now, or, if the change could interrupt service, delay merging the pull request until they can schedule a maintenance window.
• Step 3: Apply. After a pull request is approved and merged, the team reviews the final plan that's run against the shared team branch. At this point, team members evaluate the potential implications of applying the change, including risks of service disruption and who needs to be notified. They may also decide to watch the output as it happens.

This core workflow for teams is a recurring loop that is used for each change, which can occur several times per day or week.

Terraform Strategies and Best Practices

There are many best practices for better infrastructure provisioning with Terraform. Here are just a few:

• Use modules, but in moderation: Modules are containers for sets of related resources. In addition to the “root” module, you can use modules to incorporate features like preconfigured load balancers or Kubernetes clusters. Using and modifying official Terraform modules instead of creating your own allows you to save time and effort. But adding too many modules to your infrastructure will make your configuration more complex, potentially slowing code execution and making it harder to debug. 
• Use multiple workspaces: Rather than managing everything from a single Terraform workspace, divide your environment into development, staging and production areas. Smaller workspaces are easier to manage and delegate to specific teams for sharing the workload.
• Backup your system state: Terraform uses a “state file” that tracks resources and metadata in your infrastructure. If that file is lost, Terraform won’t know what resources have been deployed or how to reach them, so it’s critical to maintain a backup of the state file for each of your active environments.
• Always use the latest version: The Terraform development community is very active, releasing new features and functionalities often, so it’s best to stay on top of them to keep upgrades manageable. Skipping and then trying to catch up on multiple major releases at once adds unnecessary complexity when upgrading.
  

The Future of Infrastructure as Code

IaC will likely become the standard for provisioning, managing and orchestrating compute resources. The traditional approach of procuring, installing and configuring hardware along with applying the right configuration management tools that integrate it into a new environment is no longer practical as organizations demand more flexible and responsive infrastructure. Cloud-native development and virtualization have helped eliminate the problem of managing physical hardware, and IaC takes the next step of letting developers automate infrastructure provisioning on demand. IaC facilitates faster time to market, reduced costs and improved ROI, positioning it as an essential component of DevOps.

The Bottom Line: IaC is essential for DevOps organizations

IaC can help your organization speed up its infrastructure provisioning processes and lifecycle, maintain consistency across development environments, and free your IT teams to spend more time on higher-value activities. If you need to deliver at speed and scale, IaC can provide the foundation for doing so now and for years to come.

What is Splunk?

This posting does not necessarily represent Splunk's position, strategies or opinion.