Lesson 1: The Google Cloud Ops Map: Every Service on One Page

Why start with a map

When you take over an estate on Google Cloud, it is rarely short of tools. The trouble is that it has too many, under names that have changed several times. A runbook from 2019 says "check Stackdriver". A Terraform repo mentions config.googleapis.com. A patching ticket asks about "OS Config". This first level builds the map you will use for the rest of the course: every management and monitoring service in seven groups, with a one-line job description, the API name you will meet in IAM and billing, and any former names.

Think of it as the floor plan of a building before you look inside each room. Later levels go into each room. Here we just label the doors.

The one-page map

Naming history, briefly: Stackdriver was a startup that Google bought in 2014. Google dropped the Stackdriver brand in 2020, then called the family the operations suite, and now calls it Google Cloud Observability. The documentation URLs still contain /stackdriver/, and you will keep finding the old name in log filters, blog posts and old Terraform.

Walkthrough: find which doors are open in a project

The quickest way to see which of these services a project uses is to list its enabled APIs. Run this in Cloud Shell:

# List enabled APIs, keep only the ops-related ones
gcloud services list --enabled --format="value(config.name)" \
  | grep -E 'monitoring|logging|cloudtrace|cloudprofiler|clouderrorreporting|config\.|cloudasset|osconfig|recommender|servicehealth|billingbudgets|orgpolicy|deploymentmanager'

Realistic output from a three-year-old project:

cloudasset.googleapis.com
cloudtrace.googleapis.com
deploymentmanager.googleapis.com   # retired. Find what still depends on it
logging.googleapis.com
monitoring.googleapis.com
osconfig.googleapis.com            # VM Manager is (or was) in use

Here is what to take from it: Monitoring, Logging and Trace are on, as they are by default in most projects. Infrastructure Manager (config.googleapis.com) is not on, but Deployment Manager is. That points to old templates that need migrating, and it is the first item for your backlog.

Gotcha: an enabled API only tells you someone switched it on. It does not tell you anyone uses it. Always check for real resources too, such as patch deployments, budgets and dashboards.

How data moves between the groups

The services feed each other. A typical estate looks like this:

  [Change]                  [Run]                        [See]
Infra Manager / Config  --> VMs, GKE, Cloud Run  --metrics--> Cloud Monitoring (+ Managed Prometheus)
Connector (Terraform/KRM)        |  ^                 --logs----> Cloud Logging --sinks--> BigQuery / Storage
                                 |  | patches, OS policies  --traces--> Cloud Trace / Profiler
                                 |  VM Manager (OS Config agent)
                                 v
                     Cloud Asset Inventory  (what exists, what changed: 5-week history, export to BigQuery)
                                 |
   Cloud Billing (cost) ---------+--> Recommender / Active Assist --> FinOps hub (savings view)
   Personalized Service Health --> logs/alerts --> your on-call channel

Read it as four loops:

1. Telemetry loop: workloads send metrics, logs and traces to Observability, and alerts go to people.
2. Change loop: IaC creates resources, VM Manager keeps the guest OS in shape, and Cloud Asset Inventory records what actually changed, including changes made by hand outside IaC.
3. Cost loop: Billing data combines with Recommender's usage analysis, and the FinOps hub shows the savings you have achieved and those you could still make.
4. Health loop: Personalized Service Health tells you when the problem is Google's, not yours. It can raise alerts through Cloud Logging.

Trade-off to keep in mind: almost every arrow in this diagram can generate cost. The biggest items are usually log ingestion and metric volume, and later levels put numbers on them. A map that shows the arrows helps you see where the cost comes from.

What is retired, and what is only renamed

Do not mix these two up:

• Renamed but working: Stackdriver became Cloud Monitoring, Cloud Logging, Trace and so on. The OS Config API still sits under VM Manager. None of these needs a migration.
• Retired: Cloud Debugger (shut down 31 May 2023; its open-source replacement, Snapshot Debugger, was archived in September 2023) and Deployment Manager (end of support 31 March 2026). Both need a migration plan.

Key takeaways

• Seven groups: monitoring and logging, tracing, infrastructure as code, configuration and patching, inventory and governance, cost, and advice and health.
• Stackdriver is the old name for what Google now calls Google Cloud Observability (Monitoring, Logging, Trace, Profiler, Error Reporting).
• VM Manager is the product name, and OS Config (osconfig.googleapis.com) is the API and agent behind it.
• Infrastructure Manager (config.googleapis.com) runs Terraform for you and replaces Deployment Manager, which reached end of support on 31 March 2026.
• Cloud Asset Inventory keeps five weeks of history. Export to BigQuery if you need longer.
• Use gcloud services list --enabled as a quick first check of an estate, then confirm real usage.