What's changed: Created Professional Cloud Architect Chapter 1 (Domain 1 "Design and plan" part 1: requirements to architecture = business/technical requirements, resource hierarchy, organization policies, KPIs/SLOs; choosing compute/storage/data = CE/GKE/Cloud Run/Functions, Cloud Storage/PD/Filestore, Cloud SQL/Spanner/Firestore/Bigtable/BigQuery).
1.2Choosing compute, storage, and data services
Understand choosing Google Cloud compute (Compute Engine, GKE, Cloud Run, Cloud Functions) by use case, storage (Cloud Storage classes, Persistent Disk, Filestore), and databases (Cloud SQL, Spanner, Firestore, Bigtable, BigQuery).
Once requirements are set, choose the building blocks to meet them. A core architect skill is selecting the best-fit compute, storage, and database for the use case.
1.2.1Choosing compute
| Service | Best-fit use case |
|---|---|
| Compute Engine | Full VM control, lift-and-shift migration |
| GKE | Container orchestration, portability |
| Cloud Run | Containers serverless, scale to zero |
| Cloud Functions | Event-driven small functions |
For full control or migrating existing VMs (lift-and-shift), use Compute Engine. For serious container orchestration with portability, GKE. To run containers serverless and scale to zero, Cloud Run. For small event-driven processing, Cloud Functions. Remember "less management = more serverless" and "more control = more VM."
1.2.2Choosing storage and databases
For storage: unstructured objects = Cloud Storage (class by access frequency), VM block = Persistent Disk, shared files = Filestore. For databases: typical business RDB = Cloud SQL, global strong consistency = Spanner, mobile/web documents = Firestore, huge-scale low-latency time series/IoT = Bigtable, large-scale analytics (DWH) = BigQuery. The rule: choose by data shape, scale, and consistency requirements.
Common: use case → service. E.g., "migrate existing VMs as-is" = Compute Engine; "containers with minimal ops" = Cloud Run; "global, strongly consistent RDB" = Spanner; "petabyte SQL analytics" = BigQuery; "ultra-low-latency IoT time series" = Bigtable; "cheap long-term unstructured storage" = Cloud Storage (Coldline/Archive).
Watch the mix-ups: (1) Do not confuse Spanner (global strong-consistency RDB), BigQuery (analytics DWH), and Cloud SQL (typical RDB). (2) Bigtable is not for analytical SQL (it is huge-scale, low-latency NoSQL). (3) Choose Cloud Run vs GKE by "minimal ops vs fine control."
1.2.3Section summary
- Compute = CE (control/migration)/GKE (container orchestration)/Cloud Run (serverless)/Functions (events)
- Storage = Cloud Storage (objects)/Persistent Disk (block)/Filestore (shared files)
- DB = Cloud SQL/Spanner (global strong consistency)/Firestore/Bigtable (low-latency scale)/BigQuery (analytics)
Sign in to track progress — Log in.
Quick check
(just a quick review)Q1. To lift-and-shift existing on-prem VMs to Google Cloud as-is, which compute best fits?
Q2. To run containers with minimal ops and scale to zero when idle, which is best?
Q3. You need a globally distributed relational database with strong consistency. Which is best?
Q4. To analyze petabyte-scale data quickly with SQL, which is best?
Q5. To read/write huge-scale data like IoT time series at low latency, which is best?
Q6. Which is the best general guideline when choosing a compute service?