A sprinkler that runs all day wastes water and money. Drip irrigation is smarter: a sensor notices a plant is dry, the water switches on for that plant, and then it stops. Serverless computing works the same way. Your code sits dormant, an event wakes it (a file arrives, a request comes in), it runs for a few seconds to do one job, and then it goes back to sleep. You pay only for the seconds it ran.
You still have servers
The name is misleading. Serverless does not mean there are no servers. It means you never see or manage them. The provider keeps a fleet of machines ready, runs your function on one of them when it is needed, and takes it away afterward. Provisioning, scaling, patching, and capacity planning become the provider’s job, not yours. What you give up is some control and predictability (for example, a cold start when a function has not run recently); what you gain is that you only think about your code.
When serverless fits
Serverless shines for event-driven work: glue between services, light processing, APIs with uneven traffic, and tasks that are bursty or unpredictable. It fits less well for steady, heavy, long-running workloads where a continuously running server is cheaper, or where you need tight control over latency. As with the cloud itself, the point is to match the tool to the shape of the work.
Further reading
- Serverless the glossary definition, with more depth.
- AWS Lambda for AI pipelines the most widely used serverless compute service, in practice.
- What is the cloud? the previous lesson, if you skipped it.
Sources
- AWS. “What is serverless computing?” https://aws.amazon.com/serverless/
- AWS. “AWS Lambda Developer Guide.” https://docs.aws.amazon.com/lambda/latest/dg/welcome.html