Question

Difficulty: HardPlanning Serverless Compute Options (Cloud Run and Cloud Functions)

A financial services firm is building two backend components for a real-time transaction verification pipeline on Google Cloud:

1. Component X: An HTTP microservice that receives high-throughput API traffic. It relies on a custom C++ native binary compiled for Linux and must process up to 80 concurrent HTTP requests per instance to maximize resource efficiency.
2. Component Y: A lightweight Python event handler that executes briefly whenever a transaction log object is finalized in a Cloud Storage bucket, parsing the log and writing summary statistics to a database.

Which architecture recommendation correctly pairs these workloads with the appropriate Google Cloud serverless compute options?

  1. Deploy Component X to Cloud Run to support the custom C++ binary container environment and instance-level request concurrency, and deploy Component Y to Cloud Functions using a Cloud Storage event trigger.Answer
  2. B
    Deploy Component X to Cloud Functions 1st gen to simplify deployment overhead, and deploy Component Y to Cloud Run using a Cloud Scheduler poll job.
  3. C
    Deploy both Component X and Component Y to Cloud Functions 2nd gen in a single unified deployment package to share runtime dependencies.
  4. D
    Deploy Component X to Compute Engine Managed Instance Groups with startup scripts, and deploy Component Y to Cloud Run with no ingress traffic allowed.

Answer

Deploy Component X to Cloud Run to leverage custom container runtimes with multi-concurrency, and deploy Component Y to Cloud Functions with direct Cloud Storage event integration.
Cloud Run is built for containerized microservices, making it the appropriate choice when custom compiled system binaries (such as C++ libraries) are required and when high per-instance HTTP request concurrency (e.g., 80 requests/instance) is needed. Cloud Functions provides a FaaS paradigm that natively integrates with Cloud Storage event triggers to execute simple, short-lived Python functions upon file upload without container management.

Step-by-Step Solution

1
Analyze Component X requirements
Identified dependencies on a custom compiled Linux C++ binary and a concurrency target of 80 requests per instance.
Cloud Run executes custom OCI containers with support for arbitrary native libraries and configurable request concurrency per instance (up to 1,000 requests).
2
Analyze Component Y requirements
Identified a simple event-driven task triggered directly by object uploads in Cloud Storage.
Cloud Functions (FaaS) is ideal for short-lived, event-triggered code snippets natively integrated with Google Cloud events such as Cloud Storage triggers.
3
Evaluate architectural fit
Cloud Run for Component X and Cloud Functions for Component Y meets all technical constraints with minimum operational overhead.
This separation uses containerized serverless (Cloud Run) for binary/concurrency needs and function-as-a-service (Cloud Functions) for lightweight event processing.

Key Concept

Evaluating trade-offs between Cloud Run (custom containers, high concurrency, complex binaries) and Cloud Functions (lightweight, event-driven snippet execution).
Rate this question