An organisation with eight services and four engineers proposes adopting Kubernetes. Make the case against, then name what would change your mind.

What is being tested

Whether you separate containers-as-packaging from containers-as-orchestration, and whether you can size a platform decision to a team.

First, separate the two decisions

Container packaging is almost certainly right. An immutable image containing the application and its dependencies means the artefact tested is the artefact deployed, dependency drift between environments largely disappears, and rollback is redeploying a previous tag. That value is available at any team size and costs very little.

Orchestration is the expensive decision, and it is the one under discussion.

The case against

Kubernetes descends from Google's internal cluster manager and carries its assumptions: many heterogeneous workloads, many teams, a dedicated platform group, and enough scale that bin-packing efficiency is worth real money.

Eight services and four engineers has none of those:

• No bin-packing problem. Eight services do not need sophisticated scheduling to fit on hardware economically.
• No multi-tenancy problem. There is one team; RBAC, quotas and namespace isolation solve a problem that does not exist.
• No platform team. The cluster becomes everyone's part-time responsibility, which means it is nobody's, and it will be under-maintained in exactly the ways that cause 3am incidents.

Against that, the cost is large and permanent: cluster upgrades, networking plugins, ingress controllers, storage classes, admission policies, and a whole class of failure — a pod evicted for memory pressure, a node draining mid-request, subnet IP exhaustion — that four engineers must learn to recognise on top of their actual product.

What to do instead

A managed container platform — a service that runs containers without exposing a cluster — or a platform-as-a-service. These deliver the genuine benefits (immutable deployments, autoscaling, rollbacks, health management) at a small fraction of the operational surface. Most of what a small team wants from Kubernetes is available without operating Kubernetes.

What would change my mind

• A dedicated platform engineer or team, because the burden then lands on people whose job it is.
• Scale where bin-packing is material — enough workloads that scheduling efficiency saves real money.
• Genuinely heterogeneous workloads needing custom scheduling: GPUs, node affinity, spot capacity with graceful eviction.
• A managed control plane plus a small, deliberately boring configuration, which is a legitimate middle path — much of the cost is in running the control plane and in over-configuring.
• An organisation-wide standard where being different costs more than conforming. This is a perfectly valid reason and should be stated as such rather than dressed up as a technical one.

The framing that lands

Not "Kubernetes is bad" — it is excellent at what it was built for. Ask: which specific problem here does it solve, and what does that problem cost us today? If the answer is "nothing yet, but we might grow", the honest response is that migrating from a managed container service to Kubernetes later is a manageable project, and doing it now consumes a large share of a four-person team's capacity for a benefit that does not yet exist.