What you will take away
- The value is the review and the repeatability, not the syntax.
- State is the crown jewel - remote, locked, backed up, never hand-edited.
- Console changes are the enemy of any codified environment.
What changes when infrastructure is code
Three things. Environments become reproducible, so staging genuinely resembles production instead of approximately resembling it. Changes become reviewable, so a firewall rule gets the same scrutiny as a code change. And the configuration becomes documentation that cannot go stale, because it is the thing that runs.
The recovery story alone justifies it. Rebuilding a hand-configured environment after a serious failure is an archaeology exercise; rebuilding a codified one is a command and a wait.
Choosing between the two
Terraform uses a declarative configuration language, has the largest provider ecosystem, and is the safer default when several teams and contractors will touch the code, because the skill is common and the files are hard to make clever.
Pulumi lets you define infrastructure in a general-purpose language, which suits teams who want real abstractions, types and unit tests around their infrastructure. The trade is that a general-purpose language permits complexity, and infrastructure code that is hard to read is a genuine operational risk.
Pick the tool your on-call engineer can read at three in the morning. That constraint decides more than feature comparisons do.
Structure that survives growth
- One state per environment and per bounded area - a single global state makes every change a whole-estate risk.
- Remote state with locking, versioning and backups. Never local, never hand-edited.
- Modules for the patterns you repeat, kept small and versioned, with the composition left visible.
- Environment differences expressed as variables, not as copied directories that drift.
Drift, and the console problem
The most common way an infrastructure-as-code setup rots is a change made in the cloud console during an incident and never brought back into code. The next apply either reverts it, causing a repeat outage, or fails confusingly.
Restrict console write access to break-glass accounts, detect drift on a schedule rather than at apply time, and make reconciling an emergency change part of closing the incident. The rule that works is simple: if it was not applied by the pipeline, it is not finished.
Policy in the pipeline
Because infrastructure is now code, it can be checked before it exists. Policy rules can refuse a publicly readable storage bucket, an unencrypted volume, an untagged resource or a security group open to the world - at the pull request, where fixing it is trivial.
Show the plan output in the review and require approval for changes that destroy resources. Most infrastructure incidents are not exotic; they are an approved change whose blast radius nobody read.