Infrastructure as Code
Environments that came from a definition, not from somebody's memory.
"It works on staging" is a symptom
When staging and production behave differently, it is almost never a mystery. Somebody changed one of them by hand, months ago, for a good reason nobody wrote down. Every hand-made change is a small debt, and they are only ever collected at the worst moment.
Defining the infrastructure instead means the environments come from the same reviewed source, the differences between them are deliberate values you can point at, and rebuilding one is a routine run instead of a rescue operation.
This is how we build the cloud foundation itself, and what makes security and monitoring consistent from test through to production.
Four ways we get brought in
The second is the one most estates need, and the one most often put off.
A new environment from the start
Defined as code from the first resource, so there is never a hand-built original to compare against.
Bringing what exists under code
Importing infrastructure built by hand, so the definition describes what is actually running.
A test environment worth trusting
Somewhere that genuinely resembles production, built and destroyed on demand.
Making changes reviewable
Infrastructure changes proposed, read and approved the way code changes are.
What good looks like
Modules, used unmodified
Shared building blocks that every environment consumes without editing the source. If an environment needs something different, it passes a different value, and that difference is then visible in one place.
No secrets in the definition
Passwords, keys and connection strings live in a vault and are referenced, never written into the files. The code can then be read by anyone who needs to review it.
Writing and applying are separate acts
A change is proposed and reviewed as a change. Applying it to a live environment is a deliberate, human step, not something that happens as a side effect of a commit.
What lands on your desk
- Your infrastructure, defined and in your repository
- Readable by your team and not dependent on us.
- Environments that can be rebuilt
- Which is disaster recovery you have actually rehearsed.
- A change process
- Where the plan is visible before anything happens.
- The list of what we found
- Because bringing a hand-built estate under code always turns something up.
We build a copy of the customer's systems, in code
On our most recent Azure build, every environment is defined in Terraform through shared modules that each one consumes without editing. The part worth knowing about is the test environment: rather than reaching into the client's estate to test an integration against it, we define a stand-in for it, in code. A database, a file share, a file-transfer endpoint and a network, built to order and seeded with data, then thrown away. It means the integration is exercised end to end against something shaped like the real thing without anyone touching the real thing. Secrets are never in the definition, only referenced from a vault, and applying a change to a live environment stays a deliberate human act.
Common questions
We already have scripts. Is that the same thing?
Not quite. A script says how to build something once; a definition says what should exist, and can be re-run against what is already there without doing damage. The difference shows up the day you need to change one thing on a Friday afternoon.
Can you bring existing infrastructure under code without rebuilding it?
Usually yes, and it is a common piece of work. Existing resources get imported so the code describes what is genuinely running. Expect the first pass to turn up two or three things nobody knew were there.
Who is allowed to apply changes?
Whoever you decide, and the point is that it becomes a decision with a name on it. On our own work, changes are written and reviewed separately from being applied, and the apply is a deliberate human act.
What about the things that must differ between environments?
They differ as inputs, not as edited copies. Production is bigger and locked down harder than staging, but both come from the same definition with different values. The moment a copy gets edited, the two start drifting and nobody can tell you how far.
Does this help with disaster recovery?
It is most of it. A recovery plan you have never run is a document; a definition you can rebuild an environment from is a rehearsal you can actually do, which is the difference between knowing it works and hoping.