What is Infrastructure as Code?

Codifying everything in IaC

All the infrastructure specifications should be explicitly coded in a configuration file, for instance as Terraform configurations or Ansible playbooks. The configuration files are the single source of truth of your infrastructure specification and describe what infrastructure components are used in their configuration?

Minimize documentation

IaC is the documentation. With IaC in place, the configuration files represent the documentation and are always up-to-date, which reduces effort. The remaining documentation is about the process. Maintain code in a Version Control System.

IaC configuration files should be kept in a version control systems (VCS), like GitHub or GitLab. This provides an audit trail for code changes, but it also gives the opportunity to collaborate or peer review and test changes before they go live.

With this practice, you can easily track, manage, and revert any potential changes to your systems, with enhanced traceability and visibility.

Testing

One of the practices that IaC borrows from software development is testing. Rigorous testing of infrastructure configuration plays a role in reducing post deployment issues. When combined with version control systems, testing can be automatically triggered every time there is a modification in the code.

With Continuous Integration (CI) in place, the template infrastructure configuration can be implemented in multiple environments such as the development, UAT, QA, or production environment with minimal changes applied effectively.

Modular Infrastructure

Breaking down infrastructure into modules allows for reuse, improved reliability and an easier adoption path. Similar to the use of modules and packages in programming languages. Following are the benefits to this practice.

• Frequently used configurations can be codified as modules and reused multiple times across environments.
• Reliability increases as modules can be tested and become hardened over time with use.
• Composition from reusable modules lowers the skills barrier to IaC adoption.
• Changes are easier to make and test at a module level.
• The risk of change reduces as configuration changes are localized.

Declarative versus imperative approaches to IaC

With adopting IaC, an aspect to consider is what approach your tooling takes. There are two different styles, declarative or imperative, also sometimes described as procedural.

A declarative approach defines the desired state of the system, including the resources you need and any properties they should have, and the tool configures for you. The tool itself determines the operations to get to the desired state from any starting point.

An imperative approach instead defines the specific commands needed to achieve the desired configuration, and those commands then need to be executed in the correct order.

Chef is thought of as an imperative tool. Terraform is classed as declarative. Ansible is declarative but also can be used with imperative commands.

Declarative Terraform and lifecycle management

Schematics supports both Terraform and Ansible as IaC tools with Schematics workspaces and actions. When lifecycle management is important with environments being regularly stood up and torn down, using Terraform with Schematics workspaces is recommended. Terraform keeps a record of the current state of your deployed cloud infrastructure and Schematics is able to remove your infrastructure in reverse dependency order without manual intervention.

Idempotence

A benefit of the declarative approached used by Terraform and Ansible is idempotence. Idempotent tasks can be executed multiple times with the same end result. Irrespective of the previous state or starting place when restarting after failures, the provisioned infrastructure and configuration are always the same. This aspect is key to ensuring consistency and repeatability of environments deployed using Schematics.

How you use a tool and the modules used both have an impact on idempotency. Generally, Terraform and Ansible modules are written to be idempotent. With both tools, code can we written that does not yield an idempotent result. In which case, the configuration may drift from the desired target state. With Terraform this form of drift is most likely when null-resources are used to extend provider functionality with custom scripts which are not idempotent.

Immutability is an IaC practice that minimizes the risk of drift from the target state.

Immutable

Immutable infrastructure refers to managing services and software deployments where resources like containers or virtual machines are replaced rather than changed (using scripts). The main desire here for immutability is avoiding configuration drift. Inconsistencies that arise due to local or manual changes, or differences in the sequence of automated operations. Changes that make it harder to debug and resolve issues, and increase support costs.

To ensure immutability and eliminate drift, all changes should be made through the Schematics IaC configuration, and resources like VSIs should be redeployed when they need updating.