1.2 Cloud Run Execution and Platform Selection

Compute Platform Selection: Cloud Run, GKE, and Compute Engine

Designing cloud-native applications on Google Cloud begins with selecting the compute platform that matches your workload's operational profile, scaling requirements, hardware dependencies, and execution model. The Google Cloud Professional Cloud Developer exam tests your ability to evaluate trade-offs between fully managed serverless containers (Cloud Run), enterprise container orchestration (Google Kubernetes Engine / GKE), and Infrastructure as a Service (Compute Engine).

Cloud Run: Fully Managed Serverless Containers

Cloud Run executes containers without requiring cluster management, VM provisioning, or node OS patching. Its container contract and Knative-style configuration support portable application packaging, but networking, identity, triggers, and managed-service integrations still require migration work.

Core Capabilities and Runtime Semantics

• Scale-to-Zero and Instant Elasticity: When no traffic arrives, Cloud Run scales active container instances to zero, avoiding instance compute charges when scaled to zero; other services, storage, and networking can still incur charges. When an HTTP request, gRPC call, or Eventarc event arrives, Cloud Run provisions container instances in milliseconds to seconds.
• Container Port Contract: The containerized application must listen for incoming HTTP/1.1, HTTP/2, or gRPC requests on the port specified by the PORT environment variable (default 8080), binding to 0.0.0.0.
• Stateless Execution: Container file systems are ephemeral and memory-backed (written to RAM). Persistent data must be committed to external storage systems such as Cloud Storage, Cloud SQL, Firestore, or Cloud Spanner.
• Request Timeout: Individual request execution is bounded by a configurable timeout (default 5 minutes, configurable up to 60 minutes for HTTP services, and up to 168 hours per non-GPU Cloud Run job task attempt; GPU tasks have a 1-hour maximum).

Concurrency and Scaling Triggers

Unlike traditional Functions-as-a-Service (FaaS) platforms where each instance handles only one request at a time, Cloud Run supports multi-concurrency:

• Container Concurrency (--concurrency): Defines the maximum number of simultaneous requests a single container instance can receive (maximum 1000; console-created services default to 80, while new CLI/Terraform services default to 80 times vCPU count).
• Multi-threaded vs. Single-threaded Runtimes: For multi-threaded runtimes (Go, Java, .NET, Rust), high concurrency (e.g., 80 to 250) optimizes resource utilization and lowers cost. For CPU-heavy single-threaded handlers, lower concurrency can reduce contention. I/O-bound Node.js handlers can efficiently overlap requests. Load-test the actual framework and worker count instead of assigning concurrency solely from language choice.

## Deploying a high-concurrency microservice to Cloud Run
gcloud run deploy order-service \
    --image=us-central1-docker.pkg.dev/my-project/apps/order-service:v1.2 \
    --concurrency=80 \
    --min-instances=2 \
    --max-instances=100 \
    --cpu=2 \
    --memory=2Gi \
    --no-cpu-throttling \
    --region=us-central1

CPU Allocation Models

Cloud Run offers two distinct CPU allocation models that dictate pricing and execution guarantees:

Exam Trap: If a developer launches a background goroutine or thread to flush logs, send telemetry, or execute asynchronous cleanup after returning the HTTP response, request-based CPU allocation will throttle the CPU almost immediately. The thread will freeze until a subsequent request wakes the instance, leading to dropped telemetry or delayed processing. To execute background threads safely between requests, specify --no-cpu-throttling.

Cold Starts and Mitigation Strategies

A cold start occurs when Cloud Run provisions a new container instance from scratch to handle incoming traffic. Cold start latency comprises container image pull time, container start, and runtime/application initialization.

• Minimum Instances (--min-instances): Keeps a predetermined number of container instances initialized, warm, and ready to serve traffic immediately, reducing cold starts for baseline traffic; replacements and traffic growth can still require new instances.
• Startup CPU Boost (--cpu-boost): Temporarily allocates extra vCPUs during container initialization (startup probe and app boot) to reduce initialization latency; the improvement depends on the workload before scaling down to configured steady-state CPU limits.
• Image Size Optimization: Use minimal base images (Distroless, Alpine) stored in Artifact Registry near the workload to reduce transfer overhead; measure application initialization rather than assuming image size determines startup latency.

Official references checked October 18, 2026: Google Cloud 1, Google Cloud 2.