Decision Frameworks

After eleven chapters and fifty-one services, you have a vocabulary. This topic is about the skill that distinguishes a senior engineer from a junior one with the same vocabulary: given a problem, picking the right service in under a minute with the right justification. Not because you remember every detail of every service, but because you have internalized a small number of decision trees that take you to the right answer fast.

The decision trees that follow are not the only way to think about service selection, but they are durable. The exact products change generation to generation; the questions — does this need ACID across regions, does this need a POSIX filesystem, is this fan-out or one-to-one — do not. Get those questions right and the answers fall out.

The Compute Decision Tree

Asked in order, these questions choose the right compute service for almost every workload:

1. Is this a stateless HTTP service that fits in a container? → Cloud Run. The right default for new web services. Scales to zero, pay per request, no infrastructure to manage.
2. Is it a single event-driven function with no need for a long-running container? → Cloud Functions (gen 2 / Cloud Run functions). Lighter operational surface than Cloud Run for the simplest case.
3. Does the team run many containerized services that need orchestration, complex networking, or specific Kubernetes features? → GKE, ideally Autopilot. Reserve for workloads where Cloud Run is not enough.
4. Does it need an actual OS — GPUs, custom kernels, specific OS-level configuration, legacy applications that cannot be containerized? → Compute Engine. The escape hatch when managed services do not fit.
5. Is this an existing App Engine application running well? → App Engine. Keep it. For new projects, prefer Cloud Run.

The tree resolves in this order on purpose. Always start with Cloud Run as the candidate; only walk further down the tree when a real requirement rules it out. The default mistake here is reaching for GKE or Compute Engine first out of comfort with old patterns.

Stateless HTTP service that fits in a container→Cloud Run

Single event-driven function, no long-running container→Cloud Functions

Many services needing orchestration or specific Kubernetes features→GKE

Needs a real OS — GPUs, custom kernel, un-containerizable legacy→Compute Engine

Existing App Engine app already running well→App Engine

The Database Decision Tree

Databases have more dimensions than compute does. The right service depends on the data model, the consistency requirement, and the scale axis.

1. Is this analytical (large scans, aggregations, infrequent writes)? → BigQuery. Not transactional, not for user-facing low-latency reads.
2. Does it need ACID transactions across global regions with horizontal write scaling? → Cloud Spanner. A specific class of problem with a specific solution.
3. Is it relational (PostgreSQL, MySQL, SQL Server) at regional scale? → Cloud SQL as the default. Move to AlloyDB only when a measured Cloud SQL performance limit is hit.
4. Is it document-structured, mobile-friendly with real-time sync needs? → Firestore Native mode.
5. Is it high-throughput time series, IoT telemetry, operational analytics with known key access patterns? → Bigtable. The wide-column NoSQL workhorse.
6. Is this a cache or session store needing sub-millisecond latency? → Memorystore. Redis (or Valkey) for the access pattern; never as a primary data store.

The frequent mistake here is the inverse of the compute tree: starting with the most powerful option (Spanner because "we'll need global scale eventually") instead of the simplest one that fits today (Cloud SQL until measured limits force the migration).

Analytical — large scans, aggregations, infrequent writes→BigQuery

ACID transactions across global regions, horizontal writes→Spanner

Relational (Postgres/MySQL/SQL Server) at regional scale→Cloud SQL

Document-structured, mobile, real-time sync→Firestore

High-throughput time series, IoT, known key patterns→Bigtable

Cache or session store, sub-millisecond latency→Memorystore

The Storage Decision Tree

Three storage services with different shapes:

1. Object access by key over HTTP, files of any size, globally accessible? → Cloud Storage. The default for almost everything: build artifacts, media, backups, data lake ingest, static site hosting.
2. Block device attached to a VM, filesystem mounted in OS, single-VM access (or read-only multi-attach)? → Persistent Disk. The boot disk and the database disk.
3. POSIX shared filesystem with simultaneous read-write access across multiple VMs? → Filestore. The narrowest niche of the three — only when the workload genuinely needs POSIX shared semantics that Cloud Storage cannot deliver.

Object access by key over HTTP, any size, globally accessible→Cloud Storage

Block device on one VM, OS filesystem mounted→Persistent Disk

POSIX filesystem shared read-write across many VMs→Filestore

The Messaging Decision Tree

The decision tree from Chapter 5, applied:

1. Broadcast fan-out — one event, many independent consumers? → Pub/Sub.
2. Rate-limited HTTP call to one specific endpoint with retry? → Cloud Tasks.
3. Recurring schedule that triggers other work? → Cloud Scheduler for recurring cron, or Cloud Tasks with schedule_time for one-off deferred work.
4. Multi-step workflow with conditional logic, error handling, and rollback? → Cloud Workflows.
5. Reacting to GCP events from many sources, especially audit logs? → Eventarc.

The most common error in this tree is conflating Pub/Sub and Cloud Tasks. Re-read the Cloud Tasks page if the choice is not obvious.

One event, many independent consumers (fan-out)→Pub/Sub

Rate-limited delivery to one target (HTTP or App Engine), with retries→Cloud Tasks

Recurring schedule (cron) that triggers work→Cloud Scheduler

Multi-step workflow with conditionals and error handling→Cloud Workflows

Reacting to events from Google Cloud, SaaS, or custom sources→Eventarc

The Identity Decision Tree

Identity has three distinct dimensions:

1. End users of a B2C app (customers, mobile app users)? → Firebase Authentication, or Identity Platform for enterprise-feature variants.
2. Internal employees, contractors, GCP operators? → Cloud Identity with SAML SSO to your corporate IdP — or skip Google accounts entirely with Workforce Identity Federation.
3. Workloads outside GCP that need to call GCP services? → Workload Identity Federation. Almost never service account keys.

End users of a B2C app (customers, mobile users)→Firebase Auth

Internal employees, contractors, GCP operators→Cloud Identity

Workloads outside GCP that must call GCP APIs→Workload Identity Fed.

Decision Anti-Patterns

A few patterns of bad decisions that recur across teams:

• Choosing for resume — picking GKE because it looks impressive on a CV when Cloud Run handles the workload. The team carries operational overhead forever for one nice line on a profile.
• Premature optimization for scale — Spanner for an app that will never need global writes. The cost is real and immediate; the benefit is hypothetical and distant.
• Familiarity bias — every former AWS engineer reaching for EC2-equivalent because that is what they know, instead of Cloud Run. The mental model carries over; the operational discipline does not need to.
• "It might not scale" — over-engineering with no measurement. Without numbers, the decision is fear-based. Decisions should be load-based.
• The latest service reflex — picking the newest GCP service because it was announced last quarter. New services lack operational maturity; respect that.