Do You Need Kubernetes? An Honest Decision Framework for Growing Teams

Do you need Kubernetes? If you are asking, the answer is more often “not yet” than the internet suggests.

We are a Kubernetes shop. We run production clusters for clients, we do migrations, and a meaningful share of our revenue depends on people deciding they want Kubernetes.

So take this in the spirit it’s intended: most teams that ask us for Kubernetes do not need it yet.

That is not a fashionable position for an infrastructure consultancy. It is, however, the honest one, and it’s cheaper for you to hear it now than eighteen months into an unhappy migration. What follows is the framework we actually use when a client asks whether they should move.

What people think they are buying

When teams ask for Kubernetes, they are usually asking for a list of things. Rolling deploys with zero downtime. Automatic restart of crashed containers. Horizontal autoscaling. Service discovery. Health checks. Secrets management. Config separated from code.

Every item on that list is available from ECS Fargate, Google Cloud Run, Azure Container Apps, and several smaller platforms, without a control plane to operate. If that list is your motivation, you have not made an argument for Kubernetes. You have made an argument for containers, which you should absolutely adopt, and which is a much smaller decision.

The question worth asking is narrower: what does Kubernetes do that the managed alternatives do not?

What Kubernetes genuinely gives you

Four things, in our experience, are hard to replicate elsewhere.

Bin-packing density. Kubernetes schedules many containers onto shared nodes according to declared resource requests. If you run thirty services with wildly different resource profiles, the scheduler will pack them far more efficiently than one-task-per-Fargate-instance. With Karpenter provisioning right-sized nodes on demand, the density gain is real and it compounds. Below roughly ten services, there isn’t enough variety for the scheduler to be clever with.

Fine-grained scheduling control. Affinity and anti-affinity rules, topology spread constraints, taints and tolerations, priority classes, pod disruption budgets. If you need to guarantee that your three replicas land in three different availability zones, or that batch workloads get evicted before customer-facing ones, Kubernetes gives you the vocabulary. Most platforms give you “run N copies.”

The operator ecosystem. Databases, message queues, certificate management, secret rotation, service meshes. If your architecture depends on running stateful infrastructure yourself rather than consuming managed services, operators are a genuine advantage.

Portability, conditionally. Kubernetes manifests move between clouds more easily than ECS task definitions. This matters if you have an actual multi-cloud requirement, a regulatory constraint, or customers who insist on self-hosted deployment. It does not matter if “we might switch clouds someday” is hypothetical, and it usually is. Your managed database, your object storage, and your IAM model are all going to be the hard part of any cloud migration, not your container orchestrator.

If none of those four describe your situation, the case for Kubernetes is weaker than it looks.

What it actually costs

The EKS control plane runs about $0.10 per hour, roughly $73 a month per cluster. If you have production, staging, and development clusters, call it $220 a month. GKE and AKS have comparable or slightly friendlier pricing. That number is not the cost.

The cost is engineering time, and it recurs.

Version upgrades. Kubernetes ships a minor release roughly every four months. AWS supports each EKS version for around fourteen months before extended-support charges begin. That means an upgrade cycle two to three times a year, every year, forever, and each one touches the control plane, the node groups, and your add-ons — CNI, CoreDNS, kube-proxy, ingress controller, cert-manager, metrics-server. Deprecated APIs break manifests. This is not hard work, but it is real work that never stops.

The failure modes are unfamiliar. VPC IP exhaustion because the AWS CNI allocates an IP per pod and your subnets were sized for instances. Pods stuck in Pending because of a resource request nobody tuned. DNS resolution failures under load from CoreDNS being under-replicated. Ingress controller misconfiguration that only shows up under a specific traffic pattern. None of these are exotic. All of them require someone who has seen them before, at 2am.

Someone has to own it. This is the decisive cost. Kubernetes is not a thing you set up; it is a thing you operate. If you cannot name the person who owns cluster health, upgrades, and the on-call rotation for it, you are not ready — you are about to distribute that responsibility across everyone, which means nobody.

For a five-engineer team, that ownership can easily consume 15–20% of one person’s time. Price that honestly against whatever you expect to save.

The framework: do you need Kubernetes yet?

Score each of these. Be strict with yourself.

Strong signals you’re ready (2 points each):

• More than fifteen or twenty distinct deployable services
• Multiple teams deploying independently, needing isolation from each other
• Heterogeneous, bursty workloads where bin-packing meaningfully improves utilisation
• A named platform engineer, or someone whose job explicitly includes infrastructure
• Existing Kubernetes operating experience on the team, not just certification
• A genuine portability or self-hosted-delivery requirement from customers
• Running stateful infrastructure yourself where operators do real work

Moderate signals (1 point each):

• Ten to fifteen services with growth clearly continuing
• Batch and stream workloads alongside request-serving ones
• Need for sophisticated deployment strategies — canary, traffic splitting, progressive rollout
• Compliance requirements around workload isolation and network policy

Counter-signals (subtract 2 each):

• Fewer than eight services
• One team, one deploy cadence
• Steady, predictable traffic
• No one who can name the last CVE they patched
• The primary motivation is that a competitor or a conference talk uses it
• You are currently on-fire with reliability problems

Roughly how to read it. Six or more, Kubernetes will probably earn its complexity. Three to five, it’s genuinely arguable and depends on your trajectory over the next year. Below three, you will spend more on operating it than you recover, and the honest recommendation is to wait.

What to do instead, if the answer is “not yet”

ECS on Fargate. The pragmatic AWS default. Task definitions, service autoscaling, ALB integration, rolling deploys, secrets from Parameter Store or Secrets Manager. No control plane, no node patching, no version treadmill. Per-vCPU pricing is higher than raw EC2, which is exactly the trade you’re making: you pay a premium to not employ someone to manage nodes. For most teams under ten services that is a good trade.

Cloud Run. If you’re on GCP, this is excellent. Scale to zero, request-based billing, deploy from a container image with almost no configuration. The constraints are real (request timeouts, limited background processing) but for HTTP services it’s hard to beat.

Plain autoscaling groups behind a load balancer. Unfashionable and still correct for a surprising number of workloads. If you have three services with steady traffic, an ASG with a rolling update policy and a health check does what you need.

Nomad. Worth knowing about if you want orchestration without the Kubernetes surface area, though the smaller ecosystem is a genuine cost.

The “we’ll need it eventually” argument

The most common objection is that adopting later means a painful migration, so you may as well start now.

This is mostly wrong, and it’s worth understanding why. If you containerise your applications and keep your configuration in environment variables rather than baked into the platform — the Twelve-Factor discipline, essentially — then the move from ECS to Kubernetes is a rewrite of your deployment manifests, not your applications. That is a matter of weeks, not quarters, and by the time you do it you’ll have real production data about what your workloads actually need, which makes the resulting cluster design substantially better than one you’d have guessed at eighteen months earlier.

What does create a painful migration is coupling your application code to platform-specific behaviour: writing to local disk and expecting persistence, relying on instance metadata, hardcoding service endpoints. Avoid those, and your optionality is preserved cheaply.

Adopt containers early. Adopt orchestration when the service count justifies it.

When we say yes

To be clear about the other side: we migrate teams to Kubernetes regularly, and when the signals are there, it delivers. One ecommerce client came to us with four-hour deployments, no rollback path, and infrastructure spend growing faster than traffic. Kubernetes with GitOps took deployments to eight minutes, eliminated production incidents during rollout, and cut infrastructure costs 40% through better packing and autoscaling — the case study is here.

That worked because they had the service count, the traffic variability, and the team to justify it. The same migration for a four-service startup would have been an expensive way to make deployments more complicated.

The actual question to ask

Not “should we use Kubernetes,” but: what is the simplest platform that meets our reliability, scale, and delivery requirements for the next eighteen months?

Sometimes the honest answer is Kubernetes. Often it’s ECS with a decent CI/CD pipeline and someone paying attention to cloud costs. The difference between those two answers is worth several hundred thousand rupees a year and a meaningful amount of your team’s attention.

If you want a second opinion on which side of that line you’re on, tell us what you’re running. We’ll give you a straight answer, including when the answer is that you don’t need us yet. That framing is the substance of most of our cloud and DevOps work and our platform engineering engagements.