The case
Two peak days, eleven months of idleness. The Father's Day server sat idle for the rest of the year.
A craft brewery run by a friend of Isaac sells almost everything through its site. During the year, there are only a few orders a day. In Father's Day week, the traffic goes to dozens of times the normal level, and the site goes down on the first night.
To avoid that, the brewery rented a large server. It costs all year round, and most of the time it serves no one.
This post builds on Cloud Service Models: IaaS, PaaS, SaaS and FaaS, Containers in the Cloud and Compute Engine: virtual machines on Google Cloud. There, the server was still yours to manage. Here, the question is who needs to be running when nobody is using the site.
The problem
Paying for peak capacity all year long
With a virtual machine, capacity is bought by the hour, whether it is on or not. To survive the peak, the brewery needs a server that can handle Father's Day week. The rest of the year, that server waits for traffic that never arrives.
- If the server is small, the site goes down at the peak, exactly when the most is being sold.
- If the server is large, the bill stays high most of the time.
- If someone has to adjust the capacity for each campaign, the work falls to the team.
The solution
Serverless: pay for what runs
Serverless does not mean there are no servers. It means you don't manage the servers, and the provider creates and ends instances according to demand. A possible comparison: it's like renting a coworking room by the hour. You don't own the building, you don't do maintenance, and you pay for the time the room is yours.
Two behaviors define the model:
- Scale to zero: without requests for a while, the service has no instances.
- Pay per use: the cost follows what was processed, not the capacity turned on.
Three paths
Cloud Run, App Engine and Cloud Run functions
Cloud Run
Runs any container that answers HTTP requests, in any language.
At the brewery: the whole site packaged in a container, which starts when someone visits.
App Engine
A platform for web applications, with versions and traffic splitting between them. The standard version scales to zero; the flexible one does not.
At the brewery: the old version of the site stays up while the new one receives 10% of the visits.
Cloud Run functions
A function that runs when an event happens, such as a new file or a message.
At the brewery: the function that sends the confirmation email when an order is paid.
Don't mix them up
Cloud Run × Cloud Run functions
Cloud Run
“A whole application, or a function?”
- Example
- The brewery's site, with catalog, cart and admin panel, in a single container.
- Focus
- Any container that answers HTTP requests. You choose the language and the libraries.
Cloud Run functions
“Which event triggers the code?”
- Example
- A paid order: the function runs, sends the email and ends.
- Focus
- A small function, triggered by an event. You write only the function's code.
Underneath
Request, instance and billing
When the first request arrives, Cloud Run creates an instance of the container. One instance can serve several requests at the same time, and when traffic rises, the service creates more instances. When the traffic stops, idle instances are shut down after a while.
By default, Cloud Run charges only while it processes requests. This model has a cost: when the service was at zero instances, the first request may take longer, because an instance has to be created. This delay is called a cold start, and it is the price of scaling to zero.
In practice
Which path for each part of the brewery
| Part of the system | Service | Why |
|---|---|---|
| Sales site, with campaign peaks | Cloud Run | HTTP container that scales with the traffic |
| Function that sends the paid-order email | Cloud Run functions | Runs when the event happens, then ends |
| Internal panel with few visits per day | App Engine (standard) | Simple platform that scales to zero |
| Orders database | Cloud SQL | Not serverless: needs data always available |
Key terms
Five terms to remember
Tap a card to see the definition.
Quick test
Three questions, exam style
01
An order API receives heavy traffic for one hour a day and almost none at night. Which serverless characteristic helps the most?
02
A team wants to put online an application in a container, in any language, that answers HTTP requests. Which service fits best?
03
Which statement about serverless is false?
The brewery did not need a server for Father's Day. It needed a site that exists when someone visits and disappears when nobody does. That's the point of serverless, and the next step of the track is Kubernetes and GKE, for when the container needs more control over the infrastructure.