4.3 Serverless Architectures: Cloud Run, Cloud Functions & Eventarc

Serverless Architectures: Cloud Run, Cloud Functions & Eventarc

Architectural Objective: Serverless compute on Google Cloud enables developers and architects to build scalable, resilient applications without managing virtual machines, clusters, or operating system runtimes. A Google Professional Cloud Architect must design event-driven systems using Cloud Run Services, Cloud Run Jobs, Cloud Functions (2nd gen), and Eventarc, while optimizing concurrency, cold starts, CPU allocation, and private VPC connectivity.

---

Cloud Run Platform Architecture: Services vs. Jobs

Cloud Run is Google Cloud's fully managed containerized serverless compute platform. It abstracts all underlying infrastructure while supporting any programming language, framework, or binary that can be packaged into an OCI-compliant container image listening on a configured HTTP port.

+---------------------------------------------------------------------------------------------------+
|                             CLOUD RUN WORKLOAD ARCHITECTURE                                       |
+---------------------------------------------------------------------------------------------------+
| CLOUD RUN SERVICES (Request-Driven)             | CLOUD RUN JOBS (Run-to-Completion Batch)        |
+-------------------------------------------------+-------------------------------------------------+
| - Listens for incoming HTTP/gRPC/WebSockets     | - Explicitly triggered via API, scheduler, or CI|
| - Auto-scales from ZERO to thousands of instances| - Runs an array of parallel container tasks    |
| - Automatic request load balancing              | - Executes to completion without HTTP listener  |
| - Max timeout: 60 minutes per request           | - Max timeout: 24 hours per task execution      |
| - Use case: Web APIs, microservices, webhooks   | - Use case: Nightly ETL, ML batch inference, DB |
+-------------------------------------------------+-------------------------------------------------+

Cloud Functions (2nd Gen): Built on Cloud Run & Eventarc

In Google Cloud's modern architecture, Cloud Functions (2nd gen) is built natively on top of Cloud Run and Eventarc infrastructure. When an architect deploys a 2nd gen function, Google Cloud automatically packages the code into an OCI container and deploys it as a managed Cloud Run service.

---

Concurrency Model, Scaling Dynamics & Cost Optimization

Unlike traditional FaaS platforms (such as AWS Lambda or Cloud Functions 1st gen) that allocate one dedicated container instance per active request, Cloud Run supports multi-concurrency—allowing a single container instance to process up to 1,000 requests simultaneously.

TRADITIONAL FAAS (Single Concurrency):           CLOUD RUN (Multi-Concurrency = 80):
100 Concurrent Requests = 100 Instances          100 Concurrent Requests = 2 Instances
┌───┐ ┌───┐ ┌───┐ ┌───┐ ... ┌───┐                ┌────────────────────────┐ ┌────────────────────────┐
│VM │ │VM │ │VM │ │VM │     │VM │                │ Container Instance 1   │ │ Container Instance 2   │
└───┘ └───┘ └───┘ └───┘     └───┘                │ (Processes 80 reqs)    │ │ (Processes 20 reqs)    │
[!] 100 Cold Starts, High Memory Waste           └────────────────────────┘ └────────────────────────┘
                                                 [OK] Fast throughput, 98% fewer cold starts & lower cost

Sizing Container Concurrency

• Default Concurrency: 80 concurrent requests per instance.
• I/O-Bound Workloads (Node.js, Go, Python Asyncio, Java Spring Boot): Set concurrency to 80–200. Because threads spend most of their execution time awaiting database queries or external API calls, a single instance can easily multiplex hundreds of requests without CPU starvation.
• CPU-Bound Workloads (Heavy Image Processing, PDF Generation, ML Inference): Set concurrency to 1 to 4. Forcing heavy CPU tasks to share cores causes thread context switching overhead and degrades latency.

Instance Scaling Calculation

$\text{Required Instances} = \left\lceil \frac{\text{Peak Requests Per Second (RPS)} \times \text{Average Request Latency (seconds)}}{\text{Target Concurrency}} \right\rceil$

Example: An API receives 4,000 RPS with an average latency of 0.25 seconds (250ms). If concurrency is set to 80: $\text{Required Instances} = \left\lceil \frac{4000 \times 0.25}{80} \right\rceil = \left\lceil \frac{1000}{80} \right\rceil = 13 \text{ Instances}$

Managing Cold Starts: Min Instances (--min-instances)

When a serverless service scales from zero, the first incoming request experiences a cold start—the latency required for Google Cloud to allocate compute infrastructure, pull the container image, start the container runtime, and initialize application frameworks (e.g., JVM startup).

• Architectural Fix: Configure --min-instances = N (e.g., --min-instances 3).
• Behavior: Google Cloud maintains N pre-warmed container instances active 24/7. Incoming requests hit warm instances immediately with sub-10ms response times. Additional instances are spun up elastically only when traffic exceeds the serving capacity of the min-instances baseline.

Safeguarding Downstream Systems: Max Instances (--max-instances)

Serverless compute can scale up to thousands of instances in seconds. However, legacy downstream relational databases (like Cloud SQL or on-premises PostgreSQL) have fixed connection pool limits.

• Architectural Fix: Set --max-instances = N (e.g., --max-instances 50).
• Behavior: Cloud Run caps horizontal scaling at N instances. If traffic surges beyond this ceiling, excess requests are queued in the Cloud Run ingress proxy for up to 60 seconds awaiting available container capacity, preventing database connection pool exhaustion and cascading crashes.

---

CPU Allocation Strategies: Request-Based vs. CPU Always Allocated

Cloud Run offers two distinct CPU allocation and billing lifecycle models:

+-----------------------------------------------------------------------------------+
|                         CLOUD RUN CPU ALLOCATION MODELS                           |
+-----------------------------------------------------------------------------------+
| 1. CPU ALLOCATED DURING REQUESTS ONLY (Default Serverless Model)                  |
|    - CPU is active ONLY while processing an active HTTP request.                  |
|    - Idle CPU is throttled to ~0% when no requests are in flight.                 |
|    - Billed per millisecond strictly during request processing.                   |
|    - Anti-pattern: Background threads or async timers will FREEZE when request ends|
+-----------------------------------------------------------------------------------+
| 2. CPU ALWAYS ALLOCATED (Always-On Instance Model)                                |
|    - CPU remains active 100% of the time, even when zero requests are processing. |
|    - Supports continuous background processing, polling, WebSockets, thread pools.|
|    - Billed continuously for the entire lifecycle of the container instance.      |
+-----------------------------------------------------------------------------------+

Architectural Trade-offs

---

Event-Driven Architectures with Eventarc & CloudEvents

Eventarc provides a standardized, fully managed event routing bus that captures events from Google Cloud services, custom applications, and third-party SaaS platforms, delivering them to Cloud Run, GKE, or Cloud Workflows in the industry-standard CloudEvents format.

+-----------------------------------------------------------------------------------+
|                         EVENTARC EVENT ROUTING PIPELINE                           |
+-----------------------------------------------------------------------------------+
| EVENT SOURCES:                                                                    |
|   - Cloud Storage (Direct Object Create / Delete / Archive)                       |
|   - Cloud Audit Logs (130+ GCP Services: IAM updates, BigQuery table creation)    |
|   - Cloud Pub/Sub Topics (Custom application events)                              |
+-----------------------------------------+-----------------------------------------+
                                          |
                                          v
+-----------------------------------------------------------------------------------+
| EVENTARC ROUTER (Filters on event type, service, bucket name, method)             |
+-----------------------------------------+-----------------------------------------+
                                          |
                                          v
+-----------------------------------------------------------------------------------+
| EVENT DESTINATIONS (CloudEvents HTTP JSON Delivery):                              |
|   - Cloud Run Services                  - Cloud Functions (2nd Gen)               |
|   - GKE Services                        - Cloud Workflows Orchestration           |
+-----------------------------------------------------------------------------------+

Key Event Routing Patterns

1. Direct Cloud Storage Triggers: Eventarc routes mutations (google.cloud.storage.object.v1.finalized) directly from Cloud Storage to Cloud Run with sub-second latency, bypassing the need to manually configure Pub/Sub notifications.
2. Cloud Audit Log Triggers: Any administrative or data access action recorded by Cloud Audit Logs can trigger serverless execution. For example, capturing compute.instances.insert events across an organization to automatically trigger a Cloud Run service that verifies whether the newly launched VM complies with corporate security tags.
3. The CloudEvents Standard: All Eventarc events conform to the CNCF CloudEvents v1.0 specification, providing standard HTTP headers:
   • ce-id: Unique identifier for the event (enables deduplication).
   • ce-source: URI identifying the event producer (e.g., //storage.googleapis.com/projects/_/buckets/my-bucket).
   • ce-type: The event schema type (e.g., google.cloud.storage.object.v1.finalized).
   • ce-subject: The specific resource modified (e.g., objects/invoices/2026-08-invoice.pdf).

---

Private Backend Connectivity: Serverless VPC Access vs. Direct VPC Egress

By default, Cloud Run instances execute in a Google-managed multi-tenant VPC with outbound access to the public internet only. To connect securely to private resources inside a customer VPC (such as Cloud SQL private IPs, internal Load Balancers, Memorystore for Redis, or on-premises databases over Cloud Interconnect), architects configure VPC egress.

SERVERLESS VPC ACCESS CONNECTOR (Legacy)        DIRECT VPC EGRESS (Modern Architectural Standard)
┌──────────────┐                                ┌──────────────┐
│ Cloud Run    │                                │ Cloud Run    │
└──────┬───────┘                                └──────┬───────┘
       │ (Tunnel)                                      │ (Native NIC Attachment)
       v                                               v
┌─────────────────────────────┐                 ┌─────────────────────────────┐
│ Connector VMs (/28 Subnet)  │                 │ Customer VPC Subnet         │
│ (Throughput Bottleneck)     │                 │ (Direct Pod/Container IP)   │
└──────────────┬──────────────┘                 └──────────────┬──────────────┘
               v                                               v
┌─────────────────────────────┐                 ┌─────────────────────────────┐
│ Private Cloud SQL / Redis   │                 │ Private Cloud SQL / Redis   │
└─────────────────────────────┘                 └─────────────────────────────┘

Architectural Comparison: Connector vs. Direct VPC Egress

VPC Egress Routing Configurations

• private-ranges-only (Default): Only traffic destined for RFC 1918 private IP addresses (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) is routed through the VPC. Traffic destined for the public internet or public Google APIs traverses Google's default internet gateway.
• all-traffic: All outbound network traffic (including internet traffic) is routed through the VPC subnet. This allows architects to enforce enterprise security controls, such as inspecting all outbound traffic through a Next-Generation Firewall (NGFW) or directing internet traffic through a Cloud NAT gateway with a fixed static public IP address for third-party IP whitelisting.

---

Concrete Architectural Scenario: Event-Driven Document AI Pipeline

Scenario Profile

• Workload: Financial services document processing pipeline ingesting 100,000 PDF invoices daily.
• Requirements: Ingest PDFs via Cloud Storage, trigger OCR transformation within 5 seconds, extract metadata into a private Cloud SQL (PostgreSQL) database, and run nightly batch analytics without managing servers.
• Security Mandate: Cloud SQL must have no public IP address, and all egress must be encrypted over private internal networks.

Solution Architecture Blueprint

1. Event Ingestion: PDF invoices are uploaded to a regional Cloud Storage bucket. Eventarc captures the object.v1.finalized event and delivers the payload to a Cloud Run Service.
2. Real-Time OCR Service: The Cloud Run Service is configured with --min-instances 2 to eliminate cold starts and --concurrency 10. It attaches to the customer VPC via Direct VPC Egress (private-ranges-only), writing parsed invoice records directly to the private IP of Cloud SQL.
3. Nightly Batch Analytics: A Cloud Scheduler job triggers a Cloud Run Job at midnight. The job spawns 50 parallel container tasks that read the day's raw invoice archive, perform reconciliation calculations, and output financial summary reports to BigQuery.

---

[!IMPORTANT] Exam Watch: On the Google Professional Cloud Architect exam, whenever a scenario requires executing batch or scheduled tasks to completion (such as nightly database backups or bulk data conversions) without maintaining an active HTTP listener, choose Cloud Run Jobs. If a serverless workload must securely access a private Cloud SQL instance without public IP exposure, choose Direct VPC Egress (or Serverless VPC Access connector) with private IP routing. If an event-driven design requires capturing changes across GCP services in a standardized format, select Eventarc with CloudEvents.