Cloud Run for Serverless Containers

Cloud Run is a managed compute platform that runs stateless containers in a serverless environment. It abstracts away infrastructure management, allowing developers to deploy containerized applications without provisioning clusters, nodes, or virtual machines. The key innovation is that it combines the portability of containers with the operational simplicity of serverless functions (like Cloud Functions). You can bring your own container image (from Artifact Registry or Container Registry) and Cloud Run handles scaling, load balancing, and availability automatically.

Cloud Run exists to solve several pain points: - Operational overhead: Traditional container orchestration (Kubernetes) requires managing clusters, node pools, and scaling policies. - Cost inefficiency: Always-on servers incur costs even when idle. - Scaling complexity: Manually configuring autoscaling for variable traffic is error-prone. - Cold start latency: Functions have cold starts, but containers can be optimized for faster startup.

Cloud Run runs on top of Google Kubernetes Engine (GKE) and uses the Knative serving layer. When you deploy a container image, Cloud Run: 1. Stores the image in Artifact Registry. 2. Creates a revision (immutable snapshot of the deployment configuration). 3. Routes traffic to the revision via a managed HTTPS endpoint. 4. Instantiates container instances on demand, each in its own isolated sandbox (gVisor).

Request Flow:

Deploy a service:

gcloud run deploy myservice \
  --image us-docker.pkg.dev/myproject/myrepo/myimage:tag \
  --region us-central1 \
  --memory 512Mi \
  --concurrency 80 \
  --timeout 300 \
  --max-instances 50 \
  --min-instances 2 \
  --no-allow-unauthenticated

List services:

gcloud run services list --region us-central1

Describe a service (show revisions, traffic split, etc.):

gcloud run services describe myservice --region us-central1

View logs:

gcloud logging read "resource.type=cloud_run_revision AND resource.labels.service_name=myservice" --limit 10

Update traffic split (e.g., 50% to revision1, 50% to revision2):

gcloud run services update-traffic myservice --to-revisions=revision1=50,revision2=50 --region us-central1

Cloud Run scales based on the number of concurrent requests. Each instance can handle up to concurrency requests simultaneously. When the average number of concurrent requests per instance exceeds a threshold (default 0.7 * concurrency), Cloud Run starts new instances. Scaling is fast (seconds) but cold starts add latency. To reduce cold starts, set min instances >0, use the second generation execution environment (faster startup), or keep container images small (under 1 GB).

By default, Cloud Run services are private (only accessible by authorized accounts). To allow unauthenticated access, use --allow-unauthenticated or configure IAM policies. Cloud Run integrates with IAM for access control. Service accounts can be attached to revisions to grant permissions to other Google Cloud services.

Cloud Run charges based on: - CPU allocation: per vCPU-second (while handling requests, or always-on if configured). - Memory allocation: per GiB-second. - Requests: per million requests. - Networking: egress traffic is charged at standard rates. - No charge for idle instances (when min instances = 0).

For the GCDL exam, focus on:

A large online retailer uses Cloud Run to host its product catalog API. The API is containerized with Node.js and connects to Cloud SQL (PostgreSQL) for product data. The service experiences highly variable traffic: low during early morning, spikes during flash sales. They deploy with --min-instances 10 to keep a baseline warm, --max-instances 200 to handle spikes, and --concurrency 80 to maximize throughput. They use a VPC connector to access Cloud SQL privately. During a flash sale, they see cold starts for new instances, but most requests are handled by warm instances. They monitor with Cloud Monitoring and set alerts for request latency >500ms. A common misconfiguration is setting --min-instances too high, leading to unnecessary costs during low traffic. They also enable CPU always on for background cache warming.

A media company uses Cloud Run to run a containerized video transcoding service. They receive video files via Cloud Storage, which triggers a Cloud Function that publishes a message to Pub/Sub. A Cloud Run service subscribes to the Pub/Sub topic and processes each video. Each transcoding job takes 10-30 minutes, so they set request timeout to 60 minutes (max). They use the second generation execution environment for better CPU performance and larger memory (up to 16 GiB). They set --concurrency 1 because each instance handles one video at a time. They use Cloud Run's CPU always on to allow background processing. A pitfall is that if the request timeout is exceeded, Cloud Run terminates the request, causing partial processing. They implement checkpointing to Cloud Storage every few minutes. They also set --max-instances to control costs and avoid overwhelming downstream services.

A financial services company runs a Grafana dashboard on Cloud Run for internal use. The dashboard is lightweight and accessed by about 50 employees during business hours. They set --min-instances 0 to save costs overnight. They use IAM with --no-allow-unauthenticated and grant access via Google Groups. They use Cloud Run's managed SSL certificate for HTTPS. They notice that the first request in the morning has a cold start of about 5 seconds, which is acceptable. They set idle timeout to 10 minutes to avoid frequent cold starts if someone is actively using the dashboard. A common mistake is not setting a VPC connector to access internal databases, causing connection failures. They also use Cloud CDN behind a load balancer to cache static assets.