Lesson 1: The Integration Map: Every Service on One Page

Why start with a map?

Suppose you join a team and open their repository. You see google_cloud_tasks_queue in Terraform, a cron.yaml left over from App Engine, an apiproxy/ folder from Apigee Edge, and a runbook that says "the Eventarc trigger". These all connect applications, but they belong to different groups, and some of the names are years old.

This level puts every Google Cloud integration service on one page. You will not configure anything deeply yet. The goal is that when you see a name, you know which group it belongs to, what it does in one line, and whether the name is current.

Think of the six groups as the departments of a post office:

• Queues: one parcel goes to one known address, at a pace the recipient can handle.
• Publish-subscribe: one newsletter is copied to every subscriber.
• Event routing: a sorting office that looks at each envelope and sends it to whoever registered interest.
• Workflow and orchestration: a clerk with a checklist who runs a multi-step process, including the timed ones.
• API management: the front counter, where outsiders are identified, rate-limited and served.
• Connectors: couriers who already know how to deliver to Salesforce, SAP or a database.

The one-page map

Gotcha: Cloud Scheduler is in the orchestration group, not the queue group. It decides when something runs. Cloud Tasks decides where a single piece of work goes and how fast. People mix them up because both make outbound HTTP calls.

Walkthrough: find the services in a real project

Each service has its own API. Listing the enabled APIs is the quickest way to see what a project already uses.

# List enabled APIs and keep only the integration ones
gcloud services list --enabled \
  --format="value(config.name)" | \
  grep -E "pubsub|eventarc|workflows|cloudtasks|cloudscheduler|apigee|apigateway|integrations|connectors"

# Example output from a typical project:
# cloudscheduler.googleapis.com   -> Cloud Scheduler
# cloudtasks.googleapis.com       -> Cloud Tasks
# eventarc.googleapis.com         -> Eventarc (both editions use this API)
# pubsub.googleapis.com           -> Pub/Sub
# workflows.googleapis.com        -> Workflows

If you see integrations.googleapis.com and connectors.googleapis.com, the project uses Application Integration and Integration Connectors. If you see apigee.googleapis.com, it has an Apigee X or hybrid organisation.

Walkthrough: read Terraform without a glossary

Terraform resource names tell you which service and group you are looking at.

# Queues
resource "google_cloud_tasks_queue" "emails" {}           # Cloud Tasks

# Publish-subscribe
resource "google_pubsub_topic" "orders" {}                # Pub/Sub

# Event routing
resource "google_eventarc_trigger" "on_upload" {}         # Eventarc Standard (trigger model)
resource "google_eventarc_message_bus" "core" {}         # Eventarc Advanced (bus model)
resource "google_eventarc_enrollment" "billing" {}        # Eventarc Advanced subscription to a bus

# Workflow and orchestration
resource "google_workflows_workflow" "onboarding" {}      # Workflows
resource "google_cloud_scheduler_job" "nightly" {}        # Cloud Scheduler

# API management
resource "google_apigee_organization" "org" {}            # Apigee X or hybrid

# Connectors
resource "google_integrations_client" "client" {}         # Application Integration
resource "google_integration_connectors_connection" "sf" {} # Integration Connectors

Tip: trigger points to Eventarc Standard. message_bus, enrollment and pipeline point to Eventarc Advanced. A single project can use both.

Reading old names correctly

• "Eventarc" in docs or blogs from before late 2024 means what is now Eventarc Standard. The trigger model did not change. Google added a second edition beside it.
• Apigee Edge is the older product line, with Public Cloud (SaaS) and Private Cloud (on-premises) versions. Its replacements are Apigee X and Apigee hybrid, and Google is directing Edge customers to migrate. Job adverts that ask for "Apigee Edge" usually mean migration work.
• Apigee Integration is now Application Integration. It can be bought on its own, without Apigee.
• App Engine push queues are served by Cloud Tasks. When you upgrade the App Engine SDK, it redirects push queue calls to the Cloud Tasks APIs.
• cron.yaml is the App Engine Cron Service, which can only call its own app. Cloud Scheduler is the general service and can call any HTTP target or Pub/Sub topic.

Application integration versus data streaming

Pub/Sub appears in both courses, so it helps to know where the line falls.

When a message's job is to make another application act, it belongs in this course.

Key takeaways

• The six groups are queues, publish-subscribe, event routing, workflow and orchestration, API management, and connectors. Every service in this course fits into one of them.
• Cloud Tasks sends work to one handler. Pub/Sub copies messages to many subscribers. Eventarc routes events by filter. Workflows runs steps in order. Cloud Scheduler fires on a timetable.
• Eventarc has two editions. Standard uses triggers. Advanced uses a bus with enrollments and pipelines, plus CEL transformation. Older docs that say "Eventarc" mean Standard.
• Apigee Edge is being replaced by Apigee X and Apigee hybrid. Apigee Integration is now Application Integration, which uses Integration Connectors for SaaS and databases.
• Pub/Sub Lite was turned down in March 2026, so Pub/Sub is the managed publish-subscribe option to use.
• Application integration is about making applications act and coordinate. Moving data in bulk for analytics belongs to the analytics course.