Serverless computing lets you run code without provisioning or managing servers. You deploy functions that execute in response to events (HTTP requests, database changes, file uploads, scheduled timers) and the cloud provider handles all infrastructure, scaling, and availability. You pay only for actual execution time, measured in milliseconds.
How It Works
In a serverless model (specifically Functions as a Service), you write a function that handles a single task: process a payment, resize an image, send an email. You deploy this function to a provider (AWS Lambda, Vercel Functions, Cloudflare Workers). When triggered, the platform spins up a container, executes your code, returns the result, and shuts down. If a thousand requests arrive simultaneously, a thousand containers run in parallel.
Cold starts occur when a function has not been called recently and needs a fresh container. This adds 100ms-2s of latency depending on the runtime. Subsequent invocations within the warm period execute instantly. Strategies like provisioned concurrency or lightweight runtimes (Cloudflare Workers use V8 isolates with sub-millisecond cold starts) mitigate this.
Why It Matters
Serverless eliminates infrastructure management entirely. No patching servers, no capacity planning, no paying for idle resources. A function that runs once per day costs fractions of a cent. This pricing model makes serverless ideal for unpredictable workloads because a viral event that triggers millions of executions costs proportionally, not catastrophically.
For startups, serverless means zero infrastructure investment at launch. Scale from zero to millions of requests without architecture changes.
In Practice
An image upload workflow: a user uploads a photo to S3, which triggers a Lambda function. The function generates three thumbnail sizes, runs EXIF data extraction, stores metadata in DynamoDB, and returns signed URLs. This handles zero to ten thousand uploads per minute without any server management.
Common Mistakes
Serverless is not ideal for long-running processes (most providers cap at 15 minutes), workloads requiring persistent connections (WebSockets need different approaches), or latency-sensitive applications where cold starts are unacceptable. Vendor lock-in is real, and migrating between cloud providers requires significant rewriting.