The real cost is not the control plane
A managed control plane is inexpensive. The cost is everything around it: ingress and certificate management, secrets, network policy, autoscaling tuning, upgrade cycles every few months, RBAC design, observability, cost attribution per namespace, and at least one person who genuinely understands all of it at 3am. That is a platform team, not a line item.
The threshold test
Kubernetes starts paying for itself when several of these are true: more than roughly eight independently deployable services; multiple teams needing isolation without stepping on each other; genuinely bursty or unpredictable load; a real requirement to run the same workloads across clouds or on-premise; or workloads needing fine-grained scheduling control. One or two of those is not enough.
What to use instead, deliberately
Azure App Service, AWS ECS on Fargate, and Google Cloud Run cover a large majority of business applications with a fraction of the operational surface. You get containers, autoscaling, managed TLS, blue/green deployment and rollback — without owning a scheduler. We have moved clients off Kubernetes onto these and watched both cost and incident count fall.
The migration path stays open
The genuine argument for adopting Kubernetes early is avoiding a painful migration later. In practice, if your services are containerised, configuration is externalised, state lives in managed data services and infrastructure is defined as code, moving to Kubernetes later is a matter of weeks. Those four properties are worth having regardless — they are the actual portability, not the orchestrator.
How we advise
We ask how many engineers you can realistically dedicate to platform work. If the answer is fewer than two, we recommend against self-managed Kubernetes almost every time, because an under-maintained cluster is a worse outcome than a simpler platform. Recommending less technology than a client expected is a normal result of our assessments.