Unit 4.3 study guide — Serverless computing
Cloud Digital Leader › Unit 4 › Topic 3
Serverless computing
Study guide for Cloud Digital Leader, Unit 4 · Topic 3. This is the topic's lecture in reading form — every slide's teaching, figures and worked examples, in order — followed by the official Google Cloud pages its claims rest on.
What the exam guide asks. Discuss the advantages of serverless computing in application modernization.
Objectives, quoted from the exam guide:
- Explain the benefits of serverless computing.
- Discuss the business value of using serverless computing Google Cloud products, including: Cloud Run; App Engine; Cloud Functions.
Serverless computing
What you stop managing, what you stop paying for, and what it costs you
The benefit — the provider provisions, manages and scales; you pay for use, not for idle capacity. The price — cold starts, execution limits, portability. The products — Cloud Run services, jobs and functions, and App Engine, and which business case each one answers.
Topic two defined serverless in a sentence and placed Cloud Run among the compute options. This topic asks why a business would choose it, and which serverless product it would choose — two objectives, and the guide's summary is to discuss the advantages of serverless computing in application modernization. The deck takes them in three steps. First, what serverless actually changes: under a serverless model, developers build and run applications without having to manage any servers, and pay only for the exact amount of resources used. Second, the other side of the ledger, because Google publishes one — serverless is not suitable for every workload, and knowing where it fails is part of knowing its value. Third, the products: Cloud Run in its three forms, and App Engine, the older platform Google now points new customers away from.
The benefits of serverless computing
The provider takes the servers; you keep the code
- Productivity: developers write code, not infrastructure plans
- Scaling: instant, and down to zero — no rules to fine-tune
- Pricing: charged for actual use; nothing for idle capacity
- Delivery: less infrastructure friction in testing and deployment
- Language: any language or framework the team already knows
Worked example (synthetic). A regional retailer's two developers run a promotions service. On virtual machines they tune scaling rules before every campaign; on a serverless platform the campaign's traffic scales the service for them, and the quiet weeks cost nothing.
The first objective is the benefits, and every one of them follows from one change of responsibility. Google puts it plainly: the cloud service provider is responsible for provisioning, managing and scaling the cloud infrastructure that runs the application code. Notice what that sentence does not say. Serverless computing, despite its name, does not eliminate servers — it moves them out of your job description. Five benefits follow. Productivity: developers focus on writing code and optimizing business logic instead of worrying about provisioning, managing or scaling infrastructure. Scaling: unlike autoscaling in other types of cloud computing, which requires fine-tuning rules, serverless autoscaling is instant and can scale down to zero. Pricing: serverless is often charged on actual usage and execution time, and you do not pay for idle capacity. Delivery: it reduces the friction of infrastructure definition for development and operations teams across integration, testing, delivery and deployment. And language: serverless environments support any language or framework, so a team keeps the skills it has. The exam will offer these benefits as answers; the mechanism under each is what separates the right one from a plausible one.
Serverless against IaaS and PaaS
Both are on demand; only one stops when nothing is happening
| Question | Infrastructure or platform as a service | Serverless |
|---|---|---|
| What is running when nobody uses the app? | The infrastructure allocated to you remains active | Nothing — scaling goes down to zero |
| Who scales capacity to demand? | You — or rules you configure | The provider, instantly and automatically |
| What starts the work? | A server that is already running | An event that triggers your code |
| What is billed? | The capacity you were allocated | Actual use — not idle capacity |
Worked example (synthetic). A candidate says a virtual machine is "on demand, so it's the same as serverless". The table's first row is the correction: the machine stays allocated between requests; the serverless service does not.
Candidates often reason that every cloud model is on demand, so serverless is just a name. Google anticipates exactly that objection and answers it. Infrastructure as a service and platform as a service do provide on-demand access to computing resources — however, the cloud infrastructure allocated to you remains active even if you are not using it, and it is your responsibility to scale server capacity, or configure your applications to scale up or down, in response to user demand. Serverless differs in both respects. Serverless architectures are event-driven: the provider only gives you resources when an event triggers your code to run, and scales instantly and automatically to requests. So the table reads down each row: what runs when nobody is using the application, who scales it, what starts the work, and what is billed. The last row is why the idle-capacity benefit is real rather than a slogan — serverless is charged on use, and allocated-but-idle capacity is exactly what it does not charge for.
The other side of the ledger
Google publishes the limits too — and they are exam material
Figure. Four cards naming the limits Google lists for serverless computing: some workloads, such as long-running processes and very low latency needs, do not fit; cold starts delay first execution and there are execution time and memory limits; moving between providers is complex; and there is less visibility into the underlying infrastructure.
Worked example (synthetic). A trading desk wants every order priced in under a millisecond and a risk model that runs for six hours. Both requirements are on Google's list of poor fits for serverless.
A benefits objective invites a one-sided answer, and the exam rewards the candidate who knows the limits as well. Google lists them on the same page as the benefits. First, suitability: serverless architectures are not always suitable for applications with specific requirements, such as long-running processes or very low latency needs. Second, performance: serverless functions may experience cold starts — a delayed initial execution — and may have limits on execution time and memory. Third, portability: migrating serverless applications between cloud providers can be complex, because of differences in application programming interfaces and configurations. Fourth, visibility: developers see less of the underlying infrastructure, which makes it harder to troubleshoot performance issues or optimize resource use. None of these cancels the benefits. They define where the benefits apply — which is the judgement a business is actually making when it chooses serverless for one workload and not another.
Scale to zero, and what the first request pays
The saving and the cold start are the same mechanism
Figure: A cycle: requests are served by instances; when there are no incoming requests the last instance is removed and the service scales to zero; a new request causes a new instance to be created, and that first response is slower; then requests are served again. A dotted option, keeping a minimum number of instances, prevents the scale to zero.
Worked example (synthetic). An internal expenses tool is used for ten minutes each morning. Scale to zero means it costs nothing overnight; the first person in each morning waits slightly longer — a trade the finance team accepts.
Drawn as a cycle, the first objective's biggest benefit and its best-known cost turn out to be one mechanism. Cloud Run describes it exactly. If there are no incoming requests to your service, even the last remaining instance is removed — that is scale to zero, and it is why, if you do not configure minimum instances, you are not charged when your service is not used. Then a new request arrives for a service with no active instances, and Cloud Run creates a new instance; Google says this can increase the response time for those initial requests, depending on how quickly your container becomes ready. That delay is what the limits slide called a cold start. And the dotted line is the business's choice: you can configure Cloud Run to keep a minimum number of instances active, so the service does not scale to zero. That buys a faster first response at the price of the idle-capacity saving. The exam question is rarely which is better; it is which one this business should choose.
Google Cloud's serverless products
One platform in three shapes, and the platform it replaced
- Cloud Run service: code that answers requests or events at a stable endpoint
- Cloud Run job: work that runs to completion, on demand or on a schedule
- Cloud Run functions: the guide's "Cloud Functions", now part of Cloud Run
- App Engine: serverless web hosting — Google now recommends Cloud Run instead
Worked example (synthetic). A logistics firm's tracking API is a Cloud Run service, its nightly invoice run is a Cloud Run job, and the code that stamps each uploaded delivery photo is a function. One platform, three shapes of work.
The second objective names three products, and two of them need a sentence of context before their business value makes sense. Cloud Run, in Google's words, is a fully managed application platform for running your code, function or container on top of Google's highly scalable infrastructure, and it lets developers spend their time writing code and very little time operating, configuring and scaling. It is not tied to a list of languages either: you can deploy code written in any programming language on Cloud Run if you can build a container image from it. It runs work in different shapes: a service responds to requests at a unique and stable endpoint and also responds to events and functions; a job executes tasks manually or on a schedule and runs to completion. The guide's third product, Cloud Functions, is now part of Cloud Run. Google's comparison page gives Cloud Functions as the former product name, and describes Cloud Run functions as the latest version of functions, deployed as a service on Cloud Run. The original version survives as Cloud Run functions (1st gen), formerly Cloud Functions (1st gen), which Google describes as having limited event triggers, runtimes and configurability. So when the exam says Cloud Functions, read Cloud Run functions. App Engine is the older platform: one of the fully managed, serverless platforms for developing and hosting web applications at scale. Its own overview now says a newer and better alternative to App Engine is Cloud Run, and recommends Cloud Run to new Google Cloud users. That recommendation is part of App Engine's business story — its value today is mostly to the applications already running on it.
Which serverless product for which business case
Read the shape of the work, then the product
| Shape of the work | Product | Business value Google states |
|---|---|---|
| An API, website or microservice answering requests | Cloud Run service | REST or GraphQL APIs and private microservices, with little time spent operating them |
| A task that runs, finishes and stops | Cloud Run job | Runs to completion; array jobs split work into independent tasks, faster |
| A small piece of code reacting to an event | Cloud Run functions | Responds to a Pub/Sub message, a Cloud Storage change or a Firebase event |
| An existing web app already on App Engine | App Engine | Fully managed hosting that scales on demand — new work goes to Cloud Run |
Worked example (synthetic). An item describes a nightly job that resizes thousands of images and then stops. A service would wait for requests it never gets; the job runs, splits the work, and ends.
Exam items on this objective describe the work, not the product, so this table reads left to right. Work that answers requests — an application programming interface, a website, a set of microservices — is a Cloud Run service; Google's examples are a REST or GraphQL API and private microservices communicating over HTTP or gRPC. Work that starts, finishes and stops is a Cloud Run job, which runs to completion; when the work divides, array jobs are a faster way to process jobs that can be split into multiple independent tasks. A small piece of code that reacts to something happening is a function: Cloud Run functions can respond to asynchronous events such as a message on a Pub/Sub topic, a change in a Cloud Storage bucket, or a Firebase event. And App Engine's row is honest about its position — fully managed hosting that provisions servers and scales app instances based on demand, for applications that are already there, while Google steers new work to Cloud Run.
A function, triggered by an event
Nothing runs until something happens
Figure: A customer uploads a photo, which changes a Cloud Storage bucket. That change is an event that triggers a Cloud Run function deployed from source code, which saves a resized image back. A dotted branch notes that when there are no uploads, nothing is running.
Worked example (synthetic). A marketplace's sellers upload listing photos at unpredictable times. The resizing function runs once per upload and not at all in between — the business pays for photos processed, not for a server waiting.
This is the business case functions exist for, drawn out. A customer uploads a photo; the Cloud Storage bucket changes; that change is an event, and the event triggers a function. Google describes a function as a Cloud Run service that is deployed from source code, and lists a change in a Cloud Storage bucket among the asynchronous events functions can respond to. The function resizes the image and saves it back. The dotted branch is the business value: when there are no uploads, nothing is running, because serverless gives resources only when an event triggers the code. Google's eventing service, Eventarc, generalizes the pattern — it lets you build event-driven architectures without having to implement, customize or maintain the underlying infrastructure. For the exam, the signal is an event in the scenario: an upload, a message, a change. Where there is an event and a small piece of code, the answer is a function.
App Engine's two environments, and where Cloud Run sits
Standard scales to zero; flexible keeps a VM running
Figure. A comparison of App Engine's two environments. Standard runs in a sandbox on a supported language runtime, scales to zero, suits sudden extreme traffic spikes and can run free or at very low cost. Flexible runs Docker containers on Compute Engine virtual machines, keeps a minimum of one instance, and suits consistent traffic with gradual scaling. A note below says Google recommends Cloud Run for new applications.
Worked example (synthetic). A ticket site's App Engine app sits idle for weeks and then takes a flood of traffic when sales open. The standard environment fits both halves — it scales to zero, and it is built for sudden spikes.
App Engine comes in two environments, and the exam can ask which one a business case calls for. In the standard environment, application instances run in a sandbox, using the runtime environment of a supported language; it is intended to run for free or at very low cost, where you pay only for what you need, and your application can scale to zero instances when there is no traffic. Google says it suits applications that experience sudden and extreme spikes of traffic requiring immediate scaling. In the flexible environment, application instances run within Docker containers on Compute Engine virtual machines. It suits applications that receive consistent traffic or scale up and down gradually — and it does not scale to zero: Google's comparison lists a minimum of one instance. So of the two, only standard is serverless in the full sense this topic has used. The note beneath the table is the current context: Cloud Run is the latest evolution of Google Cloud serverless, building on more than a decade of running App Engine, and it can handle the same workloads as App Engine with much more flexibility. That is why Google recommends it for new work.
What this topic actually tests
Three discriminations, two objectives
On demand or event-driven? Only serverless stops when nothing happens. Saving or first-request delay? Scale to zero gives both; minimum instances trade one for the other. Which shape of work? Requests → service; run-and-stop → job; an event → function; an existing web app → App Engine, new ones → Cloud Run.
Close on the three discriminations this topic tests. First, on demand against event-driven: every cloud model is on demand, but under infrastructure or platform as a service the allocated capacity stays active, while serverless gives resources only when an event triggers the code and scales down to zero. Second, the saving against the delay: scale to zero is why an unused service costs nothing and also why the first request after a quiet spell is slower, and keeping minimum instances trades the saving for speed. Know the limits Google publishes — long-running processes, very low latency needs, cold starts, portability. Third, the shape of the work: requests go to a Cloud Run service, work that runs and stops to a job, a small piece of code reacting to an event to a function — which is what the guide still calls Cloud Functions — and an existing web application may stay on App Engine, while Google recommends Cloud Run for anything new. Topic four takes the container underneath all of this and asks what a container itself is worth.