Lesson 1: Every Google Cloud Compute Service on One Page

Why start with one page

When someone asks "where should this run?", most teams answer with whatever they used last time. That habit is how a nightly batch job ends up on a 24/7 VM, or a simple webhook ends up on a Kubernetes cluster. Before comparing anything in detail, you need a map of every service Google offers and of how much of the stack you operate in each.

Think of it like housing. Bare metal is buying the land. A VM is renting an empty flat. Kubernetes is a serviced flat where you still arrange the furniture. Serverless is a hotel room: you bring your bag (a container or a function) and nothing else.

The map: seven hosting models

Two look-alikes to keep apart:

• Bare metal instances are a Compute Engine feature. They are physical servers with no hypervisor between you and the CPU (for example C3 and X4 -metal machine types), managed like other Compute Engine resources.
• Bare Metal Solution is a separate product. It puts purpose-built servers in regional extensions connected to a Google Cloud region with less than 2 ms latency (usually under 1 ms). It is aimed mainly at specialised workloads such as Oracle Database.

Gotcha: Cloud Run worker pools (generally available since April 2026) are for pull-based background work, such as Pub/Sub pull subscribers, Kafka consumers and self-hosted CI runners. They do not take HTTP requests. If you skip them you may wrongly rule out Cloud Run for queue consumers.

Current and former names

Older blog posts, Stack Overflow answers and Terraform modules use names that have since changed. Keep this table to hand:

Best practice: a rename does not always change the API or the CLI. Cloud Run functions are still deployed with gcloud functions deploy, and Cluster Toolkit still lives in the hpc-toolkit GitHub repository. Search for the old name and the new name when you debug.

Walkthrough: see which compute APIs a project uses

Each service has its own API. Listing the enabled ones gives you a quick inventory of a project you have inherited. Run this in Cloud Shell:

# List enabled APIs and keep only the compute services on our map
gcloud services list --enabled --format="value(config.name)" \
  | grep -E "^(compute|container|run|cloudfunctions|appengine|batch|tpu|vmwareengine|baremetalsolution)\.googleapis\.com$"

Realistic output:

compute.googleapis.com     # Compute Engine, MIGs and GPU VMs
container.googleapis.com   # GKE
run.googleapis.com         # Cloud Run services, jobs and worker pools
cloudfunctions.googleapis.com  # Cloud Run functions (old API name kept)

This project runs VMs, Kubernetes and serverless, and nothing from Batch, TPU or the specialised hosting group. An enabled API does not prove anything is running, but it tells you where to look.

Google's own decision guidance

Google's "Choose compute options" page (docs.cloud.google.com/docs/compute-area/choose-compute-options) gives a one-line rule for each core service. In paraphrase:

• Compute Engine: you need custom configurations, special kernel settings or administrative control of the servers.
• GKE: you need container orchestration for distributed apps or microservices.
• Cloud Run: you want to deploy containerised web apps or jobs without managing servers.
• Batch: asynchronous jobs such as data analysis, video conversion or simulations, with no servers to deploy.
• Cluster Director: AI, ML or HPC clusters without setting up the network or the cluster OS yourself.
• Cluster Toolkit: automated cluster deployment while you keep control of the OS and software stack.
• VMware Engine: moving on-premises VMware workloads with minimal operational change.

The page also lists where TPUs can be used: Compute Engine, GKE, Cluster Toolkit and AI Hypercomputer, but not Batch, Cloud Run, Cluster Director or VMware Engine. That one line can remove half your options for a TPU workload.

Worked example: a first shortlist

Workload: a Python service that turns uploaded images into thumbnails. It is triggered per upload, runs for about 2 seconds, keeps no state, has spiky traffic and is maintained by a small team.

Rule out:  VMware Engine, Bare Metal Solution  -> no legacy estate, no Oracle
Rule out:  Cloud TPU, Cluster Director/Toolkit -> no accelerators, not a cluster job
Rule out:  GKE                                 -> orchestration overhead for one small service
Shortlist: 1. Cloud Run functions  (event-driven, least to operate)
           2. Cloud Run service    (same platform, full container control)
           3. Batch                (only if uploads are processed in bulk overnight)

That is the right size for a first shortlist: two or three candidates and a one-line reason for each one you ruled out. The next level turns this gut feel into a structured profile.

Key takeaways

• Sort services into seven hosting models: VMs, fleets, batch and HPC, accelerators, containers, serverless and specialised hosting. Each step up the list hands more of the stack to Google.
• Bare metal instances (Compute Engine) and Bare Metal Solution (regional extensions, Oracle-focused) are different products.
• Translate old names: Cloud Functions became Cloud Run functions, HPC Toolkit became Cluster Toolkit, Hypercompute Cluster became Cluster Director, and Anthos became GKE Enterprise, which then merged into GKE.
• Google's "Choose compute options" page gives a one-line rule for each service and shows where TPUs can be used.
• A first shortlist has two or three services, with a reason recorded for each one you ruled out.