# Do you need Kubernetes? What fits which team size

URL: https://brainpowergroup.eu/en/blog/do-you-need-kubernetes
Date: 2025-12-17 (updated 2026-06-30)
By: Aleksa, Brainpower Group

With one or two teams you usually do not need Kubernetes: Docker Compose or managed containers is enough. Kubernetes pays off with many services and several teams.

A product built by one or two teams usually does not need Kubernetes. Docker Compose on a few servers, or a managed container service, is enough. Kubernetes starts paying off when you run many services, several teams deploy on their own, and someone owns the cluster as a standing part of their job.

## What Kubernetes costs you

The first cost is on the invoice. AWS charges 0.10 dollars per hour for the control plane of an EKS cluster, roughly 73 dollars a month before you have a single server. Fall behind on Kubernetes versions and you land in extended support at 0.60 dollars per hour. On Azure, the AKS control plane costs nothing in the Free tier, but then without a financially backed SLA. Microsoft positions that tier for development and test clusters, so production with an SLA means at least the Standard tier.

Then there are upgrades. Kubernetes ships about three releases a year and each release gets roughly a year of patches. You will upgrade your cluster at least once a year, along with every add-on, ingress controller and Helm chart.

The biggest cost is knowledge. Networking, ingress, RBAC, secrets, autoscaling and observability all have to be set up properly, and someone on your team has to understand it, including when it breaks at three in the morning.

## How far Docker Compose gets you

Docker Compose describes your application in one YAML file, with its services, networks and volumes. Set `restart: unless-stopped` and Docker restarts a crashed container by itself. A `healthcheck` lets Docker check whether the app inside the container actually responds. Docker does not restart a container because it is unhealthy, though. You use that status in `depends_on` and in your monitoring. For a monolith or a few services with a worker, a reverse proxy and a database, that is enough.

What Compose does not handle for you is a machine that fails completely. You can cover that with a second server and a load balancer, or accept a few minutes of downtime during an outage. For many B2B products I think that is a perfectly reasonable trade-off, as long as your backups are in order.

If you want to deploy to your own servers without downtime, look at Kamal. 37signals uses it to deploy containers to bare metal and cloud VMs, with zero-downtime deploys and rolling restarts.

## Managed containers as the middle ground

Between your own server and a cluster sits the managed container service, such as Azure Container Apps, Google Cloud Run or AWS ECS on Fargate. You hand over an image and the platform runs it. On Azure Container Apps you do not manage servers or orchestration. An app scales on HTTP traffic, events or CPU and memory load. Most apps can scale to zero, except apps that scale on CPU or memory.

The trade-off is that you work within the limits of the platform and that costs grow with usage. For a team without a dedicated operations person, this is often the best place to start.

## When Kubernetes is worth it

Kubernetes is worth the effort when several of these hold:

- you have so many services that nobody remembers what runs where,
- several teams deploy independently and want one way of working,
- services need to scale independently of each other,
- the organisation already runs Kubernetes and has people for it.

That last one is a good reason on its own, because then you use what is already there. At [Ahold](/en/cases/ahold), our engineers worked inside existing teams and standards, on a stack that included Kubernetes and Kafka.

If you choose Kubernetes yourself, take a managed version such as EKS, AKS or GKE and keep it simple: one ingress, one way to deploy and as few extra operators as you can manage.

## Which setup fits which size

| Situation | What fits |
|---|---|
| One product, one team, a handful of containers | Docker Compose on one or two servers, possibly with Kamal |
| Several services, variable load, no operations person | Managed containers, such as Azure Container Apps or Cloud Run |
| Many services, several teams, a dedicated platform or ops team | Managed Kubernetes |

The choice between a monolith and separate services matters here too. A [modular monolith](/en/blog/the-modular-monolith) fits comfortably in one container and saves you many of these decisions. If you are weighing containers against functions, read [serverless or your own servers](/en/blog/serverless-or-your-own-servers).

## Keep a later move small

The same image runs in Compose, in a managed service and in Kubernetes, so you do not have to choose today for the situation three years from now. Do make sure your app behaves like a well-behaved container:

- configuration through environment variables, not baked into the image,
- no state on the local disk, everything in the database or in object storage,
- a health endpoint that really checks whether the app works,
- logs to stdout,
- a clean shutdown on SIGTERM.

Then moving to a cluster later is mostly configuration. How to keep an eye on the cost of each option is covered in [keeping cloud costs under control](/en/blog/keeping-cloud-costs-under-control).

## Sources

- [Kubernetes: release cycle](https://kubernetes.io/releases/release/)
- [Amazon EKS: pricing](https://aws.amazon.com/eks/pricing/)
- [Azure AKS: Free, Standard and Premium pricing tiers](https://learn.microsoft.com/en-us/azure/aks/free-standard-pricing-tiers)
- [Docker: Compose file reference, services](https://docs.docker.com/reference/compose-file/services/)
- [Azure Container Apps: overview](https://learn.microsoft.com/en-us/azure/container-apps/overview)
- [Kamal](https://kamal-deploy.org/)

## Frequently asked questions

**When do you need Kubernetes?**

When you run many services, several teams deploy independently and someone owns the cluster as a standing responsibility. With one product and one team, Docker Compose or a managed container service usually gets you further for less money.

**Can you use Docker Compose in production?**

Yes, for a monolith or a handful of services on one or two servers it works well. Use restart policies and health checks, and decide up front what happens when a whole server goes down.

**What does a managed Kubernetes cluster cost?**

On AWS EKS you pay 0.10 dollars per cluster per hour for the control plane, roughly 73 dollars a month, plus the servers themselves. In extended support that becomes 0.60 dollars per hour. Azure AKS has a Free tier without a management fee, but also without a financially backed SLA.

---

Source: https://brainpowergroup.eu/en/blog/do-you-need-kubernetes
Brainpower Group, contact: https://brainpowergroup.eu/en/contact, hello@brainpowergroup.eu