4.3 Serverless Computing

Serverless Computing Principles

Quick Answer: Serverless computing lets developers upload code and run it without managing, patching, or scaling servers. The provider handles infrastructure, bills per invocation or per 100ms of compute, and scales automatically—including to zero when there is no traffic.

Serverless rests on four principles:

1. No infrastructure to manage — The provider provisions, patches, and operates the runtime. There is no OS to harden, no Kubernetes cluster to tune, no VM to right-size.
2. Automatic scaling, including to zero — Instances appear to handle a single request and disappear when traffic stops. You pay nothing for idle capacity.
3. Pay-for-use billing — Charges accrue per request, per 100ms of CPU, and per GB-MB of memory used. There is no reserved-capacity charge and no minimum commitment.
4. Developer focus on code — Teams ship business logic, not YAML, runbooks, or capacity plans.

These principles produce a distinct cost and operations profile. Because billing is per invocation and per 100ms of compute, a service that receives a few requests per minute can cost pennies per month, while the same service implemented on an always-on VM would incur a fixed monthly charge whether or not it was used. The trade-off is cold-start latency: the first request after a scale-to-zero event may take longer while a new instance spins up. For latency-sensitive workloads, developers can configure a minimum number of warm instances—though that reintroduces some idle cost.

Benefits of Serverless in Application Modernization

• Faster time-to-market — Developers deploy functions or services in minutes, accelerating experiments and feature delivery.
• Lower operational cost — No on-call rotation for OS patching, capacity planning, or cluster upgrades.
• Automatic scaling — Sudden traffic spikes are absorbed without pre-provisioning; quiet periods cost nothing.
• No idle cost — Scale-to-zero eliminates the steady "warm capacity" bill that VMs and long-running containers incur.

Serverless in the Modernization Journey

Serverless is the destination for many refactored or reimaged applications. A monolith rehosted to Compute Engine can later be decomposed into microservices; the event-driven, stateless ones are natural candidates for Cloud Functions, while the request/response services fit Cloud Run. The progression—rehost → replatform → refactor → serverless—lets organizations capture quick savings first and incrementally unlock the velocity and cost benefits of serverless as teams mature and as domain boundaries become clear. Not every workload belongs on serverless: long-running stateful services, jobs that need persistent local storage, workloads with strict latency guarantees, and processes that run for hours on a single invocation often stay on VMs or containers. The exam expects you to identify which workloads are good serverless fits, not to claim serverless is universal.

When Serverless Is—and Isn't—the Right Choice

Serverless shines for stateless, event-driven, and short-lived workloads: HTTP APIs, webhooks, scheduled jobs, stream processing glue, image-thumbnail pipelines, and microservices that scale with demand. It struggles for stateful, long-running, or tightly coupled workloads: databases (use managed databases like Cloud SQL or Spanner instead), in-memory caches, jobs that run for hours on a single invocation, and systems that need fine-grained control over the network stack. The decision rule is: if your workload is stateless, event-driven, and short-lived, serverless is almost always the right answer; if it is stateful, long-lived, or needs deep OS control, VMs or containers are the better fit.

Serverless Cost Model in Practice

A useful mental model: serverless turns fixed cost into variable cost. An always-on VM has a predictable monthly bill regardless of traffic; a serverless function has a bill that scales linearly with usage. For spiky or unpredictable traffic, serverless wins; for steady, high-volume traffic, the per-invocation cost can exceed the equivalent VM cost, and a long-running container on Cloud Run with a minimum instance count—or a VM with autoscaling—may be cheaper. Organizations should model both paths before committing a high-traffic service to serverless.

Google Cloud Serverless Products

All three are fully managed and integrate with Google Cloud's observability suite—Cloud Monitoring, Cloud Logging, and Cloud Trace—so you get visibility into requests, latencies, and errors without operating your own monitoring stack.

Use-Case to Product Decision Guide

• "I have a container image and want it to scale to zero." → Cloud Run.
• "I have a web/mobile app and want a fully managed platform with versioning and traffic splitting." → App Engine.
• "I want a small function to fire when a file lands in Cloud Storage." → Cloud Functions.
• "I need to glue Pub/Sub messages into a BigQuery insert." → Cloud Functions.
• "I want a long-running HTTP API in a custom runtime with custom libraries." → Cloud Run.
• "I want a request/response service but my team only writes Python and wants zero container ops." → App Engine standard or Cloud Run (if containerized).

Exam trap: Cloud Run and Cloud Functions both scale to zero, but they are not interchangeable. Cloud Run runs any container (any language, any library) and is request/response oriented, while Cloud Functions is event-driven and limited to supported runtimes. For a stateless HTTP service packaged as a container, Cloud Run is the better fit; for a small piece of code triggered by a storage event, Cloud Functions is the natural choice.

Naming change for the updated exam. Cloud Functions has been folded into Cloud Run and is now called Cloud Run functions. The exam guide effective August 12, 2026 lists the serverless products as "Cloud Run; Cloud Run functions" and drops App Engine entirely. If you are sitting the updated exam, expect the function-style option to be labelled Cloud Run functions, and do not expect App Engine to be a correct answer. If you are sitting the current exam through August 11, App Engine and Cloud Functions are still both in scope - which is why this guide teaches all three.