Kubernetes is a strong platform when you need the things Kubernetes is good at: scheduling many workloads, consistent deployment primitives, workload isolation, extensibility and a common operational layer across teams. It is a poor choice when the reason is simply that the application runs in containers. A container is a packaging format; it does not imply a cluster.
Do not buy a platform problem before you have one
A small SaaS team usually needs to ship product, run a few services reliably and keep operational work predictable. Managed application platforms, serverless containers or a managed container service can often do that with fewer moving parts. Kubernetes adds a control plane, networking model, ingress, policy, secrets integration, observability choices, upgrade work and a larger surface for incidents.
Kubernetes starts making sense when repetition becomes the problem
- Many services need the same deployment, policy and observability primitives.
- Several teams need self-service environments without platform engineers provisioning each one manually.
- Workloads have materially different scaling, scheduling or isolation requirements.
- The organization needs a consistent runtime across multiple cloud or on-premise environments for a reason stronger than vendor avoidance alone.
Team size is not a magic threshold
There is no useful rule such as 'Kubernetes after twenty engineers.' A smaller team running a compute-heavy multi-tenant product may have a legitimate scheduling problem. A much larger team running a conventional web application may be better served by a simpler runtime. The question is whether Kubernetes removes more operational work than it creates for the actual workload and organization.
Managed Kubernetes does not remove platform ownership
EKS, AKS and GKE remove the burden of operating much of the control plane. They do not own your workload policies, resource requests, node strategy, network policy, ingress, autoscaling, GitOps, application observability or upgrade compatibility. A managed control plane reduces work; it does not turn Kubernetes into a zero-operations service.
The migration cost runs both directions
Teams sometimes choose Kubernetes because it feels like the most future-proof option. That only helps if the future actually needs it. Moving a well-containerized service from a managed runtime into Kubernetes later is usually easier than simplifying a deeply cluster-dependent platform after years of custom controllers, policies and deployment assumptions.
Choose Kubernetes for a constraint you can name. 'We may need it later' is not a constraint.
A practical decision test
- 1.List the capabilities the current runtime cannot provide without significant custom work.
- 2.Estimate the platform responsibilities Kubernetes would introduce, including upgrades and incident ownership.
- 3.Check whether a simpler managed service satisfies the same requirements with acceptable limits.
- 4.If Kubernetes still wins, define the supported path and guardrails before onboarding many teams.
Kubernetes can be the right answer and still be a bad default. The decision is strongest when the team can explain exactly which constraints require it and who will own the platform after the first deployment succeeds.