Do You Even Need Kubernetes for Reliable Service Delivery?
Kubernetes has become the default backbone of cloud native architecture. But does it actually help you ship services more reliably, or is it just more moving parts?
Despite Betteridge’s law of headlines, the answer is yes, for the vast majority of companies. Kubernetes has proven essential for reliable service delivery in today’s cloud native world. But not because it magically sprinkles reliability over your stack. Rather, it gives you what you need to build reliability like an engineer, not a magician. Kubernetes is a means, never the end. But let me explain before you skeet this out of context…
Kubernetes Is Not the End, but a Means
Like any technology, Kubernetes is just a building block supporting your goals. Treat it that way. If you adopt it simply because nobody gets fired for choosing Kubernetes, you’re setting yourself up for pain. Kubernetes is powerful and unforgiving — there’s no shortage of real‑world lessons and failure stories from teams led by hype and not purpose.
Instead of chasing hype, start with the essentials. Cut to the core by asking a deceptively simple question: “Who cares?”
Who cares about the benefits —reliability, consistency and automation — that Kubernetes gives you? Teams running services on your platform expect those properties to hold under load and during change. Who cares about that? Your organization, offering those services to users. Users, who have their own goals. Those goals aren’t yours to reach, but you can make the path smooth and successful. When users succeed, they’re delighted — and that’s our end.
Why Delighted Users Matter to Engineers
Keeping that mindset, you might ask: “Why should I, as an engineer, care about delighted users?” You might wonder why you should care at all. Sure, you could go eat pretzels and scroll silly websites. But engineers don’t stop there. We look deeper — because by profession, you are a systematic thinker. You solve human needs with science and engineering.
So instead of just answering the initial question (“Do we even need Kubernetes for reliable service delivery?”), we approached it like engineers. We used a structured method called causal analytics — asking “Who cares?” — until the real goal emerges: Does Kubernetes deliver the level of service reliability that we need to delight our users?
All that remains is to break it down in your specific context: Who are your users? What is a delightful experience for them? What expectations for reliability do they have?
I am certain that after answering those questions, 95% of you will conclude that your needs for reliability are not exceptional, and that Kubernetes is the right choice to achieve those goals. This should not be surprising, because as with most requirements, there’s a bell curve; most teams need a reasonable amount of reliability, some need a little and a few need the extreme.
The teams needing extreme reliability are building systems where lives are literally at stake, if they fail — aviation, medicine and similar fields.
For the teams that need less than average reliability, here’s a story: Years ago, I asked the ops team of a world-class soccer club how much reliability mattered for their online store. Their answer surprised me — “Our users are fans! If they can’t get a jersey now, they’ll wait. Reliability isn’t our differentiator — we focus on a unique fan experience.“
Indeed, fans happily wait. Half the fun is in the waiting, which deepens their sense of belonging.
What I learned from that is simple — it’s perfectly fine to be average in most areas, as long as you know where not to compromise.
You’re an Engineer – Behave Like One!
As you might have guessed, the point of this text is not to settle the question of whether you need Kubernetes for reliable service delivery. It is to remind you that you should not only like building and tinkering like an engineer but also enjoy thinking and making decisions like one. It’s your job to know when it is perfectly fine to deliberately pick the boring, established standard and when you need to go against the grain.
When you make decisions that way, you gain clarity and calmness. You will read yet another blog post from teams ditching Kubernetes and understand that they might be one of the outliers that need something different. But because you made the choice to adopt it with your context in mind, you won’t regret it.
Even if you reach the point where you need to revisit your decision, as new information and context emerge, you’ll approach the problem with the right questions: Given our current context, is moving away from Kubernetes the right thing to do? Or is it preferable to continue using it, even if your enthusiasm has waned?
Finally, it’s not just about Kubernetes. Every technology you add is a means, not the end and should be evaluated in your context. This mindset is especially useful for approaching hype cycles. Right now, everyone is trying to solve every problem with LLMs. Next year it will be something else. The cycle never stops.
But as an engineer, your job isn’t to chase the latest shiny thing. It’s to understand your context, weigh the trade-offs and decide deliberately. Sometimes that means adopting the new; sometimes it means sticking with the boring. The strength lies in knowing the difference.
