Do You Really Need Kubernetes? A Practical Assessment

This article is based on a discussion originally published on ITWorld.com, examining whether Kubernetes adoption is genuinely warranted or primarily driven by industry fashion.

The Kubernetes Question Everyone Is Afraid to Ask

Kubernetes has become the default answer to almost every container orchestration question. But is it the right answer for your organisation? As developer and commentator Paul Johnston asked publicly, “Why Kubernetes?” — and the volume and passion of the responses revealed that this is a question many practitioners are quietly asking themselves.

Before committing to the operational overhead of running Kubernetes, it is worth examining the most common justifications critically. The two most cited reasons are avoiding cloud vendor lock-in and following industry best practice. Neither holds up to scrutiny as cleanly as the sales pitch suggests.

The Lock-In Myth

Cloud portability is probably the single most frequently cited reason for adopting Kubernetes. The argument goes: if your workloads run on Kubernetes, you can move them between AWS, GCP, Azure, or on-premises without significant rework. In theory, this is sound. In practice, it is complicated.

• Managed services create their own lock-in. Most production workloads depend on managed databases, message queues, identity providers, and monitoring stacks — all of which are cloud-specific. Kubernetes does not abstract those dependencies away.
• “Portable” clusters are not free. As Neal Gompa notes, bare Kubernetes does not give you cloud portability out of the box. You need additional tooling, disciplined API usage, and often significant architectural compromises to achieve meaningful portability.
• Teams rarely actually move. Johnston observed that the same engineers who cited multi-cloud portability as their primary motivation also admitted they had no concrete plans to switch providers. The exit strategy remains theoretical.

Analyst Lawrence Hecht makes a fair counter-point: “Fear of lock-in is rational. It is rational to want to have an exit strategy even if you don’t plan to use it.” That is a reasonable position. But an exit strategy does not have to mean Kubernetes. Well-containerised applications running on plain Docker, or even well-structured monoliths on virtual machines, can offer meaningful portability without the operational overhead Kubernetes introduces.

“An attempt to evade lock-in should not automatically mean Kubernetes. We had a decent amount of portability with monoliths sitting on virtual servers. I’d argue we have less portability with Kubernetes now.”

— Paul Johnston

The Complexity Cost

Kubernetes is a sophisticated distributed systems platform. It solves genuinely hard problems around scheduling, self-healing, scaling, and service discovery. But it introduces a substantial operational burden in return:

• Cluster provisioning and lifecycle management
• Networking (CNI plugins, ingress controllers, service meshes)
• Storage provisioning and persistent volume management
• RBAC, secrets management, and security policy
• Observability: metrics, logging, and tracing pipelines
• Upgrade paths across control plane and node pools

For teams without dedicated platform engineering expertise, this overhead can consume more capacity than it saves. As James Thomason argues, Kubernetes may be overkill for the vast majority of production workloads. Developers who see it as a way to “run like Google” may be adopting the complexity without the scale that justifies it.

Johnston notes that many CTOs adopt Kubernetes because they feel they have to — either inheriting it from a previous team or viewing it as the next big industry standard — and then regret it. The regret tends to arrive when the complexity of operating Kubernetes outweighs the problems it was supposed to solve.

When Kubernetes Does Make Sense

None of this means Kubernetes is without merit. There are clear scenarios where it is the right choice:

• Large microservices architectures. When you are running dozens or hundreds of independently deployable services, the scheduling, service discovery, and health management capabilities of Kubernetes provide real value.
• Teams with platform engineering investment. Organisations that can staff and maintain a platform team get a consistent, programmable infrastructure layer that scales well.
• Infrastructure abstraction across environments. As Joseph Mente argues, Kubernetes provides a useful layer of abstraction that helps when moving between services or environments, even if it does not fully eliminate lock-in.
• Transferable developer skills. As Don Syme points out, engineers who learn Kubernetes build skills that are broadly valued across employers and industries, regardless of which cloud those employers use.

The Future: Kubernetes as Infrastructure, Not Application Concern

There is a compelling argument, made by James Urquhart among others, that the current phase of Kubernetes ubiquity is transitional. Kubernetes will likely “win” the container orchestration space — but not by requiring every developer to understand its internals. Instead, it will disappear into the abstractions above it.

This is already happening. Managed Kubernetes services (EKS, GKE, AKS) hide much of the control plane complexity. Serverless platforms like Google Cloud Run and AWS App Runner run containers on Kubernetes infrastructure without exposing Kubernetes APIs to developers. Platforms like Heroku-style PaaS tools and internal developer platforms built on top of Kubernetes abstract it further still.

The practical implication: the question is shifting from “should we use Kubernetes?” to “at which layer should our teams interact with it?” For many organisations, the right answer is that application developers should not interact with it directly at all.

A Decision Framework: Do You Actually Need Kubernetes?

Before committing, ask your team these questions honestly:

1. What specific problem are you solving? If the answer is “portability” or “it’s the industry standard”, dig deeper. Those are not engineering requirements.
2. Do you have the operational capacity? Running Kubernetes well requires sustained investment. Do you have — or can you hire — people with the skills to do it?
3. Would a managed platform solve it? For many teams, a managed container service, a PaaS, or even well-structured Docker Compose deployments on VMs will cover 90% of needs at a fraction of the complexity.
4. What does your scale actually look like? Kubernetes is designed for scale. If you have five services and one team, the overhead-to-benefit ratio is probably not in your favour.
5. Is the portability benefit real? Map out your actual external dependencies. If you are using five managed cloud services, Kubernetes on the compute layer will not make you portable.

Conclusion

Kubernetes is a powerful platform that solves real problems at scale. It is also frequently adopted for the wrong reasons — fashion, fear, or inherited decisions — and imposes real complexity costs that teams underestimate. Cloud portability, the most common justification, is real but limited: Kubernetes alone does not free you from vendor lock-in when your application depends on cloud-specific managed services.

The honest answer to “Do you need Kubernetes?” is: it depends on your scale, your team’s capacity, and whether you have a concrete engineering problem that Kubernetes solves better than simpler alternatives. If you cannot answer those questions clearly, that is a signal to slow down before you board the bandwagon.