Infrastructure as Code (IaC) means treating infrastructure the way you treat application code: it is described in text files, kept in git, reviewed in pull requests and applied by a tool, not by clicks in a console.
What changes in practice:
- Reproducible: the staging and production environments come from the same file, so they stay the same (unless someone changes things by hand).
- Auditable: the git history tells who changed what, when and why.
- Reviewable: a firewall change goes through the same code review as a code change.
- Recoverable: if a region or an account is lost, the environment is recreated from the files.
There are two styles:
| Style | You describe | Examples |
|---|---|---|
| Imperative | The steps: “create a VM, then open port 443” | Scripts using the cloud CLI, most of Ansible |
| Declarative | The result: “I want a VM with port 443 open” | Terraform, OpenTofu, CloudFormation, Kubernetes manifests |
In the declarative style, the tool compares what exists with what was described and works out by itself what to create, change or destroy. This makes applying idempotent: running the same file twice creates nothing duplicated.
The main risk is drift: someone changes a resource directly in the console and reality no longer matches the code. The rule that prevents it is easy to state and hard to keep: once a resource is in the code, it only changes through the code.
See it in practice: Terraform and Kubernetes.
- Read more: Infrastructure As Code | Martin Fowler