The current state
Kubernetes has become the default recommendation in many enterprise architecture conversations, regardless of whether it's the right tool for the problem. This is partly a function of the technology's maturity — managed Kubernetes services (EKS, AKS, GKE) have substantially reduced the operational overhead of running clusters — and partly a function of the incentive structure in technology consulting, where recommending mainstream technology is safer than recommending the simpler alternative.
The result is that organisations are running Kubernetes clusters for workloads that would run better, cheaper, and with less operational complexity on AWS ECS Fargate, Azure App Service, Google Cloud Run, or even a traditional VM. The engineers maintaining those clusters spend time managing infrastructure that doesn't give them proportionate capability in return.
Where Kubernetes genuinely adds value
Kubernetes's value proposition is specific. It provides uniform workload scheduling, service discovery, health management, and configuration management across a large number of containers that need to be deployed, scaled, and updated independently. It pays for its complexity when:
- You're running many independently deployable services. If you have 30+ microservices that deploy independently and need to be scaled independently, Kubernetes's scheduling and service mesh capabilities are genuinely useful. If you have 3–5 services, the overhead isn't justified.
- You need sophisticated deployment patterns. Kubernetes provides first-class support for canary deployments, blue-green deployments, and rolling updates with precise control over rollout speed. If your deployment requirements are complex — progressive exposure, traffic splitting, automated rollback based on metrics — Kubernetes gives you the primitives to implement them.
- You're running batch and streaming workloads alongside long-running services. Kubernetes handles heterogeneous workload types — HTTP services, batch jobs, cron jobs, stateful sets — within a single platform. This is valuable if you need to run ML training jobs and inference services alongside API services on shared infrastructure.
- You have the platform engineering capacity to operate it properly. Kubernetes requires dedicated platform engineering capability. Somebody needs to manage cluster upgrades, node configuration, networking, storage provisioning, RBAC, and the observability stack. If your infrastructure team is two people who also manage everything else, this is too much.
- You're building for multi-cloud or on-premise portability. Kubernetes provides a platform abstraction that makes it possible to run the same workloads on different cloud providers or on bare metal. If portability is a hard requirement, Kubernetes's standardisation is genuinely valuable.
When simpler alternatives are better
A mid-size e-commerce platform running 8 services on AWS is probably better served by ECS Fargate than EKS. ECS Fargate handles container scheduling, auto-scaling, and rolling deployments. It integrates natively with other AWS services. It doesn't require engineers to understand pod specs, node groups, or cluster networking. And it has a substantially lower operational overhead, which means the 2-person infrastructure team can focus on the things that actually matter to the business.
The same argument applies to workloads that are predominantly HTTP services with predictable scaling behaviour. A REST API that handles variable load is often well-served by AWS Lambda with API Gateway, or Azure Functions, if the cold-start characteristics are acceptable. The total cost of ownership — compute, engineering time, operational complexity — is frequently lower than a Kubernetes cluster running equivalently sized pods.
The pattern we see regularly is: a team adopts Kubernetes because it's the current standard, runs it successfully for a year, then realizes they're spending 20% of their platform team's time on cluster maintenance tasks that don't produce business value. The question they should have asked earlier was: what problem does Kubernetes solve for us that our alternatives don't?
The organisational maturity question
Platform adoption decisions are as much organisational as technical. Kubernetes is a substantial operational investment. Running it well requires: engineers who understand container networking, storage classes, RBAC, and the Kubernetes control plane; processes for cluster upgrade management (Kubernetes releases several times per year and clusters get expensive to maintain when they fall far behind); and observability tooling that surfaces cluster-level and application-level metrics in a unified view.
For organisations with a dedicated platform engineering function that has genuine Kubernetes expertise, this is manageable. For organisations where the "DevOps team" is one person who also handles database administration, security tooling, and incident response, it's a significant underestimate of the ongoing cost.
When we evaluate Kubernetes adoption with clients, the maturity question we ask is: do you have the staffing and expertise to run this properly for three years, including through major version upgrades? If the honest answer is no, we recommend a managed alternative that provides most of the capability with less operational overhead.
Making the decision
A practical framework for the decision:
- How many independently deployable services are you running, and how many do you expect to run in three years?
- What are your deployment requirements — simple rolling updates, or canary/progressive delivery?
- Do you have heterogeneous workload types (batch, streaming, long-running services) on shared infrastructure?
- What is your platform engineering team size and capability?
- Is multi-cloud or on-premise portability a hard requirement?
If the answers point toward: many services, complex deployment patterns, heterogeneous workloads, dedicated platform capability, and portability requirements — Kubernetes is likely the right choice. If the answers are: a handful of services, standard HTTP workloads, a small infrastructure team, and no portability requirement — a simpler managed service will serve you better.
The decision isn't permanent. We've helped clients migrate to Kubernetes when their scale and complexity grew to the point where it made sense, and we've helped others migrate away from it when they realized the operational overhead wasn't justified. The goal is to use the right tool for the current situation, with an understanding of what would trigger a change.
Related resources
Our DevOps and platform engineering service covers how we approach platform decisions in client engagements. Our retail cloud migration case study documents a decision to use ECS Fargate rather than Kubernetes for an e-commerce platform migration.