Serverless, Explained Without the Marketing

The properties that matter

• Scale to zero. No traffic, no cost. This is the defining economic feature.
• Automatic scaling from one request to thousands without configuration.
• Per-invocation billing, typically by request count and by memory multiplied by duration.
• No infrastructure management — no OS, no patching, no capacity planning.
• Event-driven — triggered by HTTP, queues, storage events, schedules.
• Execution limits — a maximum duration, memory and payload size.

Cold starts, honestly

When no instance is warm, the platform must create one: allocate a sandbox, load the runtime, initialise your code. That latency lands on the first request.

Typical cold starts range from tens of milliseconds to a few seconds. For background and event processing this is irrelevant; for a user-facing request path it may not be. Provisioned concurrency keeps instances warm at a cost that partly undoes the pricing advantage.

Where it fits well

• Webhook receivers and event handlers.
• Scheduled jobs, replacing a server that exists only to run cron.
• Image and file processing triggered by uploads.
• Glue between services and APIs.
• Genuinely spiky traffic with a low average.
• Internal tools and admin functions used occasionally.

The scheduled job case is underrated. Replacing an always-on instance whose only purpose is a nightly script removes a server, its patching and its cost.

Where it fits badly

• Sustained high traffic, where a server is cheaper above a modest volume.
• Long-running work that exceeds execution limits.
• Latency-critical paths where cold starts are unacceptable.
• Anything needing persistent connections or in-memory state between requests.
• Workloads with heavy database connection use — connection pooling is genuinely awkward.

Database connections deserve emphasis. Thousands of concurrent function instances each opening a connection will exhaust a database. Use a connection proxy or a database designed for HTTP access.

Practices that avoid trouble

1. Set concurrency limits. Without them, a loop or an attack bills without bound. This is the single most important control.
2. Keep functions small and single-purpose.
3. Initialise clients outside the handler, so warm invocations reuse them.
4. Make handlers idempotent — retries happen, and at-least-once delivery is normal.
5. Set timeouts deliberately, shorter than the platform maximum.
6. Use a dead letter queue so failed events are not silently lost.
7. Keep business logic in ordinary functions and the handler thin, so it remains portable and testable.

The economics

Serverless is dramatically cheaper at low and spiky volume, and more expensive at sustained high volume. The crossover depends on request duration and memory, and it arrives sooner than most people expect.

Calculate it directly: cost per invocation multiplied by monthly invocations, against the monthly cost of a server that would handle the same load. Include the operational cost of the server, which is real.

Common questions

Where to go next

See choosing a deployment target and cloud pricing models compared.