The question this answers
This system is two engineers, one API and a hundred requests per second. Does it need Kubernetes?
A B2B SaaS API with a managed PostgreSQL behind it. Steady traffic around 100 requests per second, peaking near 300. Two engineers, both writing product code. Deploys a few times a week. Downtime is bad but not life-threatening; a five-minute outage costs an apology, not a customer.
A defensible answer to the adoption question, and — when the answer is no — a set of simpler platforms that deliver the operational properties the team actually needs.
The answer is no, and here is the reasoning
Take the requirement seriously and list what this system actually needs. It needs the application running on more than one machine so that a reboot is not an outage. It needs a deploy that does not drop requests. It needs the process restarted if it dies. It needs TLS with certificates that renew. It needs logs, metrics and an alert when something is wrong. It needs the database to be someone else's problem.
Every single one of those is available from a managed container platform, a PaaS, or two VMs behind a load balancer — with no control plane, no RBAC model, no scheduler, no CNI, no ingress controller and no cluster upgrade. The list of things this system needs and only Kubernetes provides is empty.
Now list what adopting a cluster adds. A control plane to keep available and upgrade on the provider's schedule. A node pool to size, patch and replace. A network layer with its own failure modes. An RBAC model to design. An ingress controller to run. A monitoring stack for the platform itself, distinct from the one for the application. A vocabulary of two dozen object kinds that both engineers must learn well enough to debug at 03:00. And the ongoing tax: every Kubernetes release, every operator upgrade, every CVE in a component you did not choose.
Two engineers spending a meaningful fraction of their time on that are not building the product. That is the real cost, it does not appear on any invoice, and it is the reason the answer is no.
| Actual requirement | Kubernetes gives it via | So does | Verdict |
|---|---|---|---|
| Run on more than one machine | Deployment with replicas and a spread rule | Two VMs in an instance group; any managed container platform | No cluster needed |
| Deploy without dropping requests | Rolling update gated on readiness | Rolling deploy on an instance group; a PaaS release | No cluster needed |
| Restart on crash | Node agent restart policy | systemd; the platform's task supervisor | No cluster needed |
| TLS with renewing certificates | Ingress controller plus a certificate operator | Managed load balancer with a managed certificate | Simpler outside the cluster |
| Config and secrets outside the image | ConfigMap and Secret objects | The platform's config panel; a managed secret store | Simpler outside the cluster |
| Scale with traffic | HorizontalPodAutoscaler | Instance group autoscaling; per-request scaling on a PaaS | No cluster needed |
| Logs, metrics, alerts | A monitoring stack you install and operate | Whatever the platform ships with, plus a hosted backend | Simpler outside the cluster |
| A reliable database | A StatefulSet plus an operator, or a managed database | A managed database | Managed either way — see Managed vs Self-Hosted |
What a cluster actually costs
The financial argument for Kubernetes at small scale is weak, and it is not even the main argument against. The control plane is a fixed charge. The node pool must be large enough to hold your workloads *plus* the platform components — ingress controller, metrics stack, log agents, CSI and CNI daemons — plus headroom for rescheduling and for surge during rollouts. On a small cluster the platform overhead is a startlingly large fraction of what you pay for.
But the item that dominates is engineering time, and it is worth being concrete about what it consists of. Learning the object model and the failure modes. Cluster upgrades several times a year, each one a real change-management exercise. Debugging problems whose cause is in a layer you did not write. Building the runbooks. Being the person who understands the ingress controller when it starts returning 503s. For a team of two, that is not a line item — it is a fraction of your total engineering capacity.
None of this means Kubernetes is bad. It means it is priced for a different problem: many teams, many services, shared infrastructure, and enough scale that a platform team is justified. Buying it for two engineers and one API is buying a tool whose value curve starts well past where you are standing.
Bars are relative weights, not currency. Real rates depend on provider, region, commitment and volume.
The alternatives, and the conditions that actually change the answer
The honest ladder, cheapest first. A PaaS: push a repository, get a running, TLS-terminated, auto-restarted, rolling-deployed application. You give up fine-grained control and accept a pricing model that becomes unattractive at scale, and in exchange two engineers ship product. A managed container service: you keep your container images and a task definition, the provider does placement, restarts and rollouts; no cluster, no control plane, no scheduler. Serverless: excellent for spiky and event-driven work, with cold starts and a connection problem against a pooled database — see Serverless Trade-offs. Two or three VMs behind a load balancer with an immutable image per release: unglamorous, cheap, well understood, and it survives a machine loss.
Now the conditions that genuinely justify a cluster, stated as things you can check rather than feelings. Scale of teams: many services owned by many teams needing one consistent deployment interface. Workload diversity: batch jobs, cron work, long-running services, GPU work and stateful systems that would otherwise need four different platforms. Bin-packing economics: enough workloads that utilization gains fund the platform. A hard portability or on-premises requirement: a genuine need to run the same platform in a data center and in a cloud. Ecosystem dependence: an operator that solves a real problem you would otherwise build. An existing platform team: someone whose job this already is.
Notice what is not on that list: "it is what serious companies use", "we might need it later", "the job market expects it", "our consultant recommended it". Those are the reasons it usually gets adopted, and none of them survives contact with the 03:00 question — *who on this team can debug the ingress controller?*
And the migration path is real. Starting on a PaaS or a managed container service does not lock you out of Kubernetes. Your application is already containerized, already configured through the environment, already stateless, already emitting logs and metrics — which is most of the work. Moving later, once you can name the pressure that justifies it, is a straightforward project. Adopting early to avoid a migration that may never be necessary is paying today for an option you may never exercise. See No Cargo-Cult Infrastructure and Scoring Operational Complexity.
# What you now own, permanently: # 1 managed control plane (× staging, × production) # 3 worker nodes, sized, patched and replaced # ingress controller Deployment + certificate operator # metrics stack, log agents, CNI, CSI # RBAC model, network policies, namespace layout # ~12 manifests per service, and a templating tool to manage them # cluster upgrades several times a year # # What you can debug at 03:00: whatever one of the two of you has learned so far. # What you shipped this quarter: less than you planned. apiVersion: apps/v1 kind: Deployment # ... plus Service, Ingress, ConfigMap, Secret, Certificate, HPA, PDB, # ServiceMonitor, NetworkPolicy — and none of it is the product.
# A managed container platform or a PaaS:
service: api
image: registry.example/api@sha256:9f2c...
instances: 3 # more than one machine: a reboot is not an outage
health_check: /readyz # rolling deploy waits for this
env_from: secret_store/api # config and credentials outside the image
domains: [api.example.com] # TLS terminated and renewed by the platform
autoscale: { min: 3, max: 12, target_cpu: 60 }
# database: managed PostgreSQL, private networking, automated backups
# logs and metrics: shipped to a hosted backend
#
# What you own: the application, the Dockerfile, this file.
# What you can debug at 03:00: your own code.
# Migration to Kubernetes later, if a real pressure appears: the container,
# the config-from-environment and the statelessness are already done.The second version delivers every operational property the requirement named. The first delivers those same properties plus a platform, and the platform is what the two engineers would spend their time on.
Key points
- For two engineers, one API and 100 requests per second, the answer is no — and the reasoning is that nothing the system needs is available only from a cluster.
- A cluster costs a control plane, a node pool, a network layer, an RBAC model, an ingress controller, a platform monitoring stack and a large vocabulary — permanently.
- The dominant cost is engineering time, which appears on no invoice and is the actual reason the answer is no.
- The real alternatives are a PaaS, a managed container service, serverless, or a few VMs behind a load balancer — each delivers multi-machine redundancy, safe deploys, restarts and TLS.
- Adopt when you can name the pressure: many teams and services, diverse workload types, bin-packing economics, a hard portability requirement, or an existing platform team.
- Starting simpler does not lock you out. A containerized, config-from-environment, stateless application has already done most of the migration work.
The loop, answered
Every field is required, which is why no lesson here can recommend something without saying what it costs and what simpler thing to consider first.
- • Start from the requirement list, not the platform: multi-machine redundancy, safe deploys, restart on failure, TLS, config injection, observability, a reliable database.
- • For each requirement, name the simplest thing that satisfies it, and check whether a cluster is the only source.
- • Count what a cluster adds that nothing else in the list needed: control plane, node pool, network layer, RBAC, ingress controller, platform monitoring, object vocabulary.
- • Price the addition in engineering time as well as money, per environment.
- • Adopt only when a named, checkable condition — team count, workload diversity, utilization economics, portability, ecosystem, existing platform team — makes the addition worth it.
- • Whatever you choose, you still own: the application, the image, deployment configuration, monitoring, and the database decisions.
- • On a PaaS you additionally own the platform's constraints — its build system, its networking model and its pricing curve as you grow.
- • On a cluster you additionally own the entire platform, in perpetuity, including upgrades on someone else's schedule.
- • The decision itself is worth revisiting annually, in both directions: teams outgrow a PaaS, and teams also run clusters they no longer need.
- • Adopting early: a small team spends a quarter on platform work and ships less product, with no incident that the platform prevented.
- • The 03:00 problem: the one person who understood the ingress controller is on holiday, and nobody else can debug a component nobody wrote.
- • Cluster sprawl: one cluster per environment per team, each with a control plane charge and an upgrade obligation.
- • The opposite failure: staying on a PaaS past the point where its pricing curve, build constraints or networking model are genuinely blocking, out of the same inertia that caused the first mistake.
- • Copying a large company's architecture without its platform team, which is how most unnecessary clusters begin.
- • A PaaS scales fine technically and becomes unattractive on price and control somewhere in the mid-hundreds of requests per second to low thousands, depending on the provider.
- • A managed container service scales considerably further and rarely becomes the binding constraint for a single-product company.
- • Kubernetes' advantage grows with the number of *teams and workload types*, not with request volume — a very high-traffic single service does not need it.
- • Whatever you run on, the database is the first real ceiling, and it is the same ceiling on every platform.
- • A smaller platform is a smaller attack surface: no cluster API, no RBAC misconfiguration, no privileged operators, no CNI to keep patched.
- • Managed platforms move the patching obligation to the provider, which is a genuine security improvement for a team without a platform engineer — see Shared Responsibility.
- • The security work that does not go away on any platform: workload identity, least privilege, secret lifecycle, and not exposing a database to the internet.
- • A cluster nobody has time to keep patched is less secure than a managed platform, regardless of what its policy documents say.
- • A cluster adds a fixed control-plane charge per environment plus node capacity for platform components that a simpler platform does not require.
- • A PaaS typically costs more per unit of compute and less per unit of engineering time — which is the correct trade for a small team and the wrong one at scale.
- • The comparison that decides it is not compute price; it is engineering time, and it favours the simpler platform decisively at small team sizes.
- • Idle and headroom capacity are a larger fraction of a small cluster than of a large one, which is why cluster economics improve with scale — see Idle Capacity: Headroom or Waste?.
- • Fraction of engineering time spent on platform work rather than product — the single most honest metric for this decision.
- • Number of incidents whose root cause was in the platform rather than in the application.
- • How many people on the team can independently debug a platform failure; if the answer is one, that is a risk, not a capability.
- • Deployment frequency and lead time before and after adoption — if a platform made shipping slower, it is not paying for itself.
- • The signal that lies: "the cluster is healthy". A perfectly healthy cluster that nobody needed is still the wrong decision.
- • A platform-as-a-service: push a repository, get a rolling-deployed, TLS-terminated, auto-restarted application. The right answer for most small teams.
- • A managed container service: your images and a task definition, with the provider handling placement, restarts and rollouts — no control plane.
- • Serverless functions for spiky and event-driven work, accepting cold starts and the connection problem against a pooled database.
- • Two or three VMs behind a load balancer with an immutable image per release — boring, cheap, survives a machine loss, and understood by everyone.
- • A single machine, for genuinely internal or low-stakes systems. Not everything needs redundancy, and pretending otherwise is its own cargo cult.
- • Choosing simpler buys engineering focus; costs flexibility you may want later and a migration you may eventually do.
- • Choosing Kubernetes buys a uniform interface across many teams and workload types; costs a platform you must run whether or not you have those teams.
- • A PaaS buys the lowest operational burden available; costs unit economics and control that get worse as you grow.
- • Every option costs something. The failure is not picking the wrong one — it is picking without naming what the workload actually needs.
Do you need Kubernetes?
What people believe, and what is true
Kubernetes is the industry standard, so it is the safe default.
It is the standard for organizations with many teams, many services and a platform team. As a default for two engineers it is a large, permanent cost with no matching requirement.
We should adopt it now to avoid migrating later.
A containerized, config-from-environment, stateless application has already done most of the migration work. You are paying today for an option you may never exercise.
A managed Kubernetes service means the provider runs it for us.
They run the control plane. The nodes, networking, RBAC, ingress, monitoring, upgrades and the entire object model remain yours.
Not using Kubernetes means giving up self-healing, rolling deploys and autoscaling.
Every alternative in this lesson provides all three. They are properties of a platform, not of one specific orchestrator.