Before you invest in infrastructure as code

Most teams know this matters. Fewer have decided who owns it. Before you spend anything on infrastructure as code, it is worth confirming a few things are already true.

The bill is a design document: it tells you exactly what your architecture actually does. If two people in the business would answer this differently, that gap is the actual problem.

Prerequisites

• You can describe the outcome you want in one sentence
• Someone owns it after the work is done
• Clicking around a console is not a reproducible environment
• You have a way to tell whether it worked

Where it usually goes wrong

Review infrastructure changes the same way you review code. The reasoning matters more than the rule, because the rule has exceptions. Write the reasoning down alongside the decision, because the reasoning is what changes first.

Rebuilding from scratch should be a routine operation. That sounds obvious written down. It is still the thing most often skipped. It is the sort of thing that looks like polish right up until it costs you an enquiry.

What this looks like day to day

Cloud work rewards teams who automate early and punishes teams who click through consoles. Three things worth confirming about infrastructure as code before you move on:

• Someone can say what the current setup is without going to look
• Clicking around a console is not a reproducible environment — and you know whether that is true here
• There is a way to tell whether the last change to this helped

If you want a second opinion on how yours is set up, ask.