Infrastructure as Code

One of the objectives of shifting to a DevOps work methodology is to automate the provisioning of infrastructure. And this is known as Infrastructure as Code or just IaC. It is a vital part of Continuous Integration / Continuous Delivery - or CI/CD for short - because it reduces failures in the deployment step, which translates into less time lost resolving them, a big plus in DevOps environments since they often define very short release cycles.

Benefits of IaC

Here we will look at some of the reasons why IaC is helpful for operators.

• Similar to replacing physical servers with virtual machines and containers in most deployments frees system administrators from troubleshooting physical hardware, Infrastructure as Code replaces one-off scripts, relieving sysadmins from the potentially costly task of fixing broken scripts.
• It removes the burden of scripting the whole deployment from a group of sysadmins and instead makes all participants of the development and operations sections share that burden.
• Modifications to deployments can be staged in parts and reviewed individually, eliminating cases of operators not knowing why their new versions of deployment scripts fail.
• In pay-by-the-hour settings, fast deployments also reduce deployment costs by utilizing resources without operator intervention.

Some additional features of IaC

Idempotence

An idempotent deployment keeps the environment in a frozen state whether it is run once or repeatedly. Idempotency is especially attractive to operators because they no longer need to revert systems to a predefined state before starting the deployment. This makes deployment faster.

Environment versioning

As described above, Infrastructure as Code causes all environment configurations to be stored in version control, which allows you to “checkout” one of these versions and reproduce that particular environment, a task that would otherwise be highly laboring without versioning.

One consequence of this is that deployments are now immutable: There is no way to update a system’s configuration to reflect a new deployment; the old deployment must be erased by a proper operating system reinstall for the new deployment to be made.

Different ways of coding deployments

Two widely used methods of writing IaC deployments are declarative templates and imperative templates. In a declarative template, you would list the specific components that need to be configured, and the deployment tool will figure out the commands to do it for you. AWS CloudFormation and Terraform are examples of declarative templating tools.

Imperative templates, however, rely on the operator scripting commands in a sequential order, which the tool then executes serially. In a way, they resemble the shell scripts of traditional deployment. Ansible (to some extent) is an example of an imperative templating tool.

Configuration Managers vs. Orchestrators

Most deployment tools specialize in either deploying either software or the servers themselves. The ones that deploy software or their configurations, such as Ansible or Puppet, are called configuration managers. In contrast, others like Terraform that allocate containers, VMs, or even physical servers, are called orchestrators. Configuration managers are sufficient for software-only deployments, but if your project necessitates the configuration or provisioning of both hardware and software, then you will find having both an orchestrator and a configuration management tool useful.

Use case: Support ticket handler

Let's see how IaC can help someone in charge of support tickets.

Normally when somebody files a ticket for a degraded system or just wants to make a configuration change, the operator manually checks the system's settings and logs from a control panel and issues the appropriate commands or configuration changes.

This works fine if there are only a few servers to configure. However, things quickly get out of hand when there are more than a handful of servers to configure. In this case, an operator would make a script that configures all the servers simultaneously.

This works, however, an even better approach would be if the scripts were stored inside version control, and developers, as well as other operators, contribute bits and increments of code to it. This is what is known as Infrastructure as Code - the scripts that provision and configure production systems are similarly maintained like code.

In addition to that, treating your scripts as if they were regular code enables you to apply the same quality and style practices to it and paves the way to test and provide bug fixes for them as well.

Conclusion

Infrastructure as Code replaces one-off scripts with version-controlled code, which is read by a deployment tool. Different types of deployment tools are used depending on what resource needs to be provisioned or configured. Infrastructure as Code helps operators and sysadmins avoid deployment failures and saves deployment costs by automatically running the jobs and placing script maintenance responsibility on developers as well as on sysadmins.