Every infrastructure team owns two systems. The one described in the repository, reviewed, versioned, immaculate. And the one actually running, shaped by three years of incidents, portal clicks, and emergency fixes nobody backported.
We talk about the first. We are paged for the second.
Alfred Korzybski gave the problem its name a century ago: the map is not the territory. A representation is never the thing it represents, and confusing the two is not a small category error. It is the root of a particular kind of failure, the kind that arrives with total surprise because the map promised something the territory never agreed to.
Infrastructure as code is the best mapmaking discipline our field has produced. That is precisely why it deserves this warning.
The seduction
A good map seduces. It is legible in ways the territory never is: diffable, reviewable, beautiful in its pull requests. Over time, attention migrates toward it. We review the map, test the map, approve the map. The deployment pipeline becomes a ritual that closes with green checkmarks, and the checkmarks say: the map was applied successfully.
Notice what they do not say. Not that the territory matches. Only that the expedition went out and returned without casualties.
The better our tooling gets, the stronger the seduction. Nobody confuses a hand-drawn sketch with the coastline. A satellite photo, though, feels like the coast itself. A well-structured Terraform estate with clean modules and passing plans feels like the infrastructure. Feels.
Where the territory wins
Drift is the territory’s way of reasserting itself. Someone flips a firewall setting during an incident at 3 a.m., because that was the right call, and the backport never happens. An autoscaler makes decisions your code never described. A platform’s API deprecates a default and quietly substitutes another. A colleague clicks through the portal because the pipeline takes forty minutes and the demo is in ten.
None of these are villains. That is the point. The territory changes for reasons, usually good ones, operating on timescales the map does not observe. A state file is a photograph: honest about the moment it was taken, silent about everything since. Between refreshes, your infrastructure lives unsupervised.
And here is the trap in its purest form: the team that trusts its map most completely is the team drift damages most. Their confidence has no error bars. When the map is wrong, they do not suspect the map; they debug everything else first. The outage postmortem eventually contains some version of the same sentence: the configuration in the repository did not reflect production. The map lied, and everyone believed it, because believing it was the whole culture.
Better mapmaking, humbler mapmakers
The answer is not less mapping. Territory without maps is folklore, and operating from folklore is worse. The answer is treating the correspondence between map and territory as a thing you actively verify, not a thing you assume.
The tools exist. What-if and plan outputs, read as questions rather than formalities. Drift detection on a schedule, not after suspicion. Deployment stacks and reconciliation loops that notice when reality wanders. Policy engines that interrogate what is, not only what is proposed. Post-deployment checks that ask the territory directly: are you listening on 443, do you actually deny public traffic, does the failover really fail over.
But the tools matter less than the posture. The mapmakers worth trusting are the ones who hold their maps loosely: who treat every green pipeline as a claim pending verification, every state file as aging news, every “the code says” as the opening of an investigation rather than its conclusion.
The next time your map and your monitoring disagree, notice your first instinct. If it is to doubt the monitoring, the map has already claimed you.
The map improves until you forget it is one. That is when the territory sends a reminder, and its reminders are never gentle.
Leave a comment