Kubernetes is undoubtedly one of the most influential technologies of the last decade in software infrastructure. It is also one of the most over-specified in the SME market. There are 15-person companies paying for a managed Kubernetes cluster when Docker Compose on a single server would have given them exactly the same result at 10% of the cost and complexity.
This article does not aim to convince you to use Kubernetes or to avoid it. It aims to give you the criteria to make that decision with real information, not industry trends.
What Kubernetes actually does
Kubernetes (K8s) is a container orchestrator: its job is to automatically manage where and how your applications run across a set of servers (the cluster). When a container fails, K8s restarts it. When you need more capacity, it scales automatically. When you deploy a new version, it does so with zero downtime.
In one sentence: Kubernetes solves the problem of managing many containers on many servers reliably and automatically.
The key question before reading further: do you actually have many containers on many servers? If the answer is no, you probably don't need Kubernetes yet.
The real cost of Kubernetes that nobody mentions
Kubernetes solves real problems, but it introduces a significant layer of operational complexity with a cost that must be honestly assessed:
Learning curve
Kubernetes has its own mental model: pods, deployments, services, ingress controllers, namespaces, ConfigMaps, Secrets, PersistentVolumes… Someone on the team needs to understand all of that to maintain the cluster. This is not knowledge you acquire in a weekend.
Operational overhead
A Kubernetes cluster needs maintenance: version upgrades, certificate management, monitoring of cluster components themselves (not just applications), persistent storage management, network policies. If nobody on your team has experience, that maintenance becomes accumulated technical debt until something fails.
Minimum economic cost
A minimally viable production Kubernetes cluster (with high availability) requires at least three nodes. On major cloud providers, that means a base cost of between €150 and €400/month before storage, network traffic or additional managed services. A single server with Docker can cost €20-40/month.
When Kubernetes does make sense for an SME
K8s is probably worth it if...
- You have more than 10 different microservices or applications to manage
- You need to auto-scale for unpredictable traffic spikes
- You deploy multiple times a day and downtime is unacceptable
- At least one person on the team has real K8s experience
- Your application is already fully containerised
- You need reproducible environments (production, staging, dev) with identical configuration
K8s is probably overkill if...
- You have between 1 and 5 applications or services
- Your traffic is predictable and stable
- You deploy once a week or less
- Nobody on the team knows K8s in depth
- Your infrastructure budget is tight
- You're evaluating K8s because "it's what everyone uses"
Real alternatives: what to use instead
The good news is that between "one server with everything done manually" and Kubernetes there is a spectrum of options that cover most SME needs.
The most underused tool in the container ecosystem. A docker-compose.yml file defines all your services, networks and volumes. One command brings the entire stack up, another takes it down. Perfect for most SME applications: a backend, a database, a proxy, a message queue. No nodes, no controllers, no cluster certificates. Maintenance is minimal and any developer can understand it in an hour.
A platform that runs Docker containers close to users (edge computing) without you managing any servers. Deploy with fly deploy, auto-scales, and has a presence in over 30 regions. The pricing model is per resource consumed, making it economical for variable loads. For a web application with moderate international traffic, it can be cheaper and simpler than any self-managed alternative.
A Heroku alternative with better performance and more competitive pricing. Deploys automatically from Git, manages SSL certificates, databases, workers and cron jobs from a single interface. If your priority is keeping the team focused on the product rather than infrastructure, Render eliminates virtually all the operational burden.
A lightweight Kubernetes distribution designed for resource-constrained environments: Raspberry Pi, small servers, IoT environments. Maintains full compatibility with the Kubernetes API but with a much smaller footprint. If you want to get familiar with K8s without the cost of a full cloud cluster, K3s on a €4 VPS is the usual starting point.
If after evaluating everything you conclude that Kubernetes is what you need, always use your cloud provider's managed version (EKS on AWS, GKE on Google Cloud, AKS on Azure). The control plane (master nodes) is managed by the provider; you only manage your workloads. The extra cost versus self-managed is quickly amortised in saved administration time.
A decision tree for your specific situation
Do I need Kubernetes?
Do you have more than 10 independent services to deploy and scale?
Docker Compose or a PaaS (Fly.io, Render) covers your needs with much less operational cost.
Keep evaluating. The number of services is a necessary but not sufficient condition.
Does anyone on the team have real K8s experience (not just courses)?
Don't adopt K8s until you have that. The learning curve in production is expensive and risky.
The human factor is covered. Evaluate whether the use case justifies the additional complexity.
Do you need auto-scaling or zero-downtime deployments several times a day?
A managed PaaS or Docker Swarm solves this with much less complexity.
Kubernetes starts to justify itself. Use a managed cluster (EKS/GKE/AKS), never self-managed if you can avoid it.
The most costly mistake: adopting K8s too early
In the tech world there is a tendency to adopt the most sophisticated available technology as a signal of technical maturity. Kubernetes has suffered especially from this effect. The practical result in many SMEs is a K8s cluster running three applications, maintained by someone who learned K8s on YouTube and who spends more time debugging cluster network issues than building product.
The right technology is not the most advanced one — it's the most appropriate for the problem you have now, with the team you have now and the budget you have now. Docker Compose is not a "beginner solution": it is a professional solution for a well-defined set of problems. Many companies with tens of millions in revenue use it in production because it solves exactly what they need.
Practical rule: start with the simplest solution that solves your current problem. Migrate to something more complex only when you have a concrete problem that the simple solution cannot solve — not before.
When it does make sense to make the leap
There are clear signals that the time has come to seriously evaluate Kubernetes:
- Your Docker Compose deployments cause downtime that is beginning to affect the business
- You manage more than 15-20 containers and coordinating them manually is becoming a problem
- You need perfectly isolated and reproducible staging and production environments with complex configurations
- You have traffic spikes that require scaling within minutes and fixed over-provisioning costs more
- Your team has grown and multiple developers deploy in parallel, creating conflicts
If you recognise two or more of these situations simultaneously, and you have the technical profile to manage it, Kubernetes starts to have a clear economic justification.
At EstructuraBit we assess the infrastructure of each company and recommend the solution best suited to their current scale and management capacity, without over-selling unnecessary complexity. If you're not sure whether your current infrastructure is right for the next growth step, let's talk.
Back to blog