Serverless computing
Also known as: serverless, functions as a service, serverless functions
Serverless computing is a cloud model where developers write code that runs only when triggered, such as by a web request, file upload, or schedule, while the cloud provider handles all servers, scaling, and maintenance.
Examples include AWS Lambda, Azure Functions, Google Cloud Run functions, and Cloudflare Workers. You typically pay only for the time code runs. While serverless can be cheap and effortless at small scale, costs and complexity can grow for steady, heavy workloads, and there are still servers, just not yours to manage.
Serverless computing, explained at three levels
At home
Serverless is like using a taxi instead of owning a car. You pay only for each ride, and someone else handles maintenance and parking.
At work
Serverless lets small teams run applications without managing servers, paying only when code actually runs.
At home
Many website contact forms and image resizing features run on serverless functions that wake up when someone uses them.
At work
Serverless functions scale automatically but have limits on run time and memory, and may experience 'cold starts,' brief delays when a function hasn't run recently.
At home
Free tiers make serverless great for hobby projects. In my opinion, set billing alerts anyway, since a bug or attack can trigger many costly runs.
At work
Apply least-privilege permissions per function, monitor costs and invocations, manage secrets properly, watch for vendor lock-in, and compare costs with containers for steady workloads.
Real-world examples
At home
Thomas built a hobby site that emails him when someone fills in a form. A serverless function handles it, and it's cost him nothing so far.
At work
Aisha runs engineering at a Vancouver photo app startup. Serverless functions resize uploaded images, scaling automatically when users upload thousands at once.
How it compares
| feature | Serverless computing | Virtual Machine |
|---|---|---|
| Server management | Handled by provider | Your responsibility |
| Billing | Per use | Per hour running |
| Scaling | Automatic | Manual or configured |
| Best for | Spiky, event-driven work | Steady, long-running work |
Serverless trades control for convenience and pay-per-use pricing.
For analysts
When evaluating serverless, I'd model costs at expected and peak usage. It can be dramatically cheaper or more expensive depending on traffic patterns.
History & origin
Platforms such as Google App Engine in 2008 and Heroku offered early steps toward managed hosting. Amazon launched AWS Lambda at its re:Invent conference in November 2014, popularizing 'functions as a service.' Microsoft's Azure Functions and Google Cloud Functions followed in 2016, and Cloudflare Workers in 2017 ran code across a global network close to users. Serverless expanded to databases and containers through services such as AWS Fargate and Google Cloud Run. Some companies, including Amazon's Prime Video team in a widely discussed 2023 post, found traditional designs cheaper for certain workloads. In my view, serverless is excellent for spiky, event-driven work and a poor fit for constant heavy processing.