Infrastructure written down, version controlled and repeatable

What this actually solves

Infrastructure built by hand is infrastructure nobody can explain. The cloud console makes it easy to create a machine, attach a disk, open a port, add a rule — and it records none of the reasoning. Six months later there is a security group with an unexplained allowance in it, and the two possibilities are that it is load-bearing or that it is a hole. Nobody knows which, so it stays. That pattern repeats until the environment is a collection of settings that exist because they exist.

Then somebody asks for a staging environment that behaves like production. This is the moment the real cost lands. Nobody can build it, because nobody has a complete list of what production consists of. The nearest approximation is assembled by clicking through the console and comparing screens, and it is subtly different in ways that will only reveal themselves when a deployment behaves differently in the two places.

Writing infrastructure as code changes what the environment is. It becomes a set of files in your repository, with a history, an author on every line and a review before every change. It can be diffed, rolled back and rebuilt. And critically it stops being a hostage to one person — the value of an engineer who is the only one who knows how the network was configured is not loyalty, it is risk.

How the work runs

1. Import reality before writing anything aspirational. Every existing resource is described in code and imported into state until a plan against production proposes no changes whatsoever. That clean no-op plan is the proof that the code and the running world match, and it is the real deliverable of this phase. Three to seven days.
2. Put the state somewhere safe and locked. State goes into a remote backend with versioning and locking enabled, never into the repository — it holds resource identifiers and often secret values in plain text, and two people applying at once against a local file will corrupt it. Access to the backend is restricted separately from access to the code. One to two days.
3. Refactor into modules and environments. The repeated pieces become modules with inputs. Development, staging and production become the same code with different variable files, so a difference between environments is a visible line in a file rather than a surprise. Naming and tagging conventions go in here, because they are what makes the billing readable later. One to three weeks.
4. Wire it into the pull request. A plan runs automatically on every change and posts its output where reviewers can read it, so the discussion happens over what will actually change rather than over intentions. Apply is gated behind approval and runs from the pipeline using its own credentials, not from a laptop. Three to five days.
5. Prove it rebuilds, then prove it detects drift. A disposable environment is created from the code, checked, and destroyed. A scheduled plan runs against production and reports when the running world has diverged from the code, which is how manual console changes get caught in days instead of at the next incident. Two to four days.

What moves the price

How much already exists. Greenfield is faster because there is nothing to reconcile. Importing a mature environment is detective work — every resource has to be found, described, imported and verified, and the ones nobody remembers creating take the longest.

How many environments and providers. One environment on one provider is a contained piece of work. Three environments, two providers and a DNS provider on top means more modules, more state separation and more variables to keep honest.

What Terraform is allowed to own. Networking and compute are straightforward. Bringing databases, DNS and identity permissions under management is more valuable and demands more care, because those are the resources where a careless change is not recoverable by running apply again.

What usually goes wrong

The state file ends up in the repository. It looks like just another project file and it is not — it contains resource identifiers and frequently plaintext secrets, so committing it hands credentials to everyone with repository access. Worse, a state file on individual laptops means two engineers can apply simultaneously and produce two irreconcilable records of what exists, after which Terraform will happily propose creating things that are already there.

An innocuous attribute change forces a replacement. Certain properties cannot be altered in place, so Terraform's answer is to destroy the resource and create a new one. On a security group that is fine. On a production database it is the end of the business. The protection is boring and non-negotiable — stateful resources kept in their own state, marked so they cannot be destroyed, and a plan that is read rather than skimmed.

Nobody reads the destroy count. The plan output states exactly how many resources will be added, changed and destroyed, on one line, before anything happens. It is the single most useful sentence in this entire tool, and after a few weeks of routine changes people stop reading it and type yes. Almost every destructive Terraform accident is printed in full on the screen immediately before it happens.