In 30 seconds
- Infrastructure is described in code and stored in version control.
- Environments can be created, changed and rebuilt automatically.
- Makes environments consistent and changes reviewable.
How it works
Instead of clicking through a console, teams write files describing the infrastructure they want. Tools read the files and create or update the real thing. Changes go through review and version control like application code.
Declarative vs imperative
| Declarative | Imperative | |
|---|---|---|
| You write | The desired end state | The steps to get there |
| Examples | Terraform, CloudFormation | Scripts, some Ansible usage |
Benefits and pitfalls
- Benefits: repeatable environments, audit trail, faster recovery, fits continuous delivery
- Pitfalls: manual changes that drift from the code, secrets stored in files, untested infrastructure changes
Myth vs reality
Myth · IaC is only for the cloud.
Reality · It works for on-premises systems too.
Myth · Writing it once is enough.
Reality · Code must be maintained as needs change.
Myth · IaC removes the need for operations skills.
Reality · It changes how those skills are applied.
FAQ
What's configuration drift?
When real infrastructure no longer matches its code.
Should IaC be tested?
Yes, with validation, plans and test environments.
How does IaC relate to containers?
Containers package apps; IaC provisions where they run.