infrastructure as code

Infrastructure as code, also referred to as IaC, is a type of IT setup wherein developers or operations teams automatically manage and provision the technology stack for an application through software, rather than using a manual process to configure discrete hardware devices and operating systems. Infrastructure as code is sometimes referred to as programmable or software-defined infrastructure.

The concept of infrastructure as code is similar to programming scripts, which are used to automate IT processes. However, scripts are primarily used to automate a series of static steps that must be repeated numerous times across multiple servers. Infrastructure as code uses higher-level or descriptive language to code more versatile and adaptive provisioning and deployment processes. For example, infrastructure-as-code capabilities included with Ansible, an IT management and configuration tool, can install MySQL server, verify that MySQL is running properly, create a user account and password, set up a new database, and remove unneeded databases.

The code-based infrastructure automation process closely resembles software design practices in which developers carefully control code versions, test iterations, and limit deployment until the software is proven and approved for production.

Benefits of infrastructure as code

Software developers can use code to provision and deploy servers and applications, rather than rely on system administrators in a DevOps environment. A developer might write an infrastructure-as-code process to provision and deploy a new application for quality assurance or experimental deployment before operations takes over for live deployment in production.

With the infrastructure setup written as code, it can go through the same version control, automated testing, and other steps of a continuous integration and continuous delivery (CI/CD) pipeline that developers use for application code. An organization may choose to combine infrastructure as code with containers, which abstract the application from the infrastructure at the operating-system level. Because the OS and hardware infrastructure is provisioned automatically and the application is encapsulated atop it, these technologies prove complementary for diverse deployment targets, such as test, staging and production.

Despite its benefits, infrastructure as code poses potential disadvantages. It requires additional tools, such as a configuration management system, that could introduce learning curves and room for error. Any errors can proliferate quickly through servers, so it is essential to monitor Version control and perform comprehensive prerelease testing.

If administrators change server configurations outside of the set infrastructure-as-code template, there is potential for configuration drift. It's important to fully integrate infrastructure as code into systems administration, IT operations and DevOps practices with well-documented policies and procedures.

Approaches and methods

Infrastructure-as-code tools can be declarative and imperative.

A declarative programming approach outlines the desired, intended state of the infrastructure, but does not explicitly list the steps to reach that state. SQL is a commonly known declarative programming language. AWS CloudFormation templates, among others, are written in the declarative style of infrastructure as code.

In contrast, an imperative approach defines commands that enable the infrastructure to reach the desired state. Object-oriented languages, such as C++ and Java, can be used for imperative programming. A tool such as Chef can be used in the declarative manner, but also imperatively as needed.

In both approaches, infrastructure as code is configured on a template, where the user specifies the resources needed for each server in the infrastructure. The template is used to either verify that a system is properly configured or put it in the appropriate setup. Templates can be constructed as a set of layers of resources, such as in AWS CloudFormation, which makes a stack.

AWS CloudFormation infrastructure as code
Resources are a required component of an infrastructure-as-code deployment. In this infrastructure-as-code example, the resource is WebServer in an AWS CloudFormation template.

Infrastructure-as-code tools

Infrastructure-as-code tools configure and automate the provisioning of infrastructure. These tools can automatically execute the deployment of infrastructure, such as servers, with orchestration functionality. They also can configure and monitor previously provisioned systems.

Infrastructure-as-code tools enforce the setup from the template via push or pull methods. In the push method, a centralized server sends the desired configuration to a specific system or systems. The pull method is initiated by a request to a centralized server from a system or systems in the infrastructure. Tools typically are designed by default for push or pull deployment of code, but can be set up for specific instances to do the other. These tools should also be able to roll back changes to the code, as in the event of unexpected problems from an update.

Examples of infrastructure-as-code tools include AWS CloudFormation, Red Hat Ansible, Chef, Puppet, SaltStack and HashiCorp Terraform. Some tools rely on a domain-specific language (DSL), while others use a standard template format, such as YAML and JSON. When selecting a tool, organizations should consider the target deployment. For example, AWS CloudFormation is designed to provision and manage infrastructure on AWS, and it works with other AWS offerings. Alternatively, Chef works with on-premises servers and multiple cloud provider infrastructure-as-a-service offerings.

This was last updated in January 2019

Continue Reading About infrastructure as code

Dig Deeper on Matching IT Resources to Application Requirements

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

What benefits and challenges have you seen with infrastructure as code?
Seems like when it's good, it could be very, very good, but when it's bad, it's horrid. Like the saying goes, automating something means you can mess it up a whole lot faster. I wonder how many organizations are big enough that automating this process would save that much time, when you add in all the additional testing that would be required.
I think this area is low hanging fruit for ai...I can forsee a embeded form of HATOS that ai would use to detect and manage resources as needed.