Eventually, the moment arrives when the recommendation lands on the desk - often courtesy of an external consultant: It’s time to move to Kubernetes. Modern, scalable, future-proof. The technology is mature, the community is massive, the reference lists are impressive.

All of this is true. The question isn't whether Kubernetes works. The question is what specific problem it solves – and whether that problem actually exists in your own company.

The Reality on the Ground

A mid-sized company with up to 150 employees usually has a manageable infrastructure. Two, maybe three physical servers. These host virtual machines – a domain controller, a file server, a terminal server, maybe an application server, and an update management system. Alongside those is a handful of containerized services: a database, a cache, a reverse proxy, perhaps an identity management system.

Five to twenty containers across two or three servers. Each runs as a single instance – no horizontal scaling, no redundancy, no automatic failover. Not because the IT setup is poor, but because this infrastructure is perfectly adequate for its purpose.

What Kubernetes Was Built For

Kubernetes was designed to orchestrate tens of thousands of containers across thousands of servers. Automatic rescheduling on node failure, service discovery for hundreds of services running in parallel, rolling deployments with zero downtime in environments that push code multiple times a day.

These requirements absolutely exist. At Google, at Netflix, at platforms with millions of concurrent users.

Twenty containers on three servers have entirely different requirements. They simply need something that starts them reliably – in the correct order, after a host reboot, without manual intervention. That is a solved problem. It was solved long before Kubernetes even existed.

The Staffing Question

The underlying idea of automation is correct: Repetitive, manual tasks should be taken over by technology so that skilled employees can use their time for value-adding activities. This is not an end in itself; it simply makes economic sense.

Kubernetes promises exactly that. In the reality of mid-sized businesses, however, it turns this logic upside down: Instead of freeing up capacity, it drains it. Certificate rotation, cluster upgrades, access control, network configuration – that is a full-time job. In companies that run Kubernetes seriously, it’s several full-time jobs.

Currently, the vast majority of SMEs do not have a dedicated role for this. There is a sysadmin who also manages the phone system, maintains the printers, and occasionally explains why the CEO's laptop won't connect to the Wi-Fi. Now, this exact same administrator is expected to casually operate the highly complex Kubernetes cluster that an external consultant just recommended to management.

The result is highly predictable: The cluster runs fine, as long as nothing happens.

P.S. When something does happen, it usually happens on a Friday.

The Cloud Bill

Those who shy away from personnel costs can outsource operations to hyperscalers like Microsoft, Amazon, or Google. Their managed services remove the operational overhead – in exchange for a monthly bill that grows with usage and whose total is notoriously difficult to predict.

What gets underestimated here isn't just the cost alone. It is the dependency that is created: Once you have fully migrated your infrastructure to such a service, you are completely reliant on its availability. If the internet connection fails, operations come to a halt. If the provider exits the market or changes their terms, your options are severely limited. And sensitive business data – client information, patient records, manufacturing secrets – suddenly resides on infrastructure you do not control, in data centers whose exact location is contractually defined as "somewhere in the EU."

Once fully migrated, you don't easily return. Not because it would be technically impossible – but because no one has the time or budget to do it.

What Actually Works Instead

Twenty containers on three servers do not need an orchestration platform. Modern operating systems already provide this foundation out of the box. Combined with resource-efficient container engines like Podman, services can be managed perfectly without introducing external orchestration behemoths. Their behavior has been documented and predictable for years. Their configuration is out in the open – readable, versionable, and auditable.

A crucial aspect here: Containers should be run rootless (without elevated system privileges). What does this mean in practice? A container running with full administrator rights can, in the event of an error – or after being compromised by attackers – break out and access the entire host system. Data can be exfiltrated, other services manipulated, and the blast radius expands. A rootless container remains locked inside its own isolated environment. What happens there, stays there. This is not just an academic security concept – it is the difference between a contained incident and a complete data loss.

How data is backed up and restored in this model is a separate topic – and an equally underestimated one.

This sounds entirely unspectacular. That is exactly the point.

An infrastructure that surprises no one, that comes back online without manual intervention after a power outage, that can be completely understood and maintained by two people – that is not a compromise. That is the goal.

Control Over the Infrastructure is Control Over the Data

An environment that operates without external cloud dependencies runs on your own hardware or on dedicated bare-metal machines at a trusted hosting provider. The data resides exactly where the operator puts it.

For a law firm, a medical practice, or a company handling sensitive intellectual property, this is not an abstract consideration. It is a hard requirement – for data protection, for client trust, for one's own risk management. This requirement can be met far more reliably with a manageable, self-hosted infrastructure that everyone on the team fully understands, than with a distributed platform whose underlying complexity no one completely grasps anymore.

The Real Question

What specific business problem are we trying to solve – and does this problem actually exist here?

Kubernetes is the right answer to a specific class of problems. These problems are real. But they arise at a scale and complexity that SMEs generally do not have – and frankly, do not need to strive for.

The right technology for the right purpose. That is not a limitation. That is an engineering decision.