We’ve removed the dev/ops wall. But the dev/infra wall remains.
DevOps has taken us a long way. Fifteen years ago a 6-month cycle for releasing software was considered pretty good. These days it’s considered pretty poor. But infrastructure is still a bottleneck for most teams releasing software. In most engineering organizations beyond a fairly small size, developers rely on another team to manage infrastructure for them.
Tools like Pulumi and CDK aimed to solve this by allowing developers to write infrastructure code in a familiar programming language, so they wouldn’t need to rely on specialists to do it for them. But it turns out that YAML and HCL aren’t the real obstacle. Knowing how to wire low-level infrastructure resources like network routes, security groups, gateways, and SSL certificates together to do something useful takes time and expertise.
Developers who gain this expertise and write the infrastructure code for non-trivial systems turn into infrastructure specialists. Some are happy to take that journey, many would prefer to focus on the software.
Platform engineering, Developer Experience, and a handful of other fairly recent movements aim to empower developers by making the software delivery fully self-service. But often, these names are applied to teams which still work by hand-coding infrastructure. Developer workflows for getting code into production still involve waiting for someone else to make changes to networking, databases, or compute clusters. I’ve previously described this antipattern as infrastructure management teams.
Better tools for infrastructure experts only reinforce the wall.
Then there’s an emerging genre of tools that aim to solve the problems with Infrastructure as Code. Their creators believe that the biggest obstacle that needs to be removed is the clunkiness of managing code files in git and coping with the drift between code and deployed infrastructure. I have written about potential successors to Infrastructure as Code, including Infrastructure as Model tools like System Initiative.
System Initiative spent the last 6 years building their contender for the future of infrastructure automation. Rather than code, it represented infrastructure resources as a graph that could be dynamically manipulated by whatever extensions or integrations you chose to build.
Nobody wanted it.
One theory of why System Initiative struggled for adoption is that their approach was “too weird.” But I believe the real issue was there wasn’t a strong value proposition. System Initiative was another tool for infrastructure experts to manage infrastructure for developers. If you need to wait a week for the platform team to set up the new environment, it doesn’t matter that they don’t need to edit YAML files. The wall remains.
The next generation of infrastructure tools is for developers.
What we need is to empower developers to build and manage their own infrastructure. A developer should be able to specify what they need in terms that are relevant to the problem they’re solving. “I need this service to accept inbound HTTPS connections from the public Internet.” “I need an SQL database instance to store private user data, configured for security, availability, backups, and regulatory compliance.”
There was a brief moment back when DevOps was new where “NoOps” was a hot topic. The term has faded, partly because people read it as declaring ops and infra specialists to be obsolete. If developers are going to be whipping up databases and network connectivity, someone needs to provide the frameworks to ensure that what gets deployed complies with policies and governance.
The real point of NoOps was that ops folks should provide tools and systems that remove themselves completely from the developer’s workflow. And that point is more relevant than ever.
The System Initiative team has shut down their original product and is pivoting to something that seems aligned with that point. Their founder, Adam Jacob, recently gave a talk where he shared his epiphany about what comes next. His message is that the increase in software development velocity from AI is going to force ops to follow, like it or not.
Adam and his team gave me an early build of their new product, swamp. Swamp is a command-line tool designed to be understood and run by AI coding agents like Claude Code, so it fits naturally into the developer’s workflow.
I don’t know whether swamp itself will become the next big thing. Tools like Pulumi Neo are converging on a similar model. Especially for organizations using agentic development, bringing infrastructure management into the agent, embedded into the way developers build their software, has the potential to finally remove the dev/infra wall.
Photo by Navy Medicine on Unsplash
