PlanetformPlanetform
Back to blog

Infrastructure as Durable Execution (IaDE) - Part 2 of 8

The Wrong Mental Model

The feeling of completion after an apply is one of the most expensive illusions in modern infrastructure. We built an entire industry around it.

There is a moment every infrastructure engineer knows.

In this context, infrastructure engineering encompasses the practitioners in the trenches: the SREs, DevOps engineers, Platform engineers, and more, responsible for the stability of the stack.

The pipeline goes green. The apply completes. The terminal returns a prompt. And for a brief, quiet moment, everything feels done.

It is not. It never was.

That feeling of completion is one of the most expensive illusions in modern infrastructure. And we built an entire industry around it.

Infrastructure Modeled After Deployment

When Infrastructure as Code (IaC) emerged, it solved a real and urgent problem: human consistency. Manual provisioning was slow, error-prone, and impossible to audit. Codifying infrastructure intent into version-controlled files was a genuine leap forward.

But the model we chose was borrowed from software deployment. Write the code. Run the command. Observe the output. Move on.

That model makes sense for shipping an application. The binary either runs or it does not. The release either ships or it rolls back. The state space is relatively bounded.

Infrastructure is not a deployment. It is a living system.

It does not sit still after the command exits. It evolves through human intervention, system failure, API inconsistency, expired credentials, clock drift, hardware replacement, and a thousand other forces that have nothing to do with your last commit.

Treating infrastructure like a deployment is the wrong mental model.

And wrong mental models are expensive not because they fail immediately, but because they fail slowly, in ways that are hard to trace back to the original assumption.

The State File Is a Symptom

The state file was a clever solution to a real problem. If a tool provisions resources and wants to know what it previously created, it needs to store that information somewhere.

So we stored it in a file.

The state file works. Until it does not.

Until someone provisions something manually and forgets to import it. Until two execution paths touch it concurrently. Until it becomes the wrong copy of the truth. Until the environment drifts so far from the file that reconciliation becomes archaeology.

Every one of these failure modes is a symptom of the same root cause:

The state file assumes that what was last applied is what currently exists.

It is a record of intention, not a record of reality.

In a static world, those two things would be the same. We do not operate in a static world.

Declaration Is Not Durability

IaC solved the declaration problem. It gave us a way to describe what infrastructure should be.

It did not solve the durability problem.

Durability is the problem of maintaining declared intent against a real environment over time. Against drift. Against interruption. Against partial failure. Against the ordinary entropy of distributed systems.

This is where the gap opens.

We built powerful languages for declaration. We did not build an execution model that treats durability as a first-class concern.

Observation Is the Only Source of Truth

Here is the shift that changes everything:

The environment is the source of truth.

Not the file. Not the last apply. Not the pipeline log. The environment.

This sounds obvious when stated plainly. Of course what actually exists matters more than what we think exists. But very little tooling is built around this premise. Most tools treat the environment as something to be acted upon, not listened to.

The result is predictable: operators spend enormous energy resolving the gap between what the tools believe and what the environment actually is.

That gap is not an edge case. It is the natural consequence of building tools that stop observing the moment they finish acting.

A system built on continuous observation does not need to reconstruct truth from stale records. It keeps refreshing truth from the environment itself.

Apply Is Not the End. It Is the Beginning.

The shift required is not just technical. It is conceptual.

Deployment ends. Infrastructure does not.

When we treat apply as a terminus - the final step in a pipeline, the command that makes things done - we are optimizing for the wrong moment. The moment of apply is easy compared to everything that follows it.

The hard work is maintaining correctness over time, through change, through failure, through the ordinary noise of real systems.

Success is not a green pipeline.

Success is a system that remains correct.

Not once. Continuously. Durably.

The Operator Should Not Be the Integration Layer

The infrastructure engineer who spends their day reconciling what tools believe against what environments contain is not really doing infrastructure work. They are doing integration work - filling the gap between a model and reality with their own memory, judgment, and effort.

That is an expensive use of human expertise. It is also unsustainable as systems grow more complex and the rate of change accelerates.

The tools should close that gap.

Not the operator.

That requires a different execution model - one where observation is continuous, correction is normal, and the operator is freed to define intent rather than manually reconcile drift.


What's Next

The next post examines a second consequence of the same broken model - and why the silos between configuration, policy, and compliance keep producing different truths.

A Series in 8 Parts

Infrastructure as Durable Execution (IaDE)

Part 3 of 8-Coming Soon
Part 4 of 8-Coming Soon
Part 5 of 8-Coming Soon
Part 6 of 8-Coming Soon
Part 7 of 8-Coming Soon
Part 8 of 8-Coming Soon

Subscribe to receive each part as it publishes. No spam. Unsubscribe anytime.