Decision guide
Kubernetes vs Serverless vs Container PaaS
Should you run services on Kubernetes, a container platform-as-a-service, or serverless functions?
Side by side
| Criterion | Serverless functions | Container PaaS (Cloud Run, App Runner, Container Apps) | Kubernetes |
|---|---|---|---|
| Unit you deploy | Function code | Container image | Container image plus manifests |
| Scaling | Per request, to zero | Per request or CPU, often to zero | HPA and cluster autoscaling you configure |
| Operations | Lowest | Low | Highest |
| Cost at steady high load | Highest | Medium | Lowest when well packed |
| Limits | Time, memory, payload, cold starts | Request timeouts, fewer knobs | Few; you own everything |
| Portability | Low (provider APIs) | Medium (plain containers) | High |
When to choose each
Serverless functions
Functions (AWS Lambda, Azure Functions, Cloud Run functions) run per event; you deploy code, not servers.
Choose when
- Event-driven work (queues, files, schedules, webhooks)
- Spiky or low traffic
- Small teams that want zero servers
Avoid when
- Long-running connections or jobs beyond time limits
- Steady high traffic where per-request pricing costs more
Container PaaS (Cloud Run, App Runner, Container Apps)
You deploy a container image; the platform runs, scales (often to zero) and load-balances it.
Choose when
- HTTP services and workers from containers with little operations
- Scale to zero for dev and quiet services
- A handful to dozens of services
Avoid when
- Deep control over networking, scheduling or sidecars
- Workloads needing GPUs, daemons or special kernels (check support)
Kubernetes
Managed or self-run Kubernetes: full control over how containers are scheduled, networked and operated.
Choose when
- Many services and teams on a shared platform
- Portability across clouds or on-premises
- Operators, service meshes, custom controllers
Avoid when
- No one to own upgrades, security and cost
Verdict
Default to the least operations that fits: serverless functions for event-driven glue and spiky work, a container PaaS for most HTTP services and workers, and Kubernetes when you have many services and teams, need its ecosystem or portability, and can staff a platform. Containers make moving between PaaS and Kubernetes straightforward, so starting on a PaaS rarely locks you in.
Learn more
- Node.js Serverless on AWS Lambda
- Cloud Engineering in Production
- Kubernetes in Production
- System Design Problems
- Autoscale a Deployment on CPU and memory (Kubernetes)