What is infrastructure as code (IaC)?

How does infrastructure as code work?

In the simplest terms, IaC uses software code to provision and manage an IT infrastructure. By using code to define a desired IT outcome, organizations can improve infrastructure consistency, security, automation and performance.

Much time and effort are involved in manually provisioning and configuring servers, storage, networks, Oses, applications, and other devices and services, such as databases, load balancers and firewalls. It can take hours -- even days -- for a human to provide a suitable deployment environment for an enterprise workload and data. Human error can creep into many aspects of this manual effort, leading to the following problems:

• Inconsistent outcomes where no two environments are the same.
• Security vulnerabilities when settings and configurations are done incorrectly.
• Troubleshooting difficulties where infrastructure documentation is poor or nonexistent.
• Compliance and business continuance issues caused by security and troubleshooting problems.
• Problematic management and change control.

IaC embodies all the instructions needed to build and deploy a desired IT environment as a software entity. Developers and IT staff can create detailed instructions to assess the steps required and measure the code's outcomes.

The infrastructure code delivers reproducible results and can be executed at the push of a button or in response to specific conditions. It brings a high level of automation to provisioning and management.

Change is easier to manage because any modifications to the infrastructure code result in a new version that is well documented and can be managed with any standard version control system. If a problem arises due to a change, it can be corrected by running a previously known-good version of the code. This simplifies troubleshooting and improves compliance and security for the business.

The following four basic types of IaC are often used in tandem:

1. Scripts are often used to automate simple ad hoc tasks.
2. Configuration management code defines and automates the installation and configuration of devices such as servers.
3. Provisioning code automates setting up an overall infrastructure, tying together varied aspects of the environment.
4. Container code relies on templates to define image files with libraries and dependencies needed to deploy and execute an application.

The IaC process typically involves the following three steps:

1. A developer uses domain-specific language to create specifications for the desired infrastructure.
2. The specification files are sent or staged to a server or repository, such as GitHub, or an API.
3. The IaC platform uses the specification files, either automatically or on demand, to create and configure the intended infrastructure.

IaC approaches: Declarative vs. imperative

Infrastructure-as-code tools operate using declarative and imperative approaches.

Declarative approach

A declarative programming approach outlines the desired, intended state of the infrastructure but does not explicitly list the steps to reach that state. It declares an intended goal and allows the underlying IaC tools to decide how those goals are implemented. A commonly known declarative programming language is Structured Query Language (SQL). Amazon Web Services (AWS) CloudFormation templates, among others, are written in the declarative style of infrastructure as code.

Imperative approach

An imperative programming approach defines commands that enable the infrastructure to reach the desired state. It defines the precise steps and their order to achieve a desired outcome and does not deviate from those steps. Object-oriented languages, like C++ and Java, can be used for imperative programming. A tool such as Chef can be used declaratively but also imperatively as needed.

In both approaches, IaC is configured on a template, where the user specifies the resources needed for each server in the infrastructure. The template is used to verify that a system is configured correctly or has been set up appropriately. Templates can be constructed as a set of layers of resources, such as in AWS CloudFormation, which makes a stack.

IaC best practices

IaC involves infrastructure configuration and infrastructure management with high levels of automation. While there is no universal approach to deploying and using IaC, numerous best practices help streamline these deployments. Standard IaC best practices include the following:

• Use version control. Provisioning and configuring infrastructure through software means IaC adheres to many software development best practices, such as strong version control. Organizations should use repositories for IaC files, comprehensive version control, and strong documentation and record-keeping to track who accesses the files and what changes occurred between versions.
• Do not share secrets. Many configuration elements involved in IaC require passwords or encryption certificates. These are often included in IaC files without protection, potentially exposing sensitive systems and compromising security. Use a separate secrets manager to store identity and access management details in a protected manner.
• Keep files secure. IaC is intended to embrace the same collaborative attitude as other DevOps and Agile software designs. However, IaC files are likely to contain intellectual property, secrets or other sensitive content. It's important to keep them as secure as other source code the business uses.
• Test and validate files. IaC files should never be taken for granted. They should be tested and validated in the same ways that other software is tested before being released to production. This often involves using continuous integration/continuous delivery (CI/CD), DevOps and Agile techniques.
• Use smaller files. Several smaller IaC files can be used to perform specific tasks and then connected with a script or another IaC template. Using a larger number of smaller files enables better modularity and facilitates reuse of IaC files rather than creating and maintaining a single large ubiquitous file to do everything.
• Monitor and correct drift. When implemented properly and with careful attention to immutability, IaC should ideally not allow configuration drift. However, drift can still occur due to system problems, troubleshooting and human error. It's essential to monitor the infrastructure environment, compare the environment against the IaC definition to find instances of drift, and document and correct any instances.
• Use code as a single source of truth. IaC should serve as a reference point for infrastructure configurations. Treating IaC code as a single source of truth should help ensure consistency across environments, minimizing dependencies and reducing errors that could occur manually.
• Focus on immutable infrastructure. Software defines an infrastructure. With IaC, an immutable infrastructure approach should be used. Infrastructure changes should not be made once the code is provisioned and deployed. If a change is needed, the current infrastructure should be deleted, and a new infrastructure should be deployed using new versions of the IaC files. This prevents any chance of configuration drift.

Immutable vs. mutable infrastructure

Mutable infrastructure refers to changing components in production, while the overall service or application operates normally. Immutable infrastructure assembles and sets components and resources to create a full service or app. If a change is required for any component, it is not changed or reconfigured; it is all updated and effectively redeployed in an instance. A new iteration is assembled, tested, validated and launched, while the old iteration is discontinued and its resources are released for reuse.

Immutable infrastructure has gained favor, particularly for cloud and microservices environments, which are highly scalable and involve many interdependent components and services. Any one-off updates to address specific issues can cause configuration drift that cascades as updates are rapidly pushed to production. Reissuing sets of immutable services and components is more efficient than patching and reconfiguring individual infrastructure components. IaC emphasizes using immutable infrastructure techniques, though immutability is not a prerequisite for IaC.

Benefits and challenges of infrastructure as code

There are many benefits associated with IaC, from automation efficiency to its flexibility to align with other modern IT practices. Other IaC benefits include the following:

• Speed and efficiency. Automated provisioning and management are faster and more efficient than manual processes. This extends to provisioned resources and virtualization, databases, networking, user account management and other tied-in services. IaC can also include code that automatically scales by adding or shutting down environments and resources when they are no longer needed.
• Consistency. Software developers can use code to provision and deploy servers and applications according to business practices and policies -- rather than rely on systems administrators in a DevOps environment. A developer might create a configuration file to provision and deploy a new application for quality assurance or experimental deployment before operations take over for live deployment in production.
• Accountability. Code and corresponding repository management provide a solid foundation for documenting IaC code. It's easy to see factors such as who developed each version and what changes occurred between IaC code versions. This strengthens business compliance and code quality standards.
• Return on investment. Implementing IaC requires a considerable investment, but the payoff in speed, efficiency, consistency, compliance, troubleshooting and automation is typically worth the investment. IaC replaces a manual process that can take hours with an automated process that can be measured in minutes. It eliminates many problems associated with manual infrastructure provisioning and configuration.
• Alignment with DevOps. The infrastructure setup written as code can go through the same version control, automated testing and other steps of a CI/CD pipeline that developers use for application code. An organization might combine IaC with containers, which abstract the application from the infrastructure at the OS level. Because the OS and hardware infrastructure are provisioned automatically and the application is encapsulated, these technologies prove complementary for diverse deployment targets, such as test, staging and production.
• Shared resources. IaC improves replicating infrastructure across other systems that use the same resources. In this use, IaC provides consistency and can help streamline troubleshooting processes.

Despite its benefits, IaC also poses some disadvantages, including the following:

• Requirement of additional tools. Infrastructure as code requires additional IaC-specific or IaC-capable tools, such as configuration management tools and an automation and orchestration system, which could introduce learning curves and errors. Mistakes can proliferate quickly through servers, especially with extensive automation, so monitoring version control and performing comprehensive prerelease testing are essential.
• Lack of features. IaC tools provide various powerful features and capabilities, but some might be incomplete or missing. It's important to evaluate and vet tools, especially against business needs, and maintain careful oversight of each tool provider's product or feature roadmap.
• Complexity of existing tools. Introducing new tools, processes and standards into the DevOps and operations environments can add complexity to areas with prevalent tools and platforms. Enterprise-wide support is required for IaC to provide lasting and meaningful benefits to the business.
• Potential for configuration drift. If administrators change server configurations outside of the set IaC template, there's potential for configuration drift without additional change management tools. It's important to integrate IaC fully into systems administration, IT operations and DevOps practices with well-documented policies and procedures. If legacy security and monitoring tools cannot handle IaC, this will require investing in more tools, with additional training and testing to integrate them into workflows.
• Competency gaps. IaC places more responsibility on developers to understand how to write efficient code that translates seamlessly into production environments. They must also have strong knowledge of the languages used for IaC, including JavaScript Object Notation (JSON), YAML, Ruby, C++ and SQL. Knowledgeable staff might be harder to find and retain.

Infrastructure-as-code tools

IaC tools configure and automate infrastructure provisioning. These automation tools can automatically execute infrastructure deployment, such as servers with orchestration functionality. They can also configure and monitor previously provisioned systems.

IaC tools enforce the setup from the template using 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 are typically designed by default for push or pull deployment of code, but they can be set up for specific instances to do the opposite. These tools should also be able to roll back changes to the code in case of unexpected problems from an update.

The following are examples of IaC tools:

• AWS CloudFormation.
• Chef.
• Google Cloud Deployment Manager.
• Microsoft Azure Resource Manager.
• Puppet.
• Red Hat Ansible Automation Platform.
• Terraform by HashiCorp.
• VMware Tanzu Salt.

Some tools rely on a domain-specific language, while others use a standard template format, such as JSON and YAML.

Organizations should consider the target deployment and select a tool for that environment. For example, AWS CloudFormation is designed to provision and manage infrastructure on AWS and works with other AWS offerings. Similarly, Microsoft Azure Resource Manager manages infrastructure on the Azure platform, while Google Cloud Deployment Manager is Google's infrastructure deployment service. Alternatively, Chef works with on-premises servers and multiple cloud provider infrastructure-as-a-service offerings.

IT operations can go beyond IaC and take a code-based approach to managing all their resources. Learn how everything as code works, and see if it's right for your organization.