Serverless

Serverless means running code without provisioning or managing any servers. You hand the provider a function or a container; it handles capacity, scaling, and patching, and bills you per request or per second of execution, nothing while idle. The servers still exist; you just never see, size, or patch one.

In plain terms

A virtual machine is a rented server that runs, and bills, whether anyone uses it or not. Serverless drops the server from the deal: you upload a function like “when an image lands, make a thumbnail,” and the platform runs it on demand, scaling from zero to thousands of parallel executions and back to zero on its own. AWS Lambda, Azure Functions, and Google Cloud Run are the canonical examples; it’s the far end of the IaaS → PaaS spectrum, where the platform owns everything below your code.

Why it matters when you migrate

• It’s built for spiky, event-driven work. Webhooks, background jobs, scheduled tasks, APIs with uneven traffic, workloads that idle most of the day often cost a fraction serverless of what they cost on always-on VMs, with autoscaling handled for you.
• It’s a rebuild, not a move. A traditional app won’t run serverless unchanged, this is the refactor end of the strategy spectrum, so reserve it for workloads where the payoff justifies rewriting.
• Know the sharp edges before committing. Cold starts add latency, execution time limits are hard caps, and per-invocation pricing at sustained high volume can cost more than a VM, model your traffic first.