Pay per request, or pay per running server. The billing model is really a decision about who does the operations work.
Serverless means your code runs on-demand and you pay per invocation — AWS Lambda, Cloud Functions, and edge runtimes. Containers mean your code runs continuously in a unit you control, on anything from a single VM to a Kubernetes cluster. In 2026 the line has blurred: platforms like Cloud Run, Fargate, and Fly.io run containers with serverless economics. The real question isn’t which technology is better — it’s how much operational responsibility your team should carry.
Take a webhook handler that processes maybe 2,000 requests a day, bursty and unpredictable — a Stripe payment callback, say. On Lambda, that's close to free: you pay per invocation, there's no server sitting idle between bursts, and cold starts of a few hundred milliseconds don't matter for a background webhook nobody's watching in real time. Running the same handler as an always-on container means paying for 24 hours of uptime to serve a few minutes of actual work — the economics only make sense if that container is already up serving something else.
Now take a customer-facing API with steady, predictable traffic all day. There, containers usually win: no cold starts affecting user-facing latency, and at steady volume the per-request cost of a right-sized container undercuts per-invocation serverless pricing. The pattern holds generally — bursty and unpredictable favors serverless, steady and latency-sensitive favors containers — but the actual numbers are workload-specific enough that it's worth modeling both before committing.
Functions scale from zero to thousands of concurrent executions with no capacity planning, and cost literally nothing when idle. For spiky or unpredictable workloads — webhooks, image processing, scheduled jobs, APIs with strong peaks — the economics are hard to beat, and there is no server to patch, monitor, or right-size.
The tradeoffs are cold starts (much improved, still real for JVM-class runtimes), execution time limits, and a programming model that pushes state out to databases and queues. Costs also invert at sustained load: a function serving constant high traffic can cost several times a container doing the same work. Serverless is cheapest exactly when your traffic is least predictable.
Containers run anything — any language, any runtime, long-lived processes, websockets, background workers — with no platform-imposed time limits. Managed platforms like Cloud Run and Fargate now give containers most of serverless’s ergonomics: deploy an image, get autoscaling (even to zero), pay close to usage. For most teams these platforms, not raw Kubernetes, are the right way to run containers.
Kubernetes belongs in this conversation only at a certain scale: it buys ultimate control and portability at a steep operational price — cluster upgrades, networking, RBAC, and typically a platform engineer or two. If your team is under about twenty engineers and you don’t have a dedicated ops function, a managed container platform delivers 90% of the value at 10% of the operational cost.
Traffic is spiky, event-driven, or unpredictable — and idle cost matters.
Workloads are short-lived: webhooks, APIs, scheduled jobs, glue between services.
Your team wants zero infrastructure operations.
Traffic is sustained and high — per-request pricing stops being cheap.
You need long-running processes, websockets, or full runtime control.
You're standardizing many services — a managed container platform first; Kubernetes only when team size justifies it.
Much less than they were — but they still exist, especially for heavy runtimes and VPC-attached functions. For latency-critical paths, provisioned concurrency or a container that's always warm remains the reliable answer.
No — and most teams shouldn't start there. Cloud Run, Fargate, and similar platforms run containers with autoscaling and no cluster to manage. Kubernetes pays off when scale, multi-team standardization, or portability requirements demand it.
Almost every mature architecture does: containers for the core always-on services, functions for events, jobs, and glue. The billing models complement each other.
Serverless, clearly — you pay per invocation with no idle cost, while a container platform bills for uptime whether or not it's handling requests.
Yes — serverless functions are more tightly coupled to a provider's runtime and event model, while containers are portable across any platform that runs Docker, making migration meaningfully easier.
An honest sizing guide — what Kubernetes really costs a small team, the managed alternatives that cover 90% of cases, and the signals you've outgrown them.
Read the guideA cloud migration that felt risky until every step was mapped in advance — no downtime, lower bills, less worry.
Read the case study