Ask around and you'll struggle to find the meeting where your team chose Kubernetes. There was a proof of concept that needed orchestration, then a second service that may as well live in the same cluster, then an engineer who already knew Helm. By the time anyone asked whether you needed it, three teams were deploying to it.
That isn't a failure of governance. It's how most infrastructure decisions actually get made, one reasonable step at a time. But it means the question never got asked, and the answer changes what you spend and who you can hire. We've written about how most of your token bill is avoidable, and this is the same shape of problem sitting one layer down.
Complexity arrives, it doesn't get chosen
Every piece of your stack has a story like this. Someone needed a queue, so Kafka appeared. A service needed caching, so Redis did. None of those were wrong on the day, they were the fastest way to unblock the person who was blocked.
Kubernetes differs only in scale. It doesn't sit beside your application, it becomes the ground your application stands on, and everything after it assumes it's there. Cluster upgrades, networking, RBAC, node pools: that's a job now, and usually somebody's whole job.
Some teams genuinely chose it. They run dozens of services, several teams deploy independently, and they needed networking and scheduling that nothing simpler offered. For them the operational cost buys something real.
Most teams inherited it. One containerized service turned into a cluster, and now four people maintain orchestration built for a company ten times their size. The cost isn't the compute, it's the attention.
So how do you tell which one you are? Not by counting services. By asking what breaks when the person who set it up goes on vacation.
Start with what you actually use. If your workloads are stateless containers responding to requests or events, a managed runtime removes an entire layer of operations for nothing, and on Google Cloud that means Cloud Run rather than a cluster. If you're using three Kubernetes features and paying for all of them, that's a signal. If cluster upgrades are a project rather than a Tuesday, that's a louder one. And if the honest answer to who owns the platform is a name rather than a team, you've found the real risk, because that person is one resignation away from being a single point of failure. None of this means tearing anything out. It means knowing what you're paying for.
The reverse case is just as real. Teams outgrow managed runtimes, hit the ceiling on what they can configure, and move to Kubernetes deliberately with the platform engineering to support it. That's the same decision made in the right direction.
You pay for the whole platform, not the parts you use
Infrastructure deserves the same scrutiny as your build decisions
At eComia we do the cloud engineering work that usually starts with exactly this audit, and we'll say so when the answer is to keep what you have. If you want that conversation with people who run these platforms daily, our GCP team is where to start.
You don't need to justify your stack to anyone. You do need to know which parts you'd choose again.
Run that check once a year and the inherited things either earn their place or quietly leave. Skip it, and you'll keep paying for decisions nobody remembers making.