The serverless versus containers debate is usually framed as a maturity ladder, with serverless at the top and virtual machines at the bottom. That framing is wrong. They are different shapes for different work, and the right answer depends on how your load arrives, how your team operates and how painful it would be to leave.
We have run both in production and migrated in both directions. The expensive mistakes were rarely about the technology itself. They were about choosing a shape that did not match the workload, then discovering the mismatch through an incident or an invoice.
The decision is about load shape
Start with the traffic pattern. Is it steady through the day, spiky around a few events, or silent until a file arrives? Steady load suits containers because you can keep a warm process and predict the cost. Spiky, event-driven work suits serverless because you pay for execution rather than idle capacity.
Then look at the runtime. A standard language and framework fits either model. A custom binary, a legacy runtime or a long-running worker fits containers more comfortably. A short function that reacts to an upload or a webhook fits serverless almost perfectly.
Where serverless actually saves money
Serverless saves money when usage is intermittent. A function that runs for two hundred milliseconds when a form is submitted costs almost nothing at low volume. The same workload on an always-on container pays for idle hours, and a small team pays twice: once for the server and once for the attention needed to keep it patched.
It also saves operational time. There is no host to patch, no capacity plan for a launch and no midnight page about disk space. For a team without a dedicated operations engineer, that reduction in surface area is often worth more than the per-request price.
Where containers still win
Containers win when the workload is steady and the cost per request matters. At high, predictable volume, a reserved container can be cheaper than millions of invocations. They also win when the process needs to stay alive: a websocket server, a video encoder, a background worker that holds state in memory.
Portability is the other advantage. A container image runs on a laptop, a staging cluster and a managed service with few changes. That matters if the team expects to move providers or run in more than one environment. Serverless platforms are convenient precisely because they hide the runtime, and that convenience is also the lock-in.
Choose the shape that matches the load, then check what it costs to leave. Convenience with no exit is a subscription, not an architecture.
Cold starts, connections and timeouts
Cold starts get more attention than they deserve. For most web requests, a few hundred milliseconds is invisible next to the time a database query takes. The real problem is usually connection management: a function that opens a new database connection on every invocation will exhaust the pool long before cold starts become the bottleneck.
Use a pooler, keep connections outside the handler where the platform allows it, and set timeouts that match the work. A function with a thirty-second timeout and a ten-second downstream call is a queue of stuck requests waiting to happen. Test the failure path, not just the happy path.
Observability and debugging
Serverless debugging is better than it used to be, but it still rewards discipline. Structured logs, a request identifier passed through every call and a trace that survives the function boundary are not optional. Without them, a failure across three functions looks like three unrelated errors.
Containers give you a familiar toolbox: shell access, process metrics, a local reproduction. That familiarity is worth a lot during an incident. If the team is small and the on-call rotation is thin, choose the model whose failure modes you can diagnose at two in the morning.
Portability and exit cost
Before committing, estimate the cost of leaving. How much of the application depends on a proprietary queue, scheduler or identity service? Can the data be exported in a usable format? Is there a second region or provider that could run the same workload? The answers do not need to be perfect, but they should be written down.
A managed platform is a good deal when the team uses its features and a bad deal when it only uses the compute. Paying for a full platform to run a single cron job is a common and expensive mistake.
A checklist before you migrate
- Describe the load pattern in one sentence: steady, spiky or event-driven.
- List the runtime requirements, including any custom binary or long-running process.
- Estimate the monthly cost at current volume and at three times current volume.
- Name the observability tools and confirm they work across the boundary.
- Write down the exit path and the data export format.
- Run a small production-like workload for two weeks before moving the core.
For the cost side of the same decision, read our cloud cost control playbook. For the tools that sit in front of the application, see our Web Tools section.
