Google Cloud PCA - Section 8
Application Integration and Serverless Orchestration
Goal: recognize how Google Cloud connects services, routes events, schedules work, queues background tasks, and exposes APIs without overbuilding custom glue code.
PCA framing: This section is less about writing integration code and more about choosing the correct pattern. Use Eventarc for event routing, Workflows for ordered API orchestration, Cloud Tasks for controlled background execution, Cloud Scheduler for cron, API Gateway for simple serverless API front doors, Apigee for enterprise API management, Application Integration for SaaS and enterprise app workflows, and Pub/Sub for broad asynchronous decoupling. |
Fast Decision Matrix
Requirement | Choose | PCA Reasoning |
|---|---|---|
React to Google Cloud or SaaS events without polling | Eventarc | Use when a state change or event should trigger Cloud Run, Workflows, or functions. |
Execute multiple API calls in a controlled order | Workflows | Use for orchestration, branching, retries, error handling, and service-to-service workflows. |
Run background work outside the user request path | Cloud Tasks | Use for explicit task queues, rate limits, scheduled dispatch, and targeted retries to one handler. |
Run something on a schedule | Cloud Scheduler | Use for cron-style jobs that trigger HTTP, Pub/Sub, or other supported targets. |
Secure a REST API in front of serverless backends | API Gateway | Use for a lightweight managed API front door for Cloud Run, functions, or App Engine. |
Manage APIs as products for partners or developers | Apigee | Use for enterprise API lifecycle, policies, monetization, developer portal, OAuth, analytics, and governance. |
Connect enterprise apps/SaaS systems with low-code integration | Application Integration | Use when business workflows need connectors, transformation, mapping, and long-running processes. |
Expose connected SaaS or backend systems to integrations | Integration Connectors | Use with Application Integration to connect to systems like Salesforce, databases, Kafka, S3, and enterprise apps. |
Secure, monitor, and quota APIs using older Google API infrastructure | Cloud Endpoints | Know it as a lower-priority/legacy-ish API management option, especially for OpenAPI/gRPC patterns. |
Decouple many producers and consumers asynchronously | Pub/Sub | Use when services should not call each other directly and multiple subscribers may consume the same event stream. |
Schedule a recurring event that starts a workflow | Cloud Scheduler + Workflows | Common PCA pattern for scheduled orchestration without a custom cron server. |
Route an event into a workflow that calls multiple services | Eventarc + Workflows | Use Eventarc for the trigger, then Workflows for the ordered business process. |
Service Deep Dives
Eventarc
Why an org uses it: Eventarc gives organizations a managed eventing layer so services can respond to changes without polling or building custom event routers. It is useful for reacting to Cloud Storage object creation, Audit Log events, Pub/Sub messages, SaaS events, or changes from Google Cloud services.
PCA trigger: Pick Eventarc when the requirement says event-driven, state change, trigger Cloud Run/functions/Workflows, or avoid polling. It is especially strong with serverless event-driven architectures.
Common trap: Do not treat Eventarc like a task queue or a full orchestration engine. It routes events; it does not replace Workflows for multi-step logic or Cloud Tasks for controlled task execution.
Workflows
Why an org uses it: Workflows lets teams sequence service/API calls in a defined order without standing up a custom orchestrator. It can call Google Cloud APIs, Cloud Run, Cloud Run functions, external HTTP APIs, and handle branching, retries, and errors.
PCA trigger: Pick Workflows when the scenario says orchestrate APIs, chain microservices, call multiple systems, wait for callbacks, or handle branching/retry logic.
Common trap: Do not use Workflows for high-volume data transformations; Dataflow, Dataproc, or data pipeline tools fit that better. Also do not use it when a simple event trigger alone is enough.
Cloud Tasks
Why an org uses it: Cloud Tasks lets an application enqueue work to be processed later by a specific worker endpoint. Organizations use it to protect user-facing apps from slow work, throttle downstream systems, and retry failed background processing.
PCA trigger: Pick Cloud Tasks when the requirement says background task, rate limit, retry policy, explicit queue, delayed execution, or dispatch to a specific HTTP handler.
Common trap: Do not confuse Cloud Tasks with Pub/Sub. Cloud Tasks is better for explicit task execution to one handler; Pub/Sub is better for broad messaging and fan-out.
Cloud Scheduler
Why an org uses it: Cloud Scheduler is managed cron. It removes the need to run a VM or Kubernetes cron service just to trigger periodic jobs.
PCA trigger: Pick Cloud Scheduler when the requirement says hourly, daily, weekly, cron, scheduled report, scheduled Pub/Sub message, scheduled HTTP call, or recurring infrastructure task.
Common trap: Do not use Cloud Scheduler as a per-user task queue. If each task needs its own retry/rate policy, use Cloud Tasks.
API Gateway
Why an org uses it: API Gateway provides a lightweight managed front door for APIs, commonly in front of Cloud Run, Cloud Run functions, or App Engine. It can help standardize API exposure, authentication, monitoring, and traffic management without a full enterprise API platform.
PCA trigger: Pick API Gateway when the requirement is a simple secure REST API for serverless backends, especially when Apigee would be too heavy.
Common trap: Do not choose API Gateway when the scenario needs enterprise API products, monetization, developer portals, advanced policy control, or complex lifecycle governance. That points to Apigee.
Apigee
Why an org uses it: Apigee is Google Cloud’s enterprise API management platform. Organizations use it when APIs are business products shared with partners, customers, mobile apps, or developer ecosystems.
PCA trigger: Pick Apigee when the scenario says enterprise API management, API product, developer portal, monetization, OAuth/token policies, advanced quota/rate limiting, API analytics, or partner API governance.
Common trap: Do not pick Apigee for a small internal API in front of a single Cloud Run service unless the enterprise API management requirements are explicit.
Application Integration
Why an org uses it: Application Integration is for connecting business systems and automating enterprise workflows with less custom code. It helps connect SaaS apps, databases, Pub/Sub, APIs, and enterprise backends with mapping and process logic.
PCA trigger: Pick Application Integration when the requirement says integrate Salesforce/ERP/CRM/SaaS systems, transform payloads, use connectors, or automate long-running business processes.
Common trap: Do not use Application Integration when a developer simply needs a short ordered set of API calls; Workflows is usually simpler for service orchestration.
Integration Connectors
Why an org uses it: Integration Connectors expose supported apps and data sources through a standard interface for Application Integration. This reduces custom connector code and protocol-specific glue work.
PCA trigger: Pick Integration Connectors when the scenario emphasizes connecting to many third-party/enterprise systems such as databases, SaaS apps, Kafka, S3, Active Directory, or business platforms.
Common trap: Do not treat connectors as the workflow engine by themselves. They are usually part of Application Integration or a broader integration architecture.
Cloud Endpoints
Why an org uses it: Cloud Endpoints is an API management option that helps secure, monitor, analyze, and set quotas for APIs using Google infrastructure. It is more likely to appear as a comparison or legacy option than the first-choice modern answer.
PCA trigger: Know Cloud Endpoints when questions mention OpenAPI, gRPC, API keys, quotas, monitoring, or older App Engine/API management patterns.
Common trap: For new lightweight serverless APIs, API Gateway is usually the cleaner answer. For enterprise API lifecycle, Apigee is the stronger answer.
Pub/Sub
Why an org uses it: Pub/Sub decouples services with asynchronous messaging. It is useful for event ingestion, fan-out, stream distribution, and service integration where producers and consumers should scale independently.
PCA trigger: Pick Pub/Sub when the requirement says asynchronous messaging, many producers/consumers, fan-out, streaming ingestion, decoupling, or event distribution.
Common trap: Do not use Pub/Sub when the scenario requires precise per-task scheduling, controlled dispatch rate to one handler, or task-specific retry policies. Use Cloud Tasks for that.
Common PCA Comparison Patterns
Pattern | How to Think About It |
|---|---|
Eventarc vs Pub/Sub | Eventarc routes events to destinations; Pub/Sub is the messaging backbone for asynchronous producers/subscribers and fan-out. |
Pub/Sub vs Cloud Tasks | Pub/Sub is many-to-many messaging. Cloud Tasks is controlled task execution to a specific target with queue-level rate/retry behavior. |
Cloud Scheduler vs Cloud Tasks | Scheduler is cron. Tasks is per-task queueing, delay, throttling, and retry behavior. |
Workflows vs Application Integration | Workflows is developer-oriented API/service orchestration. Application Integration is better for low-code enterprise app/SaaS process integration. |
Workflows vs Cloud Composer | Workflows is lightweight serverless service/API orchestration. Composer/Airflow is better for complex data pipeline DAGs and dependency-heavy data workflows. |
API Gateway vs Apigee | API Gateway is a simple managed API front door. Apigee is enterprise API management and API product lifecycle. |
API Gateway vs Cloud Endpoints | API Gateway is usually the modern simple API front door answer. Endpoints is lower-priority and tied to older OpenAPI/gRPC API management patterns. |
Synchronous vs asynchronous design | Use synchronous calls for immediate responses. Use Pub/Sub, Eventarc, Cloud Tasks, or Workflows when decoupling, retries, long-running work, or reliability matters. |
Architecture Patterns to Recognize
• Event-driven serverless app: a Cloud Storage or Audit Log event is routed by Eventarc to Cloud Run or Workflows.
• Scheduled automation: Cloud Scheduler triggers Pub/Sub, HTTP, or Workflows to run a recurring task without a cron VM.
• Background task queue: the web app enqueues work in Cloud Tasks and returns quickly to the user while workers process tasks later.
• Enterprise API product: Apigee manages partner/customer APIs with products, quotas, policy enforcement, analytics, and developer onboarding.
• Simple serverless API front door: API Gateway protects and standardizes access to Cloud Run or Cloud Run functions.
• SaaS/business-system workflow: Application Integration and Integration Connectors move data between CRM, ERP, databases, Pub/Sub, and APIs.
• Fan-out messaging: Pub/Sub lets one producer publish messages consumed by multiple independent services.
Common PCA Traps
• Choosing Pub/Sub when the question asks for exact rate limits, delayed execution, or a retry policy to a single HTTP handler. That is Cloud Tasks.
• Choosing Cloud Scheduler when every user action creates its own unit of work. Scheduler is cron, not a task queue.
• Choosing Apigee for a tiny internal API when API Gateway is enough.
• Choosing API Gateway when the question says developer portal, monetization, API products, partner onboarding, or advanced enterprise API policy. That is Apigee.
• Choosing Workflows for massive data transformation. Workflows orchestrates services; it is not a data processing engine.
• Using direct service-to-service synchronous calls when the requirement emphasizes reliability, decoupling, retry behavior, or independent scaling.
• Forgetting idempotency. Retries and event-driven systems can deliver repeated requests, so handlers must tolerate duplicate work.
• Treating Eventarc as the whole workflow. Eventarc triggers the process; Workflows or the destination service usually contains the business logic.
Mini Scenario Drill
Scenario | Likely Answer | Why |
|---|---|---|
Cloud Storage object upload should trigger image processing | Eventarc + Cloud Run | Eventarc handles the event trigger; Cloud Run runs the processing service. |
Nightly job must call several APIs and handle failures | Cloud Scheduler + Workflows | Scheduler starts the run; Workflows owns the sequence, retries, and branching. |
Checkout request should return quickly while email/inventory updates run later | Cloud Tasks | Queue the background work and control dispatch/retry behavior. |
A partner-facing API needs products, quotas, portal, and analytics | Apigee | This is enterprise API management, not just a simple gateway. |
A simple REST API needs a managed front door for Cloud Run | API Gateway | Use when API exposure is simple and Apigee would be overkill. |
CRM updates must sync with ERP using low-code connectors | Application Integration + Integration Connectors | Use enterprise integration tooling instead of custom glue code. |
Cram Summary
• Eventarc = event routing and event-driven serverless triggers.
• Workflows = ordered API/service orchestration with branching, retries, and error handling.
• Cloud Tasks = controlled background task queue to a specific handler.
• Cloud Scheduler = managed cron.
• API Gateway = lightweight secure API front door for serverless backends.
• Apigee = enterprise API management and API product lifecycle.
• Application Integration = low-code enterprise/SaaS workflow integration.
• Integration Connectors = standardized connections to enterprise apps and data sources.
• Cloud Endpoints = older/lower-priority API management option; know it for comparisons.
• Pub/Sub = asynchronous decoupling, fan-out, and service integration messaging.