I've been in this industry long enough to remember when we thought we were solving everything.
Back in 2011, when I started Salt, the promise was simple: automation would set us free. We'd write some configuration management code, deploy it, and our infrastructure problems would melt away. We'd finally have time to work on the interesting problems instead of the repetitive ones.
Fast forward to today, and I find myself having the same conversation over and over again with infrastructure teams. They're drowning, they have more tools than ever before, more automation than ever before yet somehow, they're working harder than they ever did.
How did we get here?
Here's what happened: we automated everything, but we didn't automate the right thing.
Think about the modern infrastructure stack. You've got Terraform managing your infrastructure as code; Kubernetes orchestrating your containers; Salt or Ansible or Chef or Puppet managing your configuration; CI/CD pipelines stitching it all together. Then you have Prometheus and Grafana watching everything. And that's just scratching the surface.
Each one of these tools promised to make your life easier and individually they kind of do. But here's the problem nobody talks about: now you're maintaining all of them.
You're not managing servers anymore, you're managing the automation that manages the servers. You're debugging YAML. You're version-controlling your infrastructure definitions. You're writing tests for your Terraform modules. You're troubleshooting why your Helm chart won't deploy. You're explaining to your team why the CD pipeline failed at 3 AM.
I call this the DevOps Paradox. We set out to eliminate toil, and instead we created a new category of toil: automation maintenance.
Let me paint you a picture. I was talking to a platform engineering team at a mid-sized company last month, they have five engineers. Do you know how many lines of infrastructure-as-code they're maintaining? Over 50,000 lines. Terraform, Helm charts, Kubernetes manifests, CI/CD configurations, monitoring definitions.
One of them told me something I'll never forget: "I spend more time debugging our automation than I ever spent manually deploying servers."
And here's the kicker: they can't stop. If they tried to go back to manual deployments now, they'd be buried. Their application teams deploy dozens of times a day. The automation they built enables that velocity but it also traps them in a cycle of endless maintenance.
It's like they built a high-performance race car, and now they spend all their time under the hood keeping it running instead of actually racing.
The DevOps movement was supposed to break down silos, instead, we've created new ones.
Now companies have Platform Engineers, DevOps Engineers, SREs, Infrastructure Engineers, Network Engineers, and Security teams. Each with their own specialty in a different automation tool or platform. The irony is thick: we wanted to make developers more self-sufficient, and instead we built an entire new layer of specialists to maintain the automation infrastructure.
I hear this all the time: "We need another DevOps engineer because nobody else understands our Terraform setup." Or: "Our SREs are the only ones who can touch the Kubernetes configs." Or my personal favorite: "We had a two-hour outage because the person who wrote that Salt script left the company six months ago."
There's a fundamental problem here. We've taken the complexity of infrastructure and encoded it into thousands of lines of configuration code, then we wonder why it takes specialized knowledge to work with it.
Here's what I think happened, and I take some responsibility for this. The first wave of automation tools, Salt included, were built to solve a specific problem: "How do I manage 1,000 servers without losing my mind?"
We succeeded at that. But then we kept building. We kept adding features. We kept making them more powerful and more flexible. We assumed that more capabilities meant better solutions.
What we didn't realize is that we were optimizing for the wrong thing. We were optimizing for power and flexibility when we should have been optimizing for simplicity and intelligence.
Think about it. When you use Terraform, you're explicitly telling it every single resource you need. Every subnet, every security group, every load balancer rule. You're encoding your entire infrastructure topology into code, then you're maintaining that code.
But why? Why should you have to explicitly define that your application needs a database? Why should you have to manually configure network security groups? Why should you have to write separate code for development, staging, and production environments?
The promise of automation was supposed to be: "Tell me what you want, and I'll handle the how." Instead, we got: "Tell me exactly how to do everything, and I'll do it consistently."
That's not automation. That's scripting with better error handling.
I say this with love, because I was a sysadmin. I spent years SSHing into servers, manually installing packages, editing config files. Those were good days in many ways.
But when we built our automation tools, we built them to replicate what we did manually. We have all said “don’t do something twice, write a script for it!”. We took our manual processes and codified them. We didn't reimagine what infrastructure management could look like.
A developer shouldn't need to know anything about subnets or security groups or load balancers. They shouldn't need to learn Terraform or Kubernetes or any of it. They should write their code, and the infrastructure should appear around it, correctly configured, secure by default, and ready to scale.
That's the promise we failed to deliver.
I've been thinking about this problem for years now. After building Salt, after working at VMware and Broadcom, after seeing how enterprises struggle with this at massive scale, I've come to some conclusions.
The next generation of infrastructure automation needs to be fundamentally different. It can't just be a better version of what we have. It needs to actually deliver on the original promise: make infrastructure invisible.
Here's what that looks like in my mind:
Developers should work with their code, not with infrastructure definitions. If you're building a web application that needs a database, you shouldn't need to write Terraform modules. You should write your application code, and the infrastructure should understand what you need.
Intelligence should replace configuration. Instead of explicitly defining every resource, tools should understand common patterns and implement them securely and efficiently. They should know that a web application needs a load balancer, a database needs backups, and APIs need rate limiting.
Automation should actually reduce complexity, not shift it. This sounds obvious, but look around. Most automation tools today shift complexity from runtime to definition time. Real automation should make things simpler at every stage.
Security and compliance should be built in, not bolted on. You shouldn't need separate tools to scan your infrastructure for vulnerabilities after you've deployed it. Your infrastructure platform should refuse to deploy insecure configurations in the first place.
I still believe in the promise of automation, I know we can get there. But we need to be honest about where we went wrong.
We built tools that made us feel productive because we were writing code. We confused "infrastructure as code" with "automation." We created the illusion of control while actually increasing complexity.
The real promise of automation isn't about writing better code to manage your infrastructure. It's about not having to manage it at all.
That's what I'm working on now. That's the problem I am solving. Not another configuration management tool, not another orchestration platform, but something fundamentally different. Something that actually delivers on the promise we made 15 years ago.
Because I'm tired of watching talented engineers spend their days maintaining YAML files and debugging deployment pipelines. They should be solving interesting problems, building features that matter, pushing their companies forward.
The DevOps revolution promised to free us. Instead, it gave us more sophisticated chains.
It's time we finish what we started.
Tom Hatch is the founder of Salt and creator of the Salt Project. He's spent the last 13+ years building infrastructure automation tools and watching teams struggle with the complexity we've created. He's working on something new.
Ready to see what infrastructure automation should look like? Sign up for early access to ContextOS