Serverless Compute in Practice
also called Functions as a Service, FaaS
Compute billed per invocation with no capacity to manage — excellent for bursty low-duty-cycle work, expensive and constrained for sustained load.
Definition
Code runs in response to an event, scales automatically from zero to many concurrent executions, and is billed by invocation and duration. There is no instance to size, patch or keep warm.
Where it genuinely wins
- Bursty, unpredictable, low-duty-cycle work. Image processing on upload, webhook handling, scheduled jobs, glue between services.
- Traffic that arrives as a spike with no warning. A publishing event, a marketing send, a breaking news story.
- Workloads where operational capacity is scarcer than money, which describes most small teams.
Publishing platforms are a good fit for exactly this reason: the write path is low volume and highly irregular — a burst of activity when a major story breaks, near-idle at other times — while the read path is served from a CDN entirely. Paying for permanently provisioned capacity to serve an irregular write workload is paying for the peak all month.
Where it goes wrong
Sustained load. Above a certain duty cycle, functions cost several times a reserved instance for the same work. The crossover is calculable and frequently ignored.
Cold starts. The first invocation of an idle function pays initialisation cost, which lands at p99 and is worst for exactly the runtimes and dependency graphs enterprises use. Provisioned concurrency fixes it and reintroduces the fixed cost you were avoiding.
Connection-oriented downstreams. Hundreds of concurrent function instances each opening database connections exhausts the limit immediately. A connection pooler between them is mandatory.
Long or stateful work. Execution time limits, no local state between invocations, and no long-lived connections make some workloads simply unsuitable.
Local development and testing are meaningfully harder, and this cost is paid by every engineer every day rather than showing up on a bill.
Failure scenarios
- A function retried by the platform on failure, applied to a non-idempotent side effect.
- Fan-out without a concurrency cap, so a spike launches thousands of concurrent executions and overwhelms a downstream that has no such elasticity. The function scales; the database does not.
- A timeout shorter than the work, failing silently at the limit.
- Vendor coupling through event formats and identity, making the workload expensive to move.
Trade-offs
Bought: zero capacity management, automatic scaling, per-use billing, and fast delivery for small pieces of work. Sold: cost efficiency at sustained load, latency predictability, execution duration, local development ergonomics, and portability.
The most useful framing: serverless is excellent at the edges of a system — event handling, glue, irregular jobs — and questionable at its core.
Interview question
"A function fans out to 5,000 concurrent executions during a spike and takes down the database. What are your options?"