A team must choose between serverless functions and long-running containers for a new workload. Which characteristics decide it?

What decides it

• Request shape. Spiky, unpredictable, low-average-utilisation workloads suit serverless: you pay for what you use and the platform absorbs the variance. Steady workloads with high utilisation are cheaper on containers, and the crossover is real.
• Startup cost. If initialisation is expensive — a large runtime, a substantial cache, a model to load — serverless pays it repeatedly and containers pay it once. This frequently decides it on its own.
• Execution duration. A workload exceeding the platform's limit is not a candidate, and one close to the limit is a future incident.
• Statefulness. Anything holding a connection, a cache, a session or an in-memory working set fits containers better.
• Operational preference. Serverless removes capacity management and adds platform-specific behaviour that must be learned; containers do the reverse.

The constraint that surprises teams

Serverless moves the bottleneck rather than removing it. It solves compute elasticity and creates a connection fan-in problem at every stateful dependency: a thousand concurrent invocations attempt a thousand database connections against a store whose practical ceiling is far lower.

The fix always has the same shape — an intermediary converting many ephemeral clients into few persistent ones: a connection pooler, a queue, or a shared gateway holding upstream connections. Without it, the failure is abrupt: connections are fine, then exhausted, then everything is rejected including healthy traffic.

The hybrid that is usually right

Containers for the steady request path, serverless for the spiky and infrequent — scheduled jobs, webhook receivers, occasional processing, glue between systems.

Choosing one for everything optimises for whichever workload was considered first.

The decision property to note

This is a cheap decision to reverse if the application is written without deep platform coupling — which means keeping platform-specific handlers thin and the business logic ordinary. That thinness is the whole insurance policy, and it costs almost nothing to maintain.