Infrastructure as Data
I gave this talk at DevOpsDays London 2026.
I’m Laurence, I run SRE at Kevel. The idea I want to talk to you about today is that if you treat infrastructure as data, you can test things that don’t exist yet.
In software we get plenty of chances to exercise our code before production. In infrastructure we hope we’ve got a decent pre-prod, and the plan is worthless beyond listing the API calls it’ll make.
Part of the reason is where state lives. It’s a JSON blob, wherever you put it, even in the Postgres backend, and there isn’t a great deal you can do with a blob.
Each dot is a resource, and each circle is a state snapshot. Some are misconfigured, some are managed in two places at once, and plenty aren’t managed at all, which never really goes away.
We can start to fix this by storing both the desired state and the actual state somewhere easy to query, like a database, where every resource is an entity and every attribute and relationship is a fact.
It’s append only, so we keep the history and can audit it. It’s a graph, so we can follow relationships. It’s temporal, so we can look back. It’s speculative, so we can try things before committing.
A sample architecture. Terraform still makes every change, its state lives in a database, and a worker syncs the cloud’s view in. The CLI in front is where we run our own checks. I’ve got four.
So, some problems we can solve now. First, searching our infrastructure for dangerous rules. A toy example, looking for firewall rules that let an attacker straight in. Row four is the sneaky one.
If we can detect a problem, we can also prevent it. Take the proposed change, write it into a draft state, and run the same check statically against that, before anything is applied.
There’s a fun terraform feature called authoritative resources, which can quietly destroy or change things you didn’t intend to. Plan looks fine, apply looks fine, and then the alarms go off. How do we catch it?
Because we have the cloud state too, we can pull the same trick again. We know how authoritative resources behave, so we can simulate the apply and see the blast radius, nine roles in this case.
Here’s one I’m sure a lot of us have burned time on. It looks easy drawn out like this. In reality it’s reachability analyzers, route tables and security group rules. With a graph, it’s a search problem.
And with some ancient technology from the 1970s, we can ask a more useful question. What do I need to change to make these two talk to each other? One route, it turns out.
A common job for us is a zero downtime deploy, so here’s a toy example. We want to get v2 of this service serving traffic without ever dropping any of it.
This is an example of how not to do it. Deregister, stop, start, register, and for three steps nothing is serving. There are twenty three wrong ways to do this.
We know where we want to start and where we want to end up, and we know that something always has to be serving. That’s everything the solver needs.
The solver is more ancient technology that searches this space efficiently. It works through the orderings, throws out the ones that break the rule, and in this case there’s one left.
So now we have something that can make a change without breaking things, or tell us that what we’ve asked for is impossible. It’s a toy example, but this approach scales.
So here’s my proposal. None of this is new, and we deserve tools that stop us making mistakes that were always avoidable. We just have to start treating infrastructure as data.
Thank you for listening. I’m working on this problem in the open, the code is on GitHub, and these slides and the transcript are on my website.