What Is Infrastructure as Code? Benefits, Tools and 5 Best Practices
Infrastructure as Code is an integral DevOps process that businesses should implement to achieve efficiency and reliability. Read our best practices guide to employ IaC effectively.
Infrastructure as Code (IaC) has become an essential practice for virtually every IT organization today. By automating the setup of complex IT environments, IaC makes it possible for teams to manage large-scale IT estates efficiently. At the same time, IaC helps reduce the risk of introducing security vulnerabilities or misconfigurations into IT environments through human error.
No matter which type of IT environment you manage–whether your resources run on-premises, in the cloud or in a hybrid model, and whether you have a Linux-based or Windows-oriented shop–IaC can help to scale and improve your approach to IT environment setup and management.
This article explains what modern IT and DevOps teams should know about IaC. It defines IaC and walks through how IaC works, then offers best practices for getting the most value out of IaC.
What Is Infrastructure as Code?
Infrastructure as Code is the setup and management of IT resources via code-based policy files that can be used to configure resources automatically and repeatedly. It’s the opposite of setting up each system by hand, which was the traditional approach to IT resource management.
IaC can be applied to virtually any type of IT resource. It can be used to provision on-premises or cloud-based servers with the operating systems, user accounts and software configurations required to host a given workload. It can configure networking rules to set up firewalls, VPNs and other types of networking resources. It can configure databases and other storage resources. It can even be used to configure CI/CD tools when building a DevOps software delivery pipeline.
How Does Infrastructure as Code Work?
Most IaC workflows can be broken down into two basic steps.
First, developers or IT engineers write policy files that define how a resource should be configured. The policy files can be written in a variety of languages; the one a team chooses will depend in part on which IaC tool they are using, since different IaC tools support different languages.
Second, engineers deploy the policy files that are executed through an IaC tool. The IaC tool automatically applies the configurations that are defined within the policy files to the systems that engineers designate.
These two steps form the basis for configuring new resources using an IaC approach. However, IaC can also be used to update existing resources. Teams may do this by modifying IaC policy files and redeploying them.
What Are the Benefits of Infrastructure as Code?
By automating the initial setup of IT resources, as well as updates to existing resources, IaC provides several key advantages over the traditional approach of configuring each resource manually.
Efficiency and Speed
First, IaC can add considerable efficiency and speed to IT workflows. With IaC, engineers can define a configuration once, then apply it to as many resources as they wish without a corresponding increase in effort. You can configure one thousand servers just as quickly as you could configure a single server using an IaC approach, the constraint is moved to the hardware you’re deploying it on. By having teams own their IaC code, it also reduces or even eliminates the dependency on shared infrastructure teams, and reduces the friction between operations and development by having developers take ownership of their IaC.
Unlimited Scalability
A related benefit of IaC is the enablement of unlimited scalability when managing IT resources. With a traditional approach to IT configuration, a team's scalability is limited by the team's size and the amount of time it can devote to configuration and management. IaC removes this barrier by allowing teams to configure a large number of resources very quickly.
This is an especially important advantage given that many IT environments today must scale up and down quickly. For example, a business may need to set up new servers rapidly to host additional instances of its applications in response to a sudden increase in customer demand. Traditionally, it would have taken time for engineers to configure each additional server and deploy the business's applications to it. Or you would have all these servers configured and ready to go at all times, becoming costly overall. But with IaC, as long as a configuration template exists, the team can roll out additional servers and applications almost instantaneously.
Reduction of Error
A third key benefit of IaC is the reduction of configuration problems that are caused by human error.
Even the most careful engineers can make mistakes when configuring systems manually. They could forget to install an important library when setting up a server, for example, which later causes problems because the applications that the server needs to host depend on the library. Or, engineers might accidentally assign admin privileges to an ordinary user when configuring user accounts. That creates security risks.
With IaC, configuration mistakes like these are easier to avoid. As long as the IaC policy files that are used to set up resources are properly configured, configurations will be applied reliably and consistently.
Audit, Compliance and Source of Truth
Because IaC configurations are defined in code, they are easy to validate automatically prior to being applied. When writing IaC definitions, teams can use IaC auditing tools to scan them for mistakes before rolling them out, which further reduces the risk of introducing faulty configurations into IT environments. It is typically much harder to audit configurations that are applied manually because those configurations are not defined through a single set of centralized files that can be scanned automatically to detect configuration issues. In the end, IaC can be used as the single source of truth on your infrastructure, and can be leveraged as documentation on how your infrastructure is configured.
Consistency
IaC helps to ensure that businesses maintain consistent IT environments, even if they operate on a large scale.
When teams configure resources manually, it’s likely that different engineers will apply somewhat different configurations to systems that should be identical, based on their preferences. For example, when setting up firewall rules on a Linux server, engineers might use different tools to get to the same result. Although several tools can be used to configure firewalls on Linux, they might rely on different types of configurations. This variability may make it more challenging to maintain the systems in the future because engineers will need to work with two separate types of tools and configuration files to manage firewall rules on the same type of server.
With IaC, differences in configuration tooling and resources become much less of a risk. IaC results in settings that are virtually identical across multiple systems, provided that those systems are configured with the same IaC rules.
What Are the Challenges of Infrastructure as Code?
While IaC enables IT teams to work faster, more efficiently and more reliably, it poses some challenges that must be mitigated in order to derive the greatest value from IaC.
Mistakes in IaC Configuration Files
IaC is only as effective as the policy files that teams create to define how resources should be configured. If you make a mistake in your policy files, and you fail to catch it before deploying the files, you risk duplicating that mistake across all of your systems. And because human engineers won’t be manually applying the configurations, there is little chance that someone will notice the problem until after the IaC policies have already been deployed. The other side to this is, because IaC should be version controlled, it’s easy to implement a consistent fix and deploy easily across your environments. Version control also allows you to quickly roll back your changes in case of unexpected behavior.
IaC Policy Obsolescence
Even if IaC files are free of mistakes when they are first created, they may become outdated over time as IT resources evolve.
For example, an IaC file created to provision a server with one version of a Linux distribution could cease to be effective if the organization upgrades to a newer version.
While the obvious solution to this risk is to ensure that IaC files are updated whenever IT resources change, that may be easier said than done. Teams may inadvertently deploy IaC files that are no longer up-to-date.
Configuration Drift
If access to the environments isn’t managed appropriately, the risk of configuration drift occurs. Configuration drift occurs when manual changes are applied to your infrastructure that are not captured in the IaC. Ways to mitigate this is to enforce zero touch deployments and environments, so that any changes made are only possible through the IaC pipeline.
Learning Curve
For engineers who haven’t previously worked with IaC, or who have used a different IaC than the one their team prefers, it may take some time to learn to write IaC policy files and deploy them through a given IaC tool. Although IaC can save time and effort in the long run, it often requires some upfront investment on the part of engineers to acquire the requisite skills to leverage IaC effectively.
Infrastructure as Code Tools
There are a variety of IaC tools available today. Broadly speaking, they fall into two main categories: Open source solutions, and closed source IaC tools that are tied to a specific vendor or platform.
Open source IaC tools, such as Chef, Terraform and Ansible, support IaC within virtually any type of environment. They are also highly extensible thanks to a dynamic ecosystem of add-ons and plugins provided by the open source community.
In most cases, closed source IaC tools are designed to be used only within a certain type of environment or platform. For example, AWS CloudFormation provides IaC functionality for the AWS cloud. Likewise, Google Cloud Deployment Manager is designed for IaC workflows within Google Cloud, and Azure Resource Manager offers the same for the Azure Cloud.
Top 20 Digital Transformation Innovators: Europe 2021
What are the secrets to a successful digital transformation?
Hear from the experts at O2, The Football Association, Nationwide, Sainsbury's, Credit Suisse, Transport for London, Government Digital Service, Ocado, BNP Paribas and more!
Best Practices for Employing Infrastructure as Code
While deploying an IaC tool is a first step toward adding efficiency and reliability to IT workflows, teams should go further to ensure they use IaC to its greatest effect. The following best practices can help.
Use an Immutable Infrastructure Approach
Immutable infrastructure is an approach to infrastructure management in which teams completely rebuild a resource every time they need to update it. For instance, if you need to update the operating system of a virtual server, you would delete the existing server and replace it with a new server image based on an updated configuration.
IaC can be used to update resources once they are already running. It may make sense to take that approach if you need to apply minor changes, such as installing a new library on a pre-existing server or making a small change to a router's networking configuration.
In general, however, IaC is more reliable when teams adopt an immutable infrastructure strategy. By using IaC templates to create new resources from scratch whenever a major update is necessary, engineers minimize the risk of creating configuration conflicts or configuration drift within existing resources.
Use Version Control for IaC Files
As noted above, IaC files typically need to be updated along with the IT environment they help manage. The most efficient and reliable way to manage these updates is to store IaC files in a version-control system, similar to what developers typically do with application source code.
By automatically storing different versions for IaC files, teams can easily keep track of how their IaC definitions have changed over time. In turn, they’ll know how the resources that those definitions govern have been updated.
In addition, version control makes it easy to revert to an earlier version of an IaC definition in the event that engineers run into a problem when deploying a new version.
Use Modular IaC Definitions
It’s possible, in most cases, to write a single IaC file that will configure all aspects of a given resource. It could define which operating system to install, which user accounts to configure, which applications to install, which networking rules to apply and so on.
However, attempting to define everything in a single file is usually not as efficient as breaking each aspect of the configuration into different files. By taking a more modular approach, teams can more easily update one part of a configuration without touching others.
Modular IaC definitions also make it possible to share some IaC rules across resources, but not others. For example, a team may have two sets of servers that need the same operating system installed, but different user accounts. Modular IaC rules make it easy to address this type of use case.
IaC Compliance Regulation
As we’ve noted, mistakes within IaC files can become a major liability if they are not detected before the IaC definitions are deployed. For that reason, it’s a best practice to scan IaC files automatically and continuously, ensuring that validation occurs whenever an IaC definition is created or updated.
Ideally, IaC scanning should be bricked into the CI/CD pipeline. Just as you test and scan application releases prior to deployment, do the same with IaC rules.
Don’t Store Secrets in IaC Definitions
Sometimes, IaC tools need to access sensitive information, such as passwords or encryption keys, in order to configure resources. This type of information is known as secrets.
The easiest way to define secrets is to include them directly within IaC definitions. However, because IaC rules are plaintext files, this practice is very risky from a security perspective. Anyone who manages to access IaC files will be able to read any passwords or other sensitive data stored in them.
A better practice is to house sensitive data inside a secrets manager, where it can be stored securely and accessed by IaC tools when needed. Some IaC tools provide their own secrets-management tools, such as Chef-vault in the case of Chef. You can also typically use third-party secrets managers, like CyberArk Conjur or a cloud-based secrets tool such as AWS Secrets Manager, in conjunction with IaC tools.
Conclusion: Using IaC to Enable DevOps Success
It may theoretically be possible to manage modern IT environments without the help of IaC, but it’s hard to imagine many teams taking that approach today. When engineers follow IaC best practices–such as tracking the versions of IaC definitions, adopting an immutable infrastructure strategy and avoiding IaC security risks–IaC makes it possible to operate with a much greater degree of efficiency and reliability than traditional approaches to IT management.
