Serverless Computing Explained
Serverless computing has one of the most misleading names in cloud computing — servers absolutely still exist. What "serverless" really promises is that you, the developer, never have to provision, manage, or even think about them.
Updated 2026-08-06
What "serverless" actually removes
In every earlier model covered in this course — even PaaS — you are still ultimately responsible for some notion of a running server or application instance, sized to handle expected load. Serverless computing removes that entirely: you write a function, upload it, and the platform runs it only when triggered by an event, managing all the underlying infrastructure invisibly.
Pay only for the moments it actually runs
A traditional server keeps running — and costing money — whether it is busy or completely idle. A serverless function only exists while it is actively handling a request, and billing is based on that actual execution time, often measured in fractions of a second. For applications with unpredictable or spiky traffic, this can be dramatically cheaper than keeping a server running around the clock just in case.
What triggers a serverless function
Serverless functions are event-driven — they run in response to something happening, not on a schedule of their own. Common triggers include an HTTP request arriving, a new file being uploaded to storage, a message arriving on a queue, or a scheduled timer. This event-driven shape fits naturally with modern applications built from many small, independent pieces reacting to each other.
The trade-off: less control, and startup delay
Serverless is not free of downsides. Because the platform manages everything, you have less control over the exact runtime environment than you would with IaaS. There is also sometimes a brief delay — a "cold start" — the first time a function runs after being idle, while the platform prepares an environment for it, which can matter for applications that need consistently instant responses.
When serverless fits best
Serverless shines for unpredictable, intermittent workloads — a function that runs a few times an hour versus running an idle server the whole time. For workloads that are constantly busy, a traditional server or container can end up more cost-effective.
Serverless within the bigger picture
Serverless is best understood as the far end of the same spectrum this course has been walking through — from owning physical hardware, to IaaS, to PaaS, and now to serverless, each step handing more operational responsibility to the provider in exchange for less low-level control. It is not a replacement for everything else, but one more tool, best suited to specific kinds of workloads.