Why Infrastructure as Code

Every infrastructure built by clicking around a console becomes a snowflake: nobody knows all the settings that made it work, nobody can rebuild it, and the person who clicked has left the company. IaC exists because that story ends badly at 2 a.m.

The properties that matter

• Declarative: you describe the end state ("an SG allowing 443 from anywhere"), the tool computes the steps. Imperative scripts drift from reality; declarations converge to it.
• Reviewable: an infra change is a diff in a PR — reviewable like code, with history and blame.
• Repeatable: a second environment is a variable change, not a week of console archaeology.
• Self-documenting: the config IS the architecture documentation — always current because it's the thing that built it.

Terraform's lane

Cloud APIs are vendor APIs — every provider speaks a different dialect. Terraform's provider model normalizes them behind one declarative language (HCL): AWS, Cloudflare, GitHub, Postgres, Kubernetes — all become resources in one dependency graph. The alternatives (Pulumi's real languages, CDK's constructs, Ansible's procedural bent) trade the same space; Terraform is the boring majority choice and ecosystem gravity matters.

The honest costs

• State management is real work — losing or corrupting state is the classic Terraform incident.
• Clicked-out-of-band changes (console edits) drift reality from code — drift detection is part of the discipline.
• The first migration from clickops to Terraform is painful: importing existing resources is honest but tedious work.

Field notes

• IaC's value shows at rebuild time, not build time — judge it by "can we recreate this environment in an hour?"
• Start with what's already broken/rebuildable, not the production DB nobody dares touch.
• Code reviews catch infra bugs that console clicks hid — that's the point.