Infrastructure as code and automation

From runbook to repository

Before automation, a new environment meant a ticket, a checklist and a patient administrator, and no two environments ended up quite alike. The CNCF landscape guide puts the tools that replaced this at the very bottom of its stack, in the provisioning layer, because everything else is built on the resources they create. Their promise is reproducibility: once the setup is written down, creating it again produces the same result, and a mistake can be found by reading a file instead of by clicking through screens.

Most tools are declarative. You describe the end state, such as a network with two subnets and a database reachable only from one of them, and the tool works out which calls to the platform's API will get there. That same description is compared with reality on every run, so a change becomes a diff someone can read before it is applied. Kept in Git and passed through a pull request, the infrastructure acquires the review culture that application code already has.

• Provisioning tools create cloud resources: Terraform and OpenTofu (the latter a CNCF sandbox project) across many providers, CloudFormation on AWS, Bicep and ARM templates on Azure, and Pulumi, which uses general-purpose programming languages instead of a dedicated syntax.
• Configuration tools such as Ansible, Chef and Puppet set up what runs inside machines once they exist: packages, files, services and users.
• Pipelines run both kinds automatically, planning a change, waiting for approval and then applying it, so no person needs standing rights to production.

State, drift and the console

Two problems catch every team eventually. The first is state. Terraform and similar tools keep a record of what they believe exists, and losing or corrupting that record makes the next run dangerous; stored remotely, locked and backed up, it stops being a worry. The second is drift: someone fixes an incident by hand in the console, the code no longer matches reality, and the following deployment quietly undoes the fix. The cure is cultural rather than technical. Emergency changes are allowed, but they are written back into code the same day, and a scheduled plan run reports any difference.

Beginners tend to start too big, with a module library before they have deployed one stack. Start with one small environment you can destroy and recreate in minutes, and then add the pieces that hurt: remote state, a pipeline, a policy check. The same files feed operations, since an environment described in code is also an inventory, and cost work, because tags applied in code are tags that actually exist.