Infrastructure as Code: Why It Is Worth the Setup

What you actually gain

• Reproducibility. A second environment is a variable change, not a week of clicking.
• Review. Infrastructure changes go through pull requests, so someone else sees them before they happen.
• History. Git tells you what changed, when and why. Console changes leave an audit log entry and no reasoning.
• Disaster recovery. Rebuilding a region becomes running a plan rather than remembering a configuration.
• Documentation that cannot drift, because it is the thing that creates the infrastructure.
• Consistency. Staging genuinely matches production, which removes an entire class of bug.

Review is the one teams underestimate. A security group opened to the world is easy to click and hard to miss in a diff.

The tools

Terraform and its fork OpenTofu are the practical default: one tool covering every provider in this catalogue, with an enormous body of existing modules and answers.

State is the concept that trips people up

Terraform keeps a state file mapping your code to real resources. It is how the tool knows the difference between creating something new and modifying something existing.

1. Never keep state on one person’s laptop. It will be lost or diverge.
2. Store it remotely — object storage with versioning enabled.
3. Enable locking so two people cannot apply simultaneously.
4. Treat state as sensitive; it can contain secrets in plain text.
5. Split state per environment, so a mistake in staging cannot touch production.

Most Terraform disasters are state disasters. Getting this right at the start avoids nearly all of them.

Adopting it on infrastructure that already exists

You do not have to start over:

1. Write code for something new first, so the workflow is established on low-stakes work.
2. Import existing resources gradually, starting with stable ones such as networks.
3. Use import blocks or generation tooling rather than transcribing by hand.
4. Verify with a plan that shows no changes — that is the signal your code matches reality.
5. Once a resource is in code, stop changing it in the console.
6. Accept that some legacy resources may never be imported. Partial adoption is still valuable.

Practices that keep it maintainable

• Modules for repeated patterns, but do not abstract prematurely. Duplication is cheaper than the wrong abstraction.
• Separate state per environment, with the same code and different variables.
• Pin provider versions, or an upgrade will surprise you mid-deploy.
• Run plan in CI on every pull request, and post the output on the PR.
• Apply from CI, not from laptops, so there is one path and one audit trail.
• Never store secrets in code. Reference a secret manager.
• Tag everything through a default tags block, so cost allocation works automatically.

Where it is genuinely awkward

Worth knowing before you commit:

• The learning curve is real, particularly around state and dependency ordering.
• Some resources are slow to create, so plans and applies can take a long time.
• Provider bugs and gaps exist, occasionally requiring a manual workaround.
• Drift happens when someone changes something in the console, and reconciling it is tedious.
• Destroying the wrong workspace is catastrophic and entirely possible. Use protection flags on critical resources.

None of these outweigh the benefit on an estate of any size, and all of them are worse without it.

Common questions

Where to go next

See cloud-init and server automation and CI/CD pipelines.