Serverless
Serverless as an execution model: event to platform to invocation to scale-down. Cold starts, runtime limits, enforced statelessness, concurrency caps, the connection problem against a pooled database, observability gaps and the cost shape that is cheap until it is not.
Not "no servers" — a different unit of allocation. Code is registered with a platform, an event causes an execution environment to exist, the code runs, and the environment is reclaimed. Everything surprising about serverless follows from that last clause.
Q · What actually happens between an event arriving and my code running, when there is no instance I provisioned?
Cold starts, wall-clock limits, enforced statelessness, concurrency ceilings, thin observability and a bill that is linear in traffic. The honest sheet — including why "serverless is always cheaper" is a red flag rather than a summary.
Q · What am I actually giving up when I move a workload onto a function platform?
The arithmetic that breaks the first serious serverless deployment: 20 app servers held 20 connections; 1000 concurrent function environments want 1000, against a database that accepts 100. The proxy is the answer, and it is not free.
Q · Why does a function that worked perfectly in staging exhaust the database the first time real traffic arrives?