What Is Serverless Computing? (And What It Isn't)
Why the Name Is Misleading
Serverless does not mean there are no servers. There are obviously servers — they are just someone else's. The name refers to a billing and operations model in which the cloud provider provisions, scales, and maintains the underlying compute, and you only interact with the application layer. You do not pick an instance size, you do not patch the OS, and you do not pay for idle time. You hand over a function, trigger it, and walk away.
The most familiar form is Functions-as-a-Service, exemplified by AWS Lambda. You upload a small piece of code that takes an event as input and returns a response — an HTTP handler, a queue worker, a scheduled job. The provider spins up an execution environment when the function is called and tears it down when it finishes. If nobody calls the function, it costs nothing.
Why It Fits Spiky Workloads
The cost model is where serverless shines. A traditional always-on server bills you for compute whether or not anyone is using it. Serverless bills you per invocation and per millisecond of execution time. For workloads with bursts — image processing triggered in response to uploads, webhooks fired occasionally, scheduled jobs that run a few times an hour — the math tends to work strongly in your favor.
The tradeoffs that surprise teams are predictable. Cold starts add latency when a function has not been invoked recently. Long-running tasks hit provider timeout limits. Vendor-specific tooling can lock you in, and debugging distributed traces across many small functions is harder than reading logs from one server. Serverless is a tool, not a religion. It fits spiky, small, stateless workloads very well and fits large, steady-state, long-running services poorly.
The Edge Review writes plain-English infrastructure explainers. Provider offerings and pricing change frequently; verify specifics against current vendor documentation before architecting production systems.