From Enterprise Bloat to OSS: A Kubernetes Cost-Cutting Story
Some of the biggest savings in tech never make it into a keynote or onto a fancy landing page. They happen deep in infrastructure setups that most teams don't think to question. It starts with a DevOps audit and ends with someone saving a boatload of cash, literally.
Here's one such story: a team saved $100,000 by doing what more teams should, which is asking, "Wait, why are we even using this?"
The setup: standard Kubernetes, standard overspend
This particular project kicked off with a pretty routine task: setting up Prometheus for Kubernetes monitoring. Straightforward enough. The infrastructure was mature, stable, and... oddly expensive.
As the team started poking around, something stood out. Sitting in the stack was an enterprise-grade API gateway with no big traffic and no fancy routing, a bloated piece of middleware that looked more like a corporate relic than a critical service.
And the company was about to renew that license for another $100K. That's one hundred thousand dollars over three years to handle traffic that could probably fit on a Raspberry Pi.
The switch: Kong OSS to the rescue
So the team did what any good infrastructure sleuth should: they swapped it out.
Kong OSS, an open-source API gateway, was dropped in its place. Besides replicating the functionality, it actually cleaned up the setup, replacing over-engineered spaghetti with clean, purposeful routing. Performance stayed the same, the footprint got smaller, and the whole thing became way more maintainable. Oh, and a $100,000 line item was gone.
That moment of clarity turned into a habit. Now, every time they're brought in to work on DevOps or monitoring, the team peeks under the hood at the rest of the stack, and it keeps happening: old tools nobody questions, leftovers from past consultants, all overbuilt, underused, and way overpriced.
Overkill by default
What's wild is how common this is. One engineer shared that their company was paying $50K a year for a tool that basically ran glorified if statements. Another said they dropped cloud costs from $100K+ to under $20K just by moving to EKS and smarter instance management.
We're talking about legacy service meshes that aren't even routing anything anymore, enterprise monitoring platforms where 80% of the stack overlaps with open-source tools already in use, and CI/CD platforms with enterprise licensing even though only two people push code through them.
One comment summed it up perfectly: "Teams inherit tech from three architects ago and never question it."
A culture issue as much as a cost issue
Sure, money is part of it. But this story is also about how inertia slowly becomes policy.
In enterprise tech, tools often outlive the reasons they were installed. That's fine until the renewal notice hits your inbox and suddenly you're staring down a six-figure mistake.
Sometimes the tool stays because someone high up signed the original contract. Sometimes it's because the cost is hidden under some vague "support" umbrella. And other times, nobody even realizes there's an alternative because "it's always been there."
This is how enterprise bloat happens, usually through inattention rather than bad intentions.
The OSS argument (with caveats)
None of this means you should rip out every paid tool and replace it with open source. Enterprise solutions exist for a reason, especially when you need SLAs, premium support, and peace of mind that someone will pick up the phone at 3 a.m. Too often, though, companies are paying for tools that don't match their actual needs.
Several engineers in the thread noted that once they moved to OSS, especially for metrics, they saved money and also got better visibility, with no more "pay-per-metric" nonsense. One company switched from a SaaS metrics platform to Prometheus + Thanos and dropped their cost-per-series by 95%. Naturally, they started tracking 50x more data.
As one user put it: "Sometimes the only reason people keep things lean is because of the price." That's a shackle more than a strategy.
What you can actually do about it
Most of these savings came from simple questions. Do we actually need this? What's it really doing for us? Can something simpler do the same job?
You don't need to be a Kubernetes ninja to ask these things. You just need to get curious, and maybe a little bit bold.
A growing number of teams are building "stack sanity checks" into every audit, regardless of whether it's in scope. The goal is right-sizing the tools to the problem, and often the hardest part is navigating the internal politics of who picked the tool in the first place.
Look for the landmines
There's a lesson here for every dev, ops engineer, and manager with even a little pull over infrastructure choices: treat your stack like a living thing that you revisit, refactor, and question.
You might find that the high-priced gateway can be replaced by something that fits in a Dockerfile, that the monitoring suite with five dashboards nobody checks can be swapped for a Grafana setup you actually control, and that the bloated VM cluster can move to containers that scale because they're simple.
You don't need to be a startup to think lean. Even big orgs can benefit from a little OSS-driven housecleaning.
Final thought: simplicity wins
Kubernetes and API gateways are just the examples here. The broader habit to break is "well, it's already there" thinking.
Under the hood of many modern systems, there's a $100K time bomb ticking away. All it takes to disarm it is someone who's willing to ask, "Hey, do we actually still need this?" Sometimes the smartest move is removing what no longer serves you instead of building something new.