Do You Need Kubernetes? Probably Not Yet

What Kubernetes is for

Kubernetes runs containers across a group of machines. It decides where each one runs, restarts the ones that fail, scales them up and down, and routes traffic between them.

It was designed for organisations running many services, owned by many teams, on a lot of hardware. For that problem it is excellent.

Most products are not that problem.

What it costs you

The software is free. Running it is not.

• Someone has to understand it. Networking, storage, permissions, upgrades — each is a subject of its own. When something breaks at night, that person is on call.
• It adds moving parts. A cluster brings an ingress controller, certificate management, a secrets solution, monitoring and its own deployment tooling.
• It needs regular upgrades, and they do not always go smoothly.
• It costs money while idle. A cluster has a baseline cost before it serves a single request.

A small team can easily spend more time looking after the platform than building the product that runs on it.

What to use instead

In rough order of simplicity:

A managed platform. Services such as Vercel, Render or Fly.io take a repository or a container and run it. Scaling, certificates and deploys are handled for you. For a web application and an API this is often all you need.

A managed container service. AWS ECS with Fargate, Google Cloud Run or Azure Container Apps run your containers without you managing the machines underneath. You get autoscaling and rolling deploys with far less to learn.

A managed database. Whatever runs your code, do not run your own database unless you must. Backups, failover and upgrades are exactly what you want someone else to be responsible for.

These options carry a product further than people expect.

Signs you might actually need it

• You run many services that scale independently and are deployed by different teams
• You need to run the same platform across more than one cloud, or on your own hardware
• Your workloads are unusual — heavy batch jobs, GPUs, strict placement rules
• You already have people whose job is the platform

If none of those describes you today, you do not need Kubernetes today.

How to stay ready without adopting it

Moving later is straightforward if you build with a few habits now:

• Package the application as a container. The same image runs on a managed platform now and on Kubernetes later.
• Keep the application stateless. Sessions, files and jobs belong in a database, object storage and a queue — not on the server's disk.
• Put configuration in environment variables, not in the image.
• Define infrastructure as code, so an environment can be recreated rather than remembered.
• Automate deploys. A working CI/CD pipeline matters far more than what it deploys to.

Do those and the question "should we move to Kubernetes?" becomes a routine migration when the time comes, rather than a rewrite.

The rule of thumb

Choose the simplest platform that meets your reliability needs, and move when a real limit forces you to — not in anticipation of scale that may never arrive. That is the advice we give on every cloud and DevOps engagement, including the ones where the right answer does turn out to be Kubernetes.