SkarpSkarp

Chapter 12 of 27

Serverless Containers and Functions: Deploying with Cloud Run and Cloud Functions

Offload infrastructure management with serverless platforms; practice deploying stateless services and event-driven functions the way the exam will test you.

27 min readen

Big Picture: Serverless on Google Cloud

From VMs to Serverless

You have seen Compute Engine and GKE. Serverless (Cloud Run, Cloud Functions) moves you up a level: no servers or clusters to manage, and you pay mainly for actual usage.

Serverless Characteristics

Serverless on Google Cloud means: no OS or patching, automatic autoscaling (including to zero), and pricing based on requests and resource time used, not idle capacity.

Four Compute Choices

Know the four compute choices: Compute Engine for VMs, Google Kubernetes Engine for Kubernetes clusters, Cloud Run for containerized services, Cloud Functions for single-purpose functions.

Exam Relevance

Cloud Run and Cloud Functions appear mainly in Deploying and implementing a cloud solution, but also in planning and operations questions. You must compare them confidently in scenarios.

Cloud Run Fundamentals: Services, Revisions, and Requests

What Cloud Run Is

Cloud Run runs containerized HTTP services on a fully managed platform. You deploy a container image; Cloud Run gives you an HTTPS URL and scales instances automatically.

Services and Revisions

A Cloud Run service is the main resource with a URL. Each deployment creates a new immutable revision with a specific container image and configuration like CPU, memory, and env vars.

Stateless Containers

Cloud Run workloads must be stateless. Container instances are ephemeral, and local filesystem or memory can be lost. Use managed storage (Cloud SQL, Firestore, Cloud Storage) for data.

Key Exam Traps

Common pitfalls: app not listening on the PORT env var, process exiting after startup, or relying on sticky in-memory state. Also remember Cloud Run (fully managed) vs Cloud Run for Anthos.

Hands-On Flow: Deploying to Cloud Run from Source and Registry

Two Deployment Flows

For the exam, know both Cloud Run flows: deploy directly from source (Cloud Build creates the image) and deploy from an existing container image in a registry.

Deploy From Source

Inside your service folder, run: `gcloud run deploy SERVICE --source . --region REGION --allow-unauthenticated`. This builds the image and creates a Cloud Run service and revision.

Deploy From Image

First build and push an image, then run: `gcloud run deploy SERVICE --image IMAGE_URL --region REGION --allow-unauthenticated`. This skips source build and uses the given image.

Exam Reminders

Remember which APIs to enable, the meaning of `--allow-unauthenticated`, and that `--source` implies Cloud Build. In the console, similar options appear under Cloud Run > Create service.

Traffic Splitting and Revisions in Cloud Run

Revisions and Immutability

Each Cloud Run deployment creates an immutable revision: a snapshot of image plus configuration. To change config, you create a new revision instead of editing an existing one.

Traffic Splitting Concept

A Cloud Run service can send different percentages of traffic to multiple revisions. This enables gradual rollouts and canary deployments without new load balancers.

CLI Example

Use `gcloud run services update-traffic SERVICE --to-revisions rev1=90,rev2=10 --region REGION` to route 90% to the old revision and 10% to the new revision.

Rollbacks and Tags

Rollback by changing traffic back to an older revision. Tags give per-revision URLs for testing, but the main URL follows your traffic split settings on the service.

Cloud Functions Fundamentals: Functions, Triggers, and Runtimes

What Cloud Functions Is

Cloud Functions runs single-purpose functions in response to events or HTTP requests. You deploy code and config, not a full container image or VM.

Triggers

Triggers define how a function is invoked: HTTP triggers expose an HTTPS endpoint, while event-driven triggers react to Cloud Storage, Pub/Sub, Firestore, and other service events.

Runtimes and Generations

Cloud Functions supports managed runtimes (Node.js, Python, Go, Java, .NET, Ruby, PHP). 2nd gen is built on Cloud Run/Eventarc and offers better scaling and triggers.

Cloud Run vs Cloud Functions

Use Cloud Functions for small, single-responsibility tasks tightly coupled to events. Use Cloud Run for full HTTP services or when you need custom runtimes and container-level control.

Deploying Cloud Functions: HTTP and Event Triggers

This step walks through two concrete Cloud Functions deployments with `gcloud`: one HTTP-triggered, one event-triggered via Pub/Sub.

Assume a Node.js function file `index.js` in directory `hello-fn/`:

```js

// index.js

exports.helloHttp = (req, res) => {

const name = req.query.name || 'World';

res.send(`Hello ${name} from Cloud Functions!`);

};

exports.helloPubSub = (event, context) => {

const message = Buffer.from(event.data, 'base64').toString();

console.log(`Received message: ${message}`);

};

```

And a `package.json` that declares dependencies.

1. Deploy an HTTP-triggered function (2nd gen)

```bash

cd hello-fn

Enable APIs if needed

gcloud services enable cloudfunctions.googleapis.com run.googleapis.com eventarc.googleapis.com

Deploy HTTP function

gcloud functions deploy helloHttp \

--gen2 \

--region=REGION \

--runtime=nodejs20 \

--entry-point=helloHttp \

--trigger-http \

--allow-unauthenticated

```

Key flags:

  • `--gen2`: Use 2nd gen (exam questions may specify this).
  • `--trigger-http`: Creates an HTTPS endpoint.
  • `--allow-unauthenticated`: Make it publicly callable.

2. Deploy an event-driven function triggered by Pub/Sub (2nd gen)

```bash

Create a Pub/Sub topic

gcloud pubsub topics create my-topic

Deploy the function with a Pub/Sub trigger

gcloud functions deploy helloPubSub \

--gen2 \

--region=REGION \

--runtime=nodejs20 \

--entry-point=helloPubSub \

--trigger-topic=my-topic

Test by publishing a message

gcloud pubsub topics publish my-topic --message="Exam prep!"

```

Exam angles:

  • Recognize `--trigger-http` vs `--trigger-topic` vs storage triggers like `--trigger-bucket`.
  • Understand that for event triggers, Cloud Functions integrates with Pub/Sub and other services via Eventarc under the hood.
  • Identify when `--allow-unauthenticated` is (or is not) appropriate based on security requirements.

Autoscaling and Configuration: Cloud Run vs Cloud Functions

Cloud Run Autoscaling

Cloud Run scales container instances based on concurrent HTTP requests. You control concurrency, max instances, min instances, and CPU allocation to balance cost and performance.

Cloud Functions Autoscaling

Cloud Functions scales for HTTP requests and event volume (e.g., Pub/Sub). In 2nd gen, you can set max and min instances, and it supports higher concurrency than 1st gen.

Cold Starts and Warm Instances

Both platforms can have cold start latency when scaling from zero. Setting min instances keeps some instances warm, improving latency but increasing cost.

Exam-Focused Use Cases

To protect a database, cap max instances or reduce concurrency. To reduce latency for infrequent calls, use min instances. For event bursts, know that Cloud Functions scales out to max-instances.

Thought Exercise: Choosing Cloud Run vs Cloud Functions

Work through these scenarios mentally. For each, decide whether Cloud Run or Cloud Functions is the better fit, and why. Then compare your reasoning to the guidance.

  1. Image processing API
  • You have a containerized image-processing service that exposes multiple endpoints (`/resize`, `/thumbnail`, `/filter`). It uses a custom C++ library.
  • Which compute option? Why?

Guidance: Cloud Run is a better fit because you already have a container and need a custom C++ library. Cloud Functions only supports managed runtimes and is aimed at single-purpose functions, not a multi-endpoint API.

  1. Audit log forwarding
  • You need to forward Cloud Audit Logs entries to an external SIEM whenever a new log entry matches certain filters.
  • Which compute option? Why?

Guidance: Cloud Functions (event-driven) is ideal. You can use a log sink to Pub/Sub and trigger a function on each message. The function is small, single-purpose, and tightly coupled to events.

  1. Public JSON API with canary rollouts
  • You are building a public JSON REST API and want to do 5% canary rollouts for new versions while keeping 95% on stable. You want simple traffic splitting with minimal infrastructure.
  • Which compute option? Why?

Guidance: Cloud Run is ideal because it supports explicit traffic splitting across revisions. You can send 5% of traffic to the new revision and 95% to the old one without extra load balancers.

  1. Scheduled daily job
  • A job runs once per day to clean up old data in Cloud Storage. It does not need a custom runtime.
  • Which compute option? Why?

Guidance: Cloud Functions triggered by Cloud Scheduler (via Pub/Sub or HTTP) is usually simpler and cheaper than running a container on Cloud Run for a tiny daily task.

Quick Check: Cloud Run and Cloud Functions Basics

Answer this question to reinforce key distinctions.

You have a stateless HTTP API already packaged as a Docker container. You want automatic HTTPS, request-based autoscaling, and the ability to send 10% of traffic to a new version while 90% stays on the old version. Which Google Cloud product and feature combination best fits?

  1. Cloud Functions with an HTTP trigger and Cloud Load Balancing
  2. Cloud Run with revisions and traffic splitting
  3. Compute Engine with a managed instance group and rolling updates
  4. Google Kubernetes Engine with a Deployment and Horizontal Pod Autoscaler
Show Answer

Answer: B) Cloud Run with revisions and traffic splitting

Cloud Run is designed for containerized HTTP services and supports revisions with configurable traffic splitting (e.g., 90/10). Cloud Functions does not use container images directly and does not offer revision-level traffic splitting. Compute Engine and GKE can do rollouts but require more infrastructure management and do not use Cloud Run's revision traffic split feature.

Quick Check: Cloud Functions Triggers and Autoscaling

Test your understanding of Cloud Functions triggers and scaling behavior.

A team deploys a Cloud Functions (2nd gen) function triggered by a Pub/Sub topic. Suddenly, a backlog of 100,000 messages appears on the topic. What BEST describes how Cloud Functions handles this by default, assuming no custom max-instances setting?

  1. It processes messages one at a time on a single instance to preserve ordering.
  2. It scales out multiple instances in parallel up to a platform-defined limit to drain the backlog faster.
  3. It rejects new messages when more than 1,000 are pending to avoid overload.
  4. It requires you to manually create more instances using the gcloud CLI.
Show Answer

Answer: B) It scales out multiple instances in parallel up to a platform-defined limit to drain the backlog faster.

Cloud Functions (especially 2nd gen) is designed to autoscale in response to event volume. For a large Pub/Sub backlog, it automatically creates multiple instances in parallel (up to a platform or configured max-instances limit) to process messages concurrently. You do not manually create instances.

Key Term Review: Cloud Run and Cloud Functions

Use these flashcards to reinforce essential terms and behaviors before moving to practice questions and labs.

Cloud Run service
The top-level Cloud Run resource that has a stable URL and routes incoming HTTP(S) requests to one or more immutable revisions according to configured traffic percentages.
Cloud Run revision
An immutable snapshot of a Cloud Run service's container image and configuration (CPU, memory, environment variables, concurrency, etc.) created on each deployment.
Traffic splitting (Cloud Run)
A feature that lets you route different percentages of a Cloud Run service's traffic to multiple revisions, enabling gradual rollouts and canary deployments without extra load balancers.
Cloud Functions trigger
The configuration that defines how a Cloud Function is invoked, such as an HTTP trigger (HTTPS endpoint) or an event-driven trigger from services like Pub/Sub, Cloud Storage, or Firestore.
Event-driven function
A Cloud Function that runs automatically in response to events from Google Cloud services (for example, a new object in Cloud Storage or a Pub/Sub message), rather than direct HTTP requests.
Autoscaling (Cloud Run)
Cloud Run's ability to automatically adjust the number of container instances based on concurrent HTTP request load, within optional min and max instance limits and concurrency settings.
Autoscaling (Cloud Functions)
Cloud Functions' behavior of automatically creating and removing function instances based on incoming HTTP requests or event volume, up to platform or configured max-instances limits.
Min instances
A configuration option on Cloud Run and Cloud Functions (2nd gen) that keeps a minimum number of instances warm to reduce cold-start latency, at the cost of some always-on resource usage.
Max instances
A configuration option that caps the number of instances Cloud Run or Cloud Functions can scale out to, used to control costs and protect downstream systems from overload.
Cloud Run vs Cloud Functions (core difference)
Cloud Run runs arbitrary containerized HTTP services and is ideal for full microservices and custom runtimes. Cloud Functions runs code in managed language runtimes and is ideal for small, single-purpose HTTP or event-driven functions.

Key Terms

Pub/Sub
A Google Cloud messaging service that enables asynchronous communication via topics and subscriptions, commonly used as an event source for Cloud Functions.
Revision
In Cloud Run, an immutable version of a service created on each deployment, storing the container image and configuration used to handle requests.
Cloud Run
A fully managed compute platform that automatically scales stateless containers in response to HTTP requests, providing HTTPS endpoints, revisions, and traffic splitting without requiring you to manage servers or clusters.
Autoscaling
The automatic adjustment of the number of running instances (Cloud Run containers or Cloud Function instances) based on request or event load, within defined configuration limits.
HTTP trigger
A Cloud Functions trigger type that exposes a function via an HTTPS endpoint, allowing invocation via HTTP requests.
Event trigger
A configuration that causes a Cloud Function to execute in response to specific events from Google Cloud services, such as Pub/Sub messages or Cloud Storage object changes.
Cloud Functions
A serverless compute service for running single-purpose functions triggered by HTTP requests or events from Google Cloud services, using managed language runtimes instead of custom containers.
Artifact Registry
Google Cloud's container and language package registry used to store and manage container images for deployment to services like Cloud Run and GKE.
Traffic splitting
A Cloud Run feature that routes configurable percentages of a service's traffic to different revisions, enabling canary and gradual rollouts.
Concurrency (Cloud Run)
The number of simultaneous HTTP requests that a single Cloud Run container instance can handle, affecting scaling behavior and resource utilization.

Finished reading?

Test your understanding with a custom practice exam on this chapter.

Test yourself