For the second time this month, I’ve had an all too familiar conversation, with yet another company that refuses to give Kubernetes a second look. Their first attempt failed badly, cost them a lot in downtime and lost productivity, and as a result Kubernetes was deemed “the wrong technology” and shelved. The problem with that conclusion is that it is simply not true. Kubernetes is a technology that works perfectly well when it is designed and deployed correctly, and hundreds of thousands of organizations have proven exactly that. If a technology works reliably at that kind of scale, and it did not work for you, the honest starting point is that the problem was a you problem, not a tech problem.
What actually happens in almost every one of these “Kubernetes failed us” stories is not a failure of the technology; it is a failure of scope, or a failure of design, or (often) both. The design failure looks like this: engineers, likely very new to Kubernetes, made ill-informed decisions early on (wrong network stack, wrong storage class for the workloads, incorrectly sized CIDR subnets, undersized nodes, no DR strategy, and no upgrade testing) and before you know it, failures hit. Of course, the failures are because of Kubernetes, right? Wrong. Kubernetes didn’t fail, the design of the platform failed.
More commonly, “adopting Kubernetes” quietly morphs into a full CNCF-inspired transformation program on day one; GitOps goes in immediately, a service mesh gets layered in because someone at KubeCon said you must have mTLS, a full observability pipeline replaces the perfectly adequate monitoring already in place, policy engines get bolted on because they might be needed later, and a developer portal gets scoped because self-service was the goal. Then secrets management, cost management, image scanning, and admission control all arrive together, and all of this classified as “deploying Kubernetes”. This is a complicated stack by any means, and a stack that only a large and mature platform engineering team can support, you know, like the ones that run Kubernetes at a scale where 10,000 PODs is considered small. Projects that bundle in too much change up front fail all the time, regardless of whatever technology sits underneath them. This isn’t the first time around this cycle too… it happened in the early days of Virtualization, and it quickly course corrected. That course correction is starting to happen with Kubernetes now too.
When a project like that falls over, someone has to carry the failure, and in most organizations blaming a specific team’s decisions is politically much harder than blaming “the technology”. So the technology takes the fall, the retrospective gets written up as “Kubernetes is not suitable for our environment”, and the finding becomes organizational canon; two years later, no one can remember exactly what happened, but everyone knows “we tried Kubernetes and it did not work for us”. The company holds itself back from every workload Kubernetes is actually well-suited to, and pays for it in a slower application delivery cycle, worse resource utilization, and a widening capability gap against competitors who ran the same technology but scoped the project sensibly.
If you are in a company that shelved Kubernetes for these reasons, or you are the engineer or leader who lived through the failure, three questions come to mind…
Was the original project actually about running your apps on Kubernetes, or did it morph into a program to adopt half the CNCF landscape at the same time?
Did you deploy Kubernetes as a small, focused first workload, learn it, and then you added complexity as your skills improved, or did you commit to a full-stack “day one” that had you struggling to learn a dozen tools simultaneously?
Are you still avoiding the technology today because it genuinely failed, or because reopening the conversation would mean reopening the question of who owned the original scope decision?
If the honest answer to any of those is uncomfortable, that is the signal that a second look at Kubernetes is warranted (not necessarily a second attempt, but at least a second look, with clearer eyes and a much smaller scope).
None of this is written to make anyone feel bad about a project that did not land the way they hoped. Kubernetes projects fail for the same reason most transformation projects fail; the scope was too wide, the timeline was too optimistic, the tooling was too new, and the team was learning half a dozen things at once. That is a hard thing to admit at the time, and it is a much harder thing to reopen later, especially when the organizational memory has hardened around “the technology did not work”. But holding onto that story costs the company the entire category of workloads Kubernetes actually runs well. It costs years of delivery velocity that could have been captured, and eventually it costs competitive position, because the peer down the road who scoped their project sensibly is now shipping features that cannot be matched.
Neil
If your first Kubernetes attempt failed, and you want to look at it again without repeating the scope trap, this is exactly what my team at Portainer built the product to do. Run Kubernetes as an integrated platform, without the CNCF sprawl, with the day-one complexity kept small enough that the project actually succeeds first and grows into the rest later, only when it needs to. No obligation, all it takes is a call, and we are happy to walk through what a sensibly-scoped first deployment actually looks like.