GCP Core Services

Compute Engine, GCS, Cloud SQL, Cloud Run, IAM — Google Cloud essentials and how it differs from AWS.

GCP's Mental Model

Google Cloud Platform has the same building blocks as AWS — compute, storage, databases, networking, identity — but with a different philosophy.

GCP's character:
• Cleaner IAM model — service accounts and roles are unified
• Strongest networking of the big three (Google's global network)
• Best-in-class data and ML services (BigQuery, Vertex AI, Spanner)
• Less feature-rich on the operational sprawl side
• Generally simpler defaults, fewer footguns
• Smaller market share but loyal users

The big concepts:

Project — the top-level container. All resources live in a project. Projects have separate billing, IAM, quotas. Equivalent to an AWS account but lighter weight (you can have many).

Organization — collection of projects. Folder hierarchy for large orgs.

Region / Zone — same as AWS regions and AZs. us-central1 is a region; us-central1-a is a zone.

Resource hierarchy:

Organization
  └── Folder (optional)
       └── Project
            └── Resources (VMs, storage, etc.)

IAM permissions can be set at any level and are inherited downward. Set "viewer" at the org → everyone can view everything. Set "editor" at a project → only that project.

Compute Engine — VMs

Compute Engine is GCP's IaaS — the equivalent of EC2.

Machine families:
• e2 — efficient, low cost (good for dev, light workloads)
• n2 — general purpose
• c3 — compute-optimized
• m3 — memory-optimized
• a3 — GPU/AI workloads

Sizing: <family>-<type>-<vCPUs> — e2-standard-4 is e2 family, standard memory ratio, 4 vCPU.

Launching a VM via gcloud:

gcloud compute instances create my-vm \
  --machine-type=e2-medium \
  --image-family=debian-12 \
  --image-project=debian-cloud \
  --zone=us-central1-a \
  --tags=http-server

GCP-specific niceties:
• Sustained Use Discounts — automatic discount for steady usage (no commitment needed)
• Custom machine types — pick exact CPU and RAM (1 vCPU, 6.5 GB) without family constraints
• Live migration — Google moves your VM during maintenance without restart
• Preemptible VMs — like AWS Spot but with a hard 24-hour limit

For most production workloads, you'll skip raw VMs and use Cloud Run, GKE, or App Engine. Compute Engine is for when you specifically need a VM.

Cloud Storage — Object Storage

Cloud Storage is GCP's S3 equivalent. Buckets and objects.

gsutil mb gs://my-bucket
gsutil cp file.txt gs://my-bucket/
gsutil ls gs://my-bucket
gsutil rsync -r ./dir gs://my-bucket/dir

Storage classes:
• Standard — frequent access
• Nearline — accessed less than once a month
• Coldline — less than once a quarter
• Archive — less than once a year

Differences from S3:
• Globally unique bucket names (same as S3)
• Strong consistency on all operations (S3 eventually was consistent on some ops, mostly fixed by 2026)
• Multi-region buckets are first-class — single bucket spanning continents
• Tighter integration with BigQuery (can query objects without ETL)
• Object lifecycle policies move/delete objects based on age, similar to S3
• Signed URLs work the same way as S3 presigned URLs

Cost: similar to S3, slightly cheaper egress in some cases. Egress to other Google services (BigQuery, Compute Engine in same region) is free.

Cloud SQL — Managed Databases

Cloud SQL runs Postgres, MySQL, SQL Server.

gcloud sql instances create myapp-db \
  --database-version=POSTGRES_16 \
  --tier=db-custom-2-7680 \
  --region=us-central1 \
  --availability-type=REGIONAL    # multi-zone, like RDS Multi-AZ

What it handles: backups, patching, failover, replication. Same as RDS.

For more advanced needs:
• Cloud Spanner — globally distributed, strongly consistent SQL. Genuinely unique tech. Expensive but rare workloads need it (financial systems with global users).
• AlloyDB — Postgres-compatible, faster than Cloud SQL for analytics. Newer.
• Bigtable — NoSQL, time-series, IoT
• Firestore — document database, real-time sync, mobile-friendly
• BigQuery — analytics warehouse. Petabyte-scale SQL queries. Pay per query.

Cloud Run — Serverless Containers

Cloud Run is GCP's killer app for backend developers. Hand it a container; it scales from zero to thousands of instances on traffic. Pay per request.

# Build and push
gcloud builds submit --tag gcr.io/my-project/myapp

# Deploy
gcloud run deploy myapp \
  --image gcr.io/my-project/myapp \
  --platform managed \
  --region us-central1 \
  --allow-unauthenticated

That's it. You get:
• HTTPS endpoint with auto-managed certificate
• Auto-scaling (zero to N based on requests)
• Pay only when handling requests
• Built-in health checks
• Concurrent request handling (up to 1000 per instance)

When Cloud Run is amazing:
• Web APIs and backends
• Internal tools
• Anything containerized that scales with traffic
• Low to medium traffic apps where serverless economics shine

When less great:
• Workloads needing persistent connections (WebSockets supported but with caveats)
• Very steady high-traffic apps (might be cheaper on Compute Engine + LB)
• Apps with very long startup time (cold starts)

Cloud Run vs Lambda: Cloud Run runs containers (more flexible), Lambda runs functions (more constrained). Cloud Run handles HTTP automatically; Lambda needs API Gateway. For HTTP services, Cloud Run is usually simpler.

Cloud Run jobs (newer): for non-HTTP work. Runs a container to completion. Good for batch jobs, scheduled tasks.

GKE — Kubernetes

GKE is generally considered the best managed Kubernetes by people who use multiple. Why:

• GKE Autopilot — fully managed mode where you don't manage nodes. You just deploy Pods. Pricing per Pod resource consumption.
• Standard mode — you manage node pools. Cheaper for predictable workloads.
• Auto-upgrades, auto-repair, auto-scaling enabled by default
• Tight integration with Google's networking (HTTP(S) Load Balancer is global anycast — your service gets one IP that routes to the nearest region automatically)

Compared to EKS: GKE generally less fiddly. EKS is more flexible but expects you to know more.

Quick GKE deploy:

gcloud container clusters create-auto myapp \
  --region=us-central1

kubectl apply -f deployment.yaml   # works the same as any K8s

IAM — Service Accounts & Roles

GCP's IAM is cleaner than AWS's in important ways.

Identities:
• Users — humans (Google accounts)
• Groups — collections of users
• Service Accounts — non-human identities (apps, VMs, etc.). Equivalent to AWS roles but more elegant.

Roles:
• Predefined roles — Google-curated, scoped to services (roles/storage.objectViewer)
• Custom roles — you define
• Basic roles (Owner, Editor, Viewer) — too broad for production. Avoid.

Granting access:

gcloud projects add-iam-policy-binding my-project \
  --member='user:alice@example.com' \
  --role='roles/storage.objectAdmin'

gcloud projects add-iam-policy-binding my-project \
  --member='serviceAccount:my-sa@my-project.iam.gserviceaccount.com' \
  --role='roles/cloudsql.client'

Service accounts attach to resources (VMs, Cloud Run services, GKE Pods via Workload Identity). The resource gets short-lived credentials automatically.

Workload Identity Federation — the modern way to authenticate from outside GCP (GitHub Actions, AWS, on-prem) without long-lived keys. Set up once; CI/CD authenticates without secrets.

AWS vs GCP — When to Pick Which

Use AWS when:
• You want maximum service breadth
• Your team's existing skills are AWS-heavy
• You need very specific AWS-only services (some compliance regions, some niche services)

Use GCP when:
• You're heavy on data/ML (BigQuery, Vertex AI are amazing)
• You value cleaner IAM and operational simplicity
• Global networking matters (Cloud Load Balancing's global anycast is genuinely better)
• You want Cloud Run (the cleanest serverless container experience)

For learning purposes:
• AWS has more job postings, more documentation, more questions answered on Stack Overflow
• GCP has cleaner abstractions if you're new to cloud
• Concepts transfer in both directions — once you know one, the other is fast

The real-world truth: most teams pick one and stay. The cost of multi-cloud usually exceeds the benefits. If you're personally curious, install both CLIs, do their tutorials, see which feels better. There's no wrong answer.