Here’s something most people don’t realize: complexity isn’t a bug. It’s the business model.
I watched this play out at IBM, VMware, and Broadcom. A customer says, “We need to manage our infrastructure.” You sell them one product. Months later, you return: “You’ll also need orchestration, monitoring, security, and automation to tie it together.”
Each product requires specialists, training, and its own license. Each integrates just poorly enough with the others that you need professional services to make it all work.
I’ve seen the spreadsheets tracking customer “wallet share,” and the roadmaps that deliberately spread features across multiple tools. I’ve watched executives celebrate when a customer bought their fifth or sixth product.
That’s the dirty secret of enterprise software: vendors make more money when infrastructure is complicated. Every new tool means another license, another support contract, another renewal. The more complex your stack, the more locked-in you become — and the harder it is to leave.
I’ve even heard CEOs talk explicitly about “rental revenue streams.” Your infrastructure becomes rent paid to vendors who profit from your pain.
Between IBM and SaltStack, I worked at Domo on backend infrastructure for a consumer-facing product. It taught me something the enterprise world forgot: great products make complex things simple, not simple things complex.
At Domo, thousands of users relied on data systems they never had to think about. Integration, scaling, and security just worked. We built big data infrastructure that stayed invisible.
When I returned to the enterprise world at VMware, the contrast was painful. We were building tools that made smart people feel stupid — products that required week-long training courses and armies of consultants. We told ourselves we were creating “enterprise-grade” solutions. Really, we were building job security for the ecosystem that supported them.
From the inside, here’s what an enterprise infrastructure sale looks like.
The slide deck shows magic: click a button and infrastructure appears; drag and drop your app; it scales, self-heals, and stays secure by default.
Then you buy it — and realize you need to:
Six months later, you have automation — sort of. It works as long as no one touches the configuration files. You’ve reduced manual work but created a new full-time job maintaining the automation itself.
And vendors know this. They know the gap between demo and reality. That’s why they invest so heavily in “customer success” — not to make you successful, but to keep you paying until you’re too entrenched to leave.
After years talking to infrastructure teams at IBM, VMware, SaltStack, Broadcom, and now ContextOS, I hear the same thing:
“Just make it work. I don’t want to worry about it.”
Teams don’t want more tools, dashboards, or knobs to turn. They want to deploy applications that run securely and scale automatically — without becoming experts in networking, load balancing, or certificate management.
They want infrastructure that understands what their applications need, provisions it correctly, and includes security by default. They want costs that scale with usage, not with complexity.
In other words, they want what vendors have promised for decades — but never actually delivered.
If we were designing infrastructure the way it should work, it would follow a few simple principles:
If this is what customers want, why hasn’t anyone built it?
Two reasons.
First, vendors have no incentive to simplify. Complexity is their moat. It drives switching costs, premium pricing, and consulting revenue. AWS won’t build something that makes you use fewer AWS services. VMware won’t ship a product that cuts your license bill. They’ll talk about simplification, but they’ll never eliminate the sprawl that fuels their profits.
Second, true automation is hard. It requires deep infrastructure, security, and compliance expertise — the kind Tom and the whole ContextOS team developed over decades in the industry. Most startups don’t have that experience or the patience to tackle such a complex problem.
But today, the technology finally exists — and our team has learned enough from decades of automation to build systems that truly manage themselves.
That’s what we’re doing with ContextOS — a platform that finally delivers on the promises enterprise vendors made but never kept.
Our principle is simple: developers should never have to worry about infrastructure.
You write your code. You push to GitHub or GitLab. ContextOS analyzes your app, understands what it needs, and deploys everything — databases, networking, scaling, and security — automatically and correctly.
No Terraform. No Kubernetes manifests. No Helm charts. No configuration-as-code. Just your application.
We’re not adding another tool to your stack. We’re replacing the stack entirely with something that actually works.
Because here’s the truth: vendors won’t fix this. They profit too much from the complexity. Real change has to come from people willing to build something different — even if it means disrupting the market they came from.
I spent years building and selling infrastructure tools that created more problems than they solved. We won’t do that at ContextOS.
Enterprise teams deserve better than products that require armies of specialists and consultants. They deserve infrastructure that works the way we envisioned it fifteen years ago — simple, secure, and scalable by default.
Tom talked about finishing what the DevOps revolution started. He’s right. But this isn’t just about better technology — it’s about better incentives: optimizing for simplicity over feature count, and aligning vendor success with customer success.
Big vendors can’t make that shift. Their business models depend on complexity. But we can — and we are.
If you’re tired of maintaining infrastructure automation, if you want to focus on your product instead of your platform, if you believe infrastructure should just work — join our beta.
Let’s build infrastructure the way it should have been built from the beginning.