Infrastructure as Code is a Maintenance Tool

How We Started Studying the Tools Instead of the Principles

Every day I see DevOps posts in my feed. Often, they’re quizzes.

“Which DevOps practice focuses on automated infrastructure provisioning?”

The expected answer is Infrastructure as Code (IaC). And technically, that’s the answer they’re looking for.

But it’s also the wrong question.

Infrastructure as Code does not exist because someone wanted automated infrastructure provisioning. Automated provisioning is a useful consequence, certainly, but it isn’t the reason.

The reason is that manual infrastructure creates friction, inconsistency, risk, and delay. The reason is that typing commands into production servers at 2:00 AM does not scale. The reason is that nobody wants critical infrastructure to exist only in someone’s memory. Infrastructure should be treated like every other important system artifact: versioned, reviewed, documented, maintained, and improved.

More than a decade ago, I gave a talk on what I called the Three R’s of DevOps. The years haven’t changed my opinion. In fact, I think they explain Infrastructure as Code better than “automated provisioning” ever could:

Repeatability. Reproducibility. Reliability.

If I can describe an environment as code, I can create it repeatedly. If I can create it repeatedly, I can reproduce it. If I can reproduce it consistently, I have a much stronger basis for trusting it. And once I have those things, automated provisioning naturally follows.

But provisioning was never the point.

There’s another benefit that gets overlooked: memory.

Infrastructure as Code is documentation. It captures decisions, records intent, and makes maintenance possible. It allows the next engineer to understand not just what exists, but how it is supposed to exist. Done well, it can preserve some of the reasoning that created the environment in the first place.

Long after the original author has moved on, the infrastructure does not have to depend entirely on institutional memory.

That matters far more than whether a server can be provisioned with a single command.

In fact, I would argue that Infrastructure as Code is primarily a maintenance tool that happens to automate provisioning. Provisioning is something you do occasionally. Maintenance is something you do for years.

Asking what IaC “focuses on” is a little like saying source control focuses on creating commits. Commits are the mechanism; managing change is the purpose. Saying testing focuses on generating coverage reports makes the same mistake. Coverage is a mechanism; confidence is the purpose. Saying monitoring focuses on dashboards confuses the artifact with the goal. Dashboards are a mechanism; visibility and understanding are the purpose.

Infrastructure as Code is no different.

Code is the mechanism. Repeatability, reproducibility, reliability, maintainability, reviewability, and understanding are the purpose.

The same mistake happens all over the industry. Testing gets reduced to code coverage. Monitoring gets reduced to dashboards. CI/CD gets reduced to pipelines. DevOps gets reduced to tools.

We’ve become so focused on the implementation that we’ve forgotten the intent.

DevOps was never about Terraform, Jenkins, GitHub Actions, Kubernetes, or whatever tool happens to be fashionable this quarter. Those tools are useful. Some of them are excellent. But DevOps is not a collection of tools.

It is not a certification path. It is not a quiz answer. And it is not a job title.

DevOps emerged because organizations were struggling to deliver value. Development and operations were optimized around different goals. Work moved slowly. Feedback arrived late. Risk accumulated. Customers waited.

The goal was to remove barriers between an idea and the value it could create. Everything else was in service of that goal.

Infrastructure as Code helps because it reduces friction. Automation helps because it reduces friction. Testing helps because it reduces friction. Documentation helps because it reduces friction. Maintainability helps because it reduces friction.

Even practices that seem unrelated often exist for the same underlying reason: making it easier, safer, and faster to deliver value.

That’s why I find many DevOps quizzes frustrating. Not because the answers are necessarily wrong, but because they often train people to memorize practices without understanding the principles that created them.

We’ve started studying the tools instead of the principles.

And when that happens, practices become rituals. People know what to do, but they stop understanding why they’re doing it. Once the context changes—or a new tool arrives—they have no principle to reason from. They only have the ritual.

So the next time someone asks which DevOps practice focuses on automated infrastructure provisioning, I would answer differently.

Infrastructure as Code focuses on making infrastructure repeatable, reproducible, reliable, maintainable, reviewable, understandable, supportable, and sustainable over time.

Automated provisioning is what happens when you do that well.

And DevOps?

DevOps focuses on delivering value to customers. Everything else is a means to that end.

Mechanism is not purpose.

And when we forget the difference, we start optimizing for the tool instead of the outcome.