When Kubernetes is too much: simpler ways to run containers

We run Kubernetes for clients who need it, and we like it. We also spend a fair amount of time talking clients out of it. The pattern is familiar: a team of four engineers building a single web application and a background worker reads that serious companies run on Kubernetes, sets up a cluster, and six months later spends a third of its engineering time on ingress controllers, certificate managers, node upgrades and YAML. The application has not changed; the operational burden has. Containers are almost always a good idea. A full orchestrator is a separate decision that deserves its own justification.

What Kubernetes is actually good at

It helps to be precise about the problems Kubernetes solves well:

• Running many services, often dozens, with different scaling needs on a shared pool of machines.
• Bin-packing workloads efficiently to keep infrastructure costs down at scale.
• Providing a consistent deployment and networking model across multiple teams.
• Portability across clouds or into on-premises data centers.
• A large ecosystem of operators for running stateful software such as queues and search engines.

If several of those describe your situation, a managed cluster is a reasonable choice. If none of them do, you are paying the complexity cost without collecting the benefit.

What it costs a small team

A managed Kubernetes service removes control plane management, but plenty remains. Someone must own cluster and node upgrades, which arrive every few months and occasionally deprecate APIs your manifests use. Someone must understand networking policies, ingress, DNS inside the cluster, persistent volumes, resource requests and limits, and how the autoscaler interacts with all of them. Security configuration, from RBAC to pod security standards, is its own discipline.

For a team of three to six engineers, our experience is that a well-run cluster needs somewhere between a quarter and a half of one engineer's time on an ongoing basis. That is time not spent on the product. The compute bill is often higher too, because small clusters have fixed overhead: control plane fees, system pods and the headroom needed for rolling updates.

Containers are a packaging decision. Kubernetes is an operations decision. Teams often make the second by accident while making the first.

The simpler options

Between a single server and a full cluster, there is a wide range of options that run containers well.

Managed container platforms. Services that take an image and run it with autoscaling, health checks, rolling deploys and TLS handled for you. On the major clouds these are the serverless container offerings; there are also several developer-focused platforms. For a typical web app plus worker, this is our default recommendation. You get most of the deployment benefits of Kubernetes with a fraction of the configuration.

A few virtual machines with Docker Compose. For steady workloads, two or three VMs behind a load balancer, each running the same Compose file, are simple to understand and cheap. Deploys can be a pipeline job that pulls the new image and restarts containers one host at a time. It lacks autoscaling, but many applications do not need it.

Serverless functions for the edges. Scheduled jobs, webhooks and image processing often fit well as functions alongside a containerized core, removing the need for a permanently running worker for occasional tasks.

A decision checklist

When a client asks whether they need Kubernetes, we work through these questions:

1. How many independently deployed services do you run today, and how many in a year? Fewer than five usually points away from a cluster.
2. Do you have, or plan to hire, someone whose job includes cluster operations?
3. Is your traffic bursty enough that bin-packing and fine-grained autoscaling would materially change the bill?
4. Do you have a hard requirement for multi-cloud or on-premises portability?
5. Are you running stateful components that would benefit from operators, or can those be managed services?

Mostly no answers point to a managed container platform or VMs. Mostly yes answers point to a managed cluster. A mix usually means starting simple and designing for a later move.

Keeping the door open

Choosing a simpler platform now does not lock you out of Kubernetes later, provided you follow a few practices from the start:

• Package everything as a container image built once in CI and promoted between environments.
• Configure applications through environment variables and keep secrets in a secret manager.
• Keep the application stateless, with sessions, files and queues in managed services.
• Expose a proper health endpoint and handle termination signals gracefully.
• Define the infrastructure in code so a future migration is a translation, not an archaeology project.

We moved one client from a managed container platform to Kubernetes after they grew from two services to fourteen. Because those practices were in place, the migration took five weeks and required almost no application changes.

Going the other direction happens too. A client came to us with a three-node cluster running one application and a cron job. Moving them to a managed container platform took two weeks, cut their monthly infrastructure bill by about 40 percent, and removed a quarterly upgrade task that had caused two outages the previous year.

Getting it right for your size

Whichever direction you are heading, our Docker and Kubernetes practice covers both containerizing an application and running clusters when they are justified. For teams whose event-driven workloads suit it, serverless architecture can replace much of what a cluster would otherwise run, and a managed cloud hosting plan takes day-to-day operations off your team entirely.

Choose the platform that fits your team

If you are weighing up a cluster, or wondering whether the one you have is earning its keep, we are happy to give a straight answer. Tell us about your services and team, and we will send a fixed-price recommendation and migration plan within 24 hours. Ask us here.