GCP, service by service.

What this is, and why service-shaped

The Cloud Codex above is organised by topic — compute, storage, networking, identity, databases. That's the right shape for system-design conversations. This subtree is organised by GCP service, because that's the shape you need when you're building or debugging on Google Cloud: someone says "the Cloud Run service is cold-starting under load" and you want to already know which of the three concurrency knobs to look at.

Each page covers the same things: the model the service implements, the parts you'll actually configure, how it bills, what breaks at scale, what to use it for and what not to, and a small gcloud lab you can run to feel it work. Reading sequence is recommended but not strict — most pages cross-link to the others where it matters.

How GCP thinks differently from AWS

If AWS is your first cloud, four things on GCP will feel wrong until they suddenly feel right. First, everything lives in a project. Not an account — a project, sitting in a hierarchy of organisation → folders → projects, with IAM policy inheriting downward. A project is a billing boundary, a quota boundary, and a deletion boundary all at once. The AWS habit of multi-account isolation maps to "make another project," and it's a single command.

Second, the network is global. One VPC spans every region; only subnets are regional. Two VMs in different continents on the same VPC reach each other over internal IPs with no peering, no transit gateway, no VPN. The load balancer is global too — a single anycast IP, terminated at the nearest Google edge, with traffic riding Google's backbone from there. The AWS pattern of "an ALB per region plus Route 53 in front" collapses into one resource.

Third, maintenance is invisible. Compute Engine live-migrates running VMs off hosts that need patching, so the "scheduled maintenance, your instance will reboot" email mostly doesn't exist. It changes how you think about single-VM reliability.

Fourth, the crown jewels are the databases. BigQuery and Spanner are externalised versions of systems Google published papers about and ran internally for a decade first. BigQuery separates storage from compute so completely that you can query a petabyte without provisioning anything; Spanner uses GPS-and-atomic-clock time (TrueTime) to give you externally consistent transactions across continents. Neither has a true AWS counterpart, and both are common reasons teams pick GCP at all.

The map

Planned Three more pages are on the way: an IAM deep dive (service accounts, workload identity federation, policy inheritance), Cloud SQL, and Cloud KMS. They'll slot into the map above when they land.

How the labs work

Every page closes with a section called "Build it yourself" — an ordered list of gcloud commands that creates the resource, exercises it, observes it, and tears it down. You won't understand a service from reading about it; you understand it from watching gcloud run deploy go from zero to a URL in forty seconds, then hitting it hard enough to watch the instance count climb.

• Use a dedicated project. Create a fresh GCP project just for these labs — projects are cheap, disposable, and deleting one tears down everything inside it. Set a budget alert at $25 so you find out fast if you forget something.
• gcloud first. Every lab is written for the gcloud CLI. The console is friendlier the first time you meet a service; gcloud is what you'll script, and its flags map almost one-to-one onto the API.
• Tear down at the end. Every lab finishes with the delete commands. Run them. Persistent disks, static IPs, and idle GKE clusters are the usual surprises on the bill — or just delete the whole project when a sequence is done.
• Region affects price. us-central1 is the cheap default and gets new services first. European and Asian regions cost more for the same machine. Pick one region and stay in it for the whole sequence.

Adjacent reading

• Cloud Codex (topic shape). Same material organised by problem — compute, storage, networking, identity, databases, multi-region, observability, cost. Read this first if you don't already know what services to look up.
• AWS Codex. The sibling subtree. Most pages here name their AWS counterpart explicitly, so reading the two side by side is the fastest way to see what's a cloud concept and what's a vendor choice.
• Kubernetes Codex. For the GKE side of containers — the page here covers what Google manages and how Autopilot changes the deal; that codex covers what's running inside.
• Distributed Systems Codex. Spanner and Pub/Sub make a lot more sense with the consistency, replication, and ordering background fresh — TrueTime in particular is a distributed-systems idea wearing a database costume.
• Networking Codex. The protocol-layer companion to the global VPC and anycast load balancing pages.