Serverless
Home cooks upload photos of their dishes to DabbaGo, and each photo must be resized into three sizes. Uploads come in bursts: dozens at 8 pm when cooks plan tomorrow's menu, almost none at 3 am. Keeping a server running all night to wait for photos wastes money, but a server too small for the 8 pm rush makes cooks wait. Serverless was made for work shaped like this.
The rule
Hand the servers to the provider; pay only when your code runs.
In a serverless style you still have servers, but you never manage them. You give the cloud provider small pieces of code, called functions, and say what should trigger them: an uploaded file, an HTTP request, a message on a queue, a timer. The provider:
- starts the function when a trigger fires,
- runs as many copies as needed when triggers pile up,
- scales down to zero when nothing is happening,
- bills you for the time your code actually runs.
Serverless also includes managed services you use without running them yourself, such as hosted databases, queues and file storage.
# a sketch of a function's settings
function: resize-dish-photo
trigger: file uploaded to bucket "dish-photos"
memory: 512 MB
timeout: 30 secondsThe trade-offs:
- Cold starts. A function that has not run recently needs a moment to start, adding delay to the first request.
- Limits. Functions have time and memory limits and keep no memory between runs, so state must live in a database or storage.
- Cost at steady load. Paying per run is cheap for bursty or rare work, but for heavy, constant traffic a server that is always on can cost less.
- Lock-in. Triggers, permissions and managed services are provider-specific, so moving to another cloud takes real work.
- Harder debugging. A request may pass through several functions and managed services that you cannot log into.
The shortcut
Score the job on four questions: Is it triggered by events? Is the load bursty or rare? Is each run short? Is it stateless? Four yeses make serverless an easy win. Each no is a cost you should weigh.
Photo resizing
Triggered by an upload: yes. Bursty: yes, 8 pm rush, quiet nights. Short: a few seconds. Stateless: yes, reads a file and writes three. Four yeses: serverless.
The trap is choosing a style for the whole company. DabbaGo, like most real systems, will mix styles: a modular core, a few services, and serverless functions around the edges.
Drills
Answer fast — trust the rule.
What does "scale to zero" mean for a serverless function?
Which DabbaGo job is the best fit for serverless?
The first photo resize after a quiet night takes two extra seconds; later ones are fast. What is the likely cause?
A function must remember a cook's upload count between runs. Where should that count live?
Remember
- Serverless hands servers to the provider; you pay only when your code runs.
- Shortcut: events, bursty, short, stateless. Four yeses make an easy win.
- Trap: forcing one style on everything instead of mixing styles by job.