A publisher must choose between serverless functions and containers for its asynchronous processing. What decides it?

What decides it

Duty cycle, primarily. Serverless bills per invocation, which is excellent for work that runs intermittently and terrible for work that runs continuously — at sustained high volume, per-invocation pricing exceeds provisioned capacity substantially.

Execution characteristics, secondarily: execution time limits, memory ceilings, whether state must persist between invocations, and whether a cold start is acceptable.

Where each fits for a publishing platform

Serverless: image derivative generation on upload, content transformation on publish, webhook receivers, scheduled jobs replacing a cron host. Bursty, stateless, independent, with long idle periods — paying per invocation for a low duty cycle is far cheaper than provisioned capacity that is mostly idle.

Containers: the editorial application, the publishing pipeline's long-running stages, anything with persistent connections, anything exceeding execution limits, and anything with sustained volume.

The decisive consideration for the read path

Neither. Serving articles is the highest-volume, most spike-prone part of the system, and the correct answer is pre-rendered content at the edge, where the marginal cost per request approaches zero and no computation happens per request at all.

Choosing between serverless and containers for the read path is choosing between two answers to a question that should not be asked.

The constraints that catch teams out

• Cold starts landing exactly when a spike begins, which is precisely when latency matters most.
• Connection exhaustion: a thousand concurrent functions each opening a database connection exceeds the limit, requiring a proxy — extra machinery that partly negates the simplicity that motivated the choice.
• Execution time limits discovered when a job grows past them.
• Local development and testing, which is harder for serverless and matters for velocity.

The pragmatic position

Both, chosen per workload. The mistake is adopting either as a platform-wide philosophy — serverless everywhere becomes expensive and awkward at the high-volume path; containers everywhere means paying for idle capacity for work that runs twice a day.