Infrastructure as Code (IaC) vs Manual Deployment: Why IaC Isn’t Always the Answer

Infrastructure as Code is the default answer for cloud infrastructure now, and mostly for good reasons. It is not the right answer every time, which is the part nobody puts in the sales deck.

This post covers both sides. What IaC gives you, and the situations where clicking through a portal is the better call.

What IaC is, and what you would use

You describe your infrastructure in files. Servers, networks, databases, permissions. A tool reads those files and makes reality match them.

The tooling has shifted since we first published, so here is where it stands.

Terraform is still the most widely used. HashiCorp moved it to a source-available licence in 2023, which prompted a fork called OpenTofu. OpenTofu is now a Linux Foundation project and a drop-in replacement for most people. Which one you choose matters mainly if you are a software vendor, or your procurement team reads licences properly.

On Azure, Bicep has largely replaced hand-written ARM templates. It compiles down to ARM, so it is the same engine with a fraction of the JSON. If anyone on your team is still writing ARM by hand, that is the easiest win available.

AWS has CloudFormation and the CDK. Pulumi lets you write infrastructure in a real programming language, which suits teams who were developers first. Ansible sits slightly to one side, better at configuring things that already exist than at creating them.

What it gives you

Consistency, because the same file produces the same result every time. Version control, so you can see who changed what and put it back. Speed, once the code exists.

And a kind of documentation that cannot go stale, because the environment is built from it. That last one is badly undervalued. A network diagram is out of date the week after you draw it. Terraform code cannot be.

When clicking is fine

Five situations where we would not bother.

Small, static setups. A couple of virtual machines running a web server that barely changes. Writing, testing and maintaining the code costs more than the thing it manages.

One-off environments. A client demo, or a proof of concept that gets deleted in a fortnight. IaC pays you back through repetition and there is none here.

Teams without the skills. There is a real learning curve, and half-learned IaC is worse than none. A corrupted state file at the wrong moment turns into a very long afternoon.

Genuinely unusual environments. Some setups are strange enough that expressing them in code costs more than it returns. This is rarer than people claim and it is often an excuse, so be honest about which one you have.

Infrastructure that truly never changes. The code still needs maintaining as providers update, so you would be paying to look after code that buys you nothing.

When it is clearly right

Anything you will build more than once. Anything with more than one environment, because dev, test and production drifting apart is the exact problem IaC was invented to solve.

Anything that changes often. Anything that has to be rebuilt in a hurry after a failure. Anything moving through a CI/CD pipeline, where a manual step becomes the bottleneck for everything behind it.

Compliance work belongs on this list too. When an auditor asks what was deployed and when, code in version control answers in seconds.

The middle ground people miss

You do not have to make one decision for everything you own.

Plenty of environments run networking, identity and the shared platform as code, and leave a handful of one-off resources to the portal. That is a reasonable design rather than a failure of nerve.

What does not work is pretending. If half your environment is code and half is clicked, write down which is which. The worst outcome here is an engineer trusting the code and finding that somebody changed the portal underneath it.

How to decide

Ask how many times you will build this thing. Once, and click it. More than a few times, or across more than one environment, and write it down as code.

Then ask who maintains it once the person who wrote it has moved on. If there is no answer to that, sort it out before you start.

Element Digital offers IT consulting services in Hobart. If you want a hand deciding what to automate and what to leave alone, get in touch.