GCP + Cloud-Agnostic

Fourth phase of Year 2. GCP fast-tour as the AWS compare. The point isn’t GCP mastery — it’s seeing what’s primitive vs. vendor-specific by looking at the same shape twice. ~5 weeks, ~60 hrs (shorter on purpose).

Phase 11 is the pattern-first scaffold’s COMPARE step at year scale. Eight weeks of AWS gave you depth in one cloud; five weeks of GCP make that depth transferable. If GCP feels easy, Phase 10 taught you cloud — the category. If GCP feels foreign, Phase 10 taught you AWS — the brand.

The phase is shorter on purpose. You’re not learning GCP from scratch; you’re mapping AWS concepts to GCP equivalents to extract the underlying primitives. The trap is treating it like Phase 10-but-Google: re-doing all the depth work, reading every doc, building everything from zero. Don’t. The work is mapping — every concept you internalized in Phase 10 has a GCP equivalent, and the goal is the table in section 2.1, not a second IAM mental model.

By phase end, terralabs ships gcp-* modules + at least one Crossplane Composition for GCP, and basecamp deploys the same workload to K3s + EKS + GKE. Total GCP spend: $0, well within the $300 free credit window. That sets up Phase 12 (Backstage + mesh + security across clusters) and Phase 13 (multi-cloud capstone) on a substrate that is already three-cloud by default.

Prerequisites

Phase 10 complete — AWS at depth

GCP account with $300 free credits activated

You accept: this is a compare phase. You’re not learning GCP from scratch — you’re mapping AWS concepts to GCP equivalents to extract the cloud pattern.

Why this phase exists

The fastest way to know what’s primitive in cloud is to learn the same primitive twice in different clouds. After this phase, “compute = K8s/managed instances,” “storage = object store + managed Postgres,” “identity = OIDC tokens + roles,” “network = VPC + LB” — these are concepts, not AWS-specific names.

terralabs gets GCP modules. basecamp adds GKE as a third cluster target. Total cloud spend: $0 (within $300 credits). This is also where the Master Plan’s “patterns, not tools” bet earns its keep — five weeks here vs. eight in AWS, because the pattern transferred.

1. PROBLEM

Every cloud sells the same primitives with different names + different opinions. AWS has EKS; GCP has GKE; Azure has AKS. AWS has S3; GCP has GCS; Azure has Blob Storage. The patterns are the same; the implementations differ.

The trap is learning each cloud’s marketing names instead of the patterns underneath. The fix is the compare exercise.

2. PRINCIPLES (compressed: this is a compare phase)

2.1 The cloud-primitive map

Concept	AWS	GCP	Azure	Pattern
Managed K8s	EKS	GKE	AKS	container orchestrator
Object storage	S3	GCS	Blob	flat namespace + metadata
Managed Postgres	RDS	Cloud SQL	Database for PG	leader-follower with backups
Identity	IAM	IAM (different model)	Entra ID	role/policy graph
VPC	VPC	VPC	VNet	layer-3 network
Load balancer	ALB/NLB	Cloud LB	App Gateway	L4/L7 routing
Pub/sub	SNS+SQS	Pub/Sub	Service Bus	event broker
Functions	Lambda	Cloud Functions / Cloud Run	Functions	event-driven compute

2.2 Where they actually differ

IAM model — AWS is policy-centric; GCP is role-centric. The mental model shifts; the goal of least privilege doesn’t.
Network defaults — AWS lets you wire complex VPCs; GCP defaults to a single global VPC. Both work; ergonomics differ.
K8s ergonomics — GKE is generally smoother out-of-the-box; EKS gives you more control + more sharp edges.
Pricing shape — AWS line items are baroque; GCP’s are simpler at the cost of fewer knobs.

2.3 Cloud-agnostic basecamp

basecamp’s applications/ should be 99% identical whether the target cluster is K3s, EKS, or GKE. What changes is clusters/{cluster}/ overlays — node-pool sizes, storage classes, ingress controller flavor.

→ Pattern: multi-tenancy (cluster-as-tenant variant)

Investigate:

What in basecamp’s manifests must be cloud-specific? (StorageClass, IngressClass, node selectors.)
What can be cloud-agnostic? (Almost everything else — the workload manifests, the Helm chart values for the app itself, the ArgoCD Application definition.)

3. TRADE-OFFS

Decision	AWS	GCP	When
Cost	line items	simpler bundles	AWS for control; GCP for predictability
Network	wire-it-yourself	global by default	AWS for complex topologies; GCP for simplicity
K8s ergonomics	EKS + lots of operators	GKE Autopilot or standard	GKE is friendlier OOTB
Vendor neutrality	Crossplane	Crossplane	Either via Crossplane Compositions
ML	SageMaker (heavy)	Vertex AI (heavy)	Year 4 — both abstracted via Crossplane/K8s

4. TOOLS (as of Q1 2026)

gcloud CLI
gke-gcloud-auth-plugin for kubectl access
terralabs gcp-* modules (you’ll write these this phase)
existing aws-* modules for the compare

5. MASTERY (lean)

5.1 Reading list

Required	Why
GCP “Essentials” docs	Orientation
Compare guides: “AWS to GCP for AWS pros”	Direct mapping

5.2 Operational depth checklist

[ ] Set up GCP project + budget alerts; verify $0 baseline
[ ] Add GCP modules to terralabs: gcp-vpc, gcp-gke, gcp-cloud-sql, gcp-storage-secure-bucket
[ ] Add Crossplane Composition: gke-with-cloudsql (parallel to eks-with-rds from Phase 9)
[ ] Provision a GKE cluster via terralabs; add as a basecamp ArgoCD target cluster
[ ] Deploy the same Helm chart (e.g., `triage`) to K3s + EKS + GKE; observe identical behavior
[ ] Configure Workload Identity (GCP equivalent of IRSA): GKE pod → GCP service account → GCS access
[ ] Compare GCP Cloud Logging vs AWS CloudWatch for the same workload
[ ] Diagnose one inter-cloud edge case: TLS cert that works on EKS Ingress but not GKE Ingress, or DNS that resolves differently
[ ] Build a "cloud-agnostic" view in basecamp/clusters/ — verify identical workload manifests, only overlays differ
[ ] Destroy GKE + Cloud SQL at end of phase; verify $0 ongoing spend

6. COMPARE: write the cloud-agnostic guide

Write a 1500-word internal doc: “How I would design a cloud-agnostic platform team workflow at a $COMPANY.” Cover:

What stays cloud-agnostic in your stack (Crossplane, K8s, GitOps).
What requires per-cloud overlays.
Cost optimization shape per cloud.
When to commit to one cloud vs hedge.

This becomes a Year 2 portfolio artifact — useful in interviews + as a blog post draft, and a structural prerequisite for Phase 13’s multi-cloud capstone.

7. OPERATE

2+ runbooks (gke-node-pool-recovery, cross-cloud-DNS-debug)
Weekly log

8. CONTRIBUTE

GCP-adjacent: Terraform GCP provider, Crossplane GCP provider, GKE node-image issues.

Validation criteria

[ ] All 10 operational depth checks
[ ] terralabs ships gcp-* modules + at least one Crossplane Composition for GCP
[ ] basecamp deploys same workload to K3s + EKS + GKE
[ ] Cloud-agnostic platform writeup
[ ] 2+ runbooks; 5+ weekly log entries
[ ] Total GCP spend this phase: $0
[ ] Pattern entries reinforced (no new DEEP):
    - least-privilege (now applied across two IAM models)
    - defense-in-depth (now applied across two clouds)
    - multi-tenancy (clusters as tenants — first touch)
[ ] Exit Test passed

Exit Test

Time: 2 hours.

Build (60 min) — given a fresh GCP project, terralabs-provision GKE + Cloud SQL; deploy basecamp’s triage chart; verify it works identically to the EKS deployment.
Articulate (60 min) — 1000 words: “Map AWS to GCP for compute / storage / identity / network / observability. Where do the patterns end and the implementations begin?”

Anti-patterns

Anti-pattern	Why
Trying to learn GCP from scratch	This is a compare phase. Map, don’t restart.
”Multi-cloud everything” without justification	Real ops cost; pick by need, not philosophy
GCP-specific shortcuts in basecamp manifests	Defeats the cloud-agnostic point
Forgetting credit window	$300 credits expire; track usage

Patterns reinforced this phase

least-privilege — applied across two IAM models
defense-in-depth — applied across two clouds
multi-tenancy — first touch (clusters-as-tenants)

Browse the full category at patterns/infrastructure-and-platform/.

→ Next: Phase 12: Platform Engineering