Google Cloud (GCP)

01The mental model: organisation, projects, regions

Everything in GCP belongs to a project. A project is a container for resources, billing and permissions: think of it as one apartment in a building, with its own keys and its own electricity meter. Projects can sit in folders under an organisation, which lets a company apply policies (for example "no public buckets") to every team at once. A common layout is one project per environment: app-dev, app-staging, app-prod. That gives you a hard wall between staging and production, separate quotas and a clear bill per environment. Resources run in a region (europe-west1, us-central1) and sometimes a zone inside it (europe-west1-b). Pick a region close to your users and keep the app and its database in the same one, because traffic across regions costs money and adds latency. Compared with AWS, a GCP project is roughly an AWS account, and a GCP organisation is roughly AWS Organizations.

• Organisation → folders → projects → resources.
• One project per environment is the simplest safe layout.
• Same region for app and database: lower latency, no inter-region egress.

02Compute: Cloud Run, GKE or Compute Engine

GCP gives you three main ways to run code. Compute Engine is plain virtual machines, the closest thing to a VPS: you manage the OS, patches and process manager yourself. GKE is managed Kubernetes. Standard mode gives you nodes to size and manage; Autopilot mode bills you for the CPU and memory your pods request and handles the nodes for you. Cloud Run sits on top: you hand it a container that listens on the PORT environment variable and it gives you an HTTPS endpoint, autoscaling by concurrent requests, revisions and traffic splitting. Cloud Run also runs jobs (batch tasks that run to completion), functions (the product formerly called Cloud Functions is now Cloud Run functions) and worker pools for pull-based background work. For a typical web API, start with Cloud Run. Move to GKE when you need many services with service mesh, custom networking or long-lived stateful workloads, and to Compute Engine when you need full control of the machine.

03Deploying a container to Cloud Run

The fastest path is to let Cloud Run build from source using Cloud Build and store the image in Artifact Registry (the old Container Registry has been shut down). For real projects, build the image in CI, push it to Artifact Registry, then deploy that exact image tag. Give the service its own service account with only the roles it needs, keep secrets in Secret Manager, and connect to Cloud SQL through the built-in connector. The key flags decide cost and behaviour: --min-instances keeps warm instances (no cold starts, but you pay for them), --max-instances caps both scale and your bill, and --concurrency sets how many requests one instance handles at once. Node and PHP apps usually handle many concurrent requests well, so the default of 80 is a sensible start.

1gcloud config set project app-prod
2gcloud services enable run.googleapis.com artifactregistry.googleapis.com
3 
4gcloud run deploy api \
5  --image=europe-west1-docker.pkg.dev/app-prod/apps/api:1.4.2 \
6  --region=europe-west1 \
7  [email protected] \
8  --set-secrets=DATABASE_URL=database-url:latest \
9  --add-cloudsql-instances=app-prod:europe-west1:main-db \
10  --min-instances=0 --max-instances=10 \
11  --concurrency=80 --cpu=1 --memory=512Mi \
12  --allow-unauthenticated

04Data: Cloud SQL, Firestore, Cloud Storage and BigQuery

Cloud SQL is managed PostgreSQL, MySQL or SQL Server: Google handles patching, automated backups, point-in-time recovery and optional high availability with a standby in another zone. It comes in Enterprise and Enterprise Plus editions; Plus adds faster failover and more performance at a higher price. AlloyDB is Google's Postgres-compatible engine for heavier workloads. Firestore is a serverless document database, popular with mobile apps. Cloud Storage holds files (uploads, backups, static assets) in buckets with storage classes from Standard to Archive. BigQuery is different from all of these: it is a columnar warehouse for analytics, not for your app's transactions. You load or stream events into it and run SQL over huge tables. On-demand pricing charges per terabyte scanned, so SELECT * on a wide table is literally expensive; select only the columns you need and partition tables by date.

• App data → Cloud SQL (or AlloyDB). Files → Cloud Storage.
• Analytics and reporting → BigQuery, fed from the app or by exports.
• Cloud SQL has no free tier: even the smallest instance bills every hour it exists.

05IAM: who can do what

IAM answers one question: which principal (a user, a group or a service account) has which role on which resource. Roles are bundles of permissions, such as roles/run.invoker or roles/cloudsql.client. Avoid the basic roles Owner, Editor and Viewer for anything but small experiments; they are far too broad. Give each workload its own service account and grant it predefined roles on the narrowest scope possible, a single bucket or secret rather than the whole project. The biggest security rule on GCP: do not create downloadable service account keys. A JSON key file is a long-lived password that ends up in repos and laptops. Code running on Google Cloud gets credentials automatically from the attached service account, and CI systems such as GitHub Actions should use Workload Identity Federation, which swaps a short-lived OIDC token for Google credentials. New organisations block key creation by policy by default for exactly this reason.

06Production tips and pricing traps

GCP bills by the second for most things, which is great until something runs that you forgot about. Set a budget with alerts on day one (budgets alert, they do not stop spending). The common surprises: Cloud SQL instances bill around the clock even when the app is idle; min-instances on Cloud Run bill while idle; Cloud NAT and load balancers have hourly charges; internet egress is charged per GB; and BigQuery on-demand queries are charged by bytes scanned, so a dashboard that refreshes a SELECT * every minute can cost more than the whole app. Logging is another trap: Cloud Logging charges for ingestion above the free allowance, so do not log full request bodies at debug level in production. The always-free tier covers small usage of Cloud Run, Cloud Storage, BigQuery and one small VM, and new accounts get trial credit, but read the limits before you rely on them.

07Cloud Run internals: concurrency, CPU allocation and cold starts

Cloud Run scales on concurrent requests, not on CPU alone. If concurrency is 80 and 400 requests are in flight, it aims for about five instances. Each instance runs in a gVisor-based sandbox (second-generation execution environment gives full Linux compatibility and faster CPU and network). Billing has two modes. Request-based billing charges CPU and memory only while an instance is handling a request, and CPU is throttled close to zero between requests, so timers, queue consumers and fire-and-forget work after the response may simply stall. Instance-based billing (formerly "CPU always allocated") charges for the whole instance lifetime at a lower unit rate and lets background work run. Cold starts come from pulling the image and booting your runtime; reduce them with small images, lazy initialisation, startup CPU boost and, where latency matters, a minimum instance count of one or two.

1# Background-friendly service: instance billing + warm instance
2gcloud run services update worker-api \
3  --region=europe-west1 \
4  --no-cpu-throttling \
5  --cpu-boost \
6  --min-instances=1 \
7  --execution-environment=gen2

08Networking: VPCs, private access and egress

A GCP VPC is global: one network can have subnets in many regions, unlike AWS where a VPC is regional. Cloud Run is not inside your VPC by default; to reach private resources (Cloud SQL private IP, Memorystore Redis, internal VMs) use Direct VPC egress, which attaches the service to a subnet without the older Serverless VPC Access connector VMs. Outbound calls to the internet that must come from a fixed IP (partner allowlists) go through Cloud NAT with a reserved address. Private Service Connect and Private Google Access let workloads reach Google APIs without public IPs. For inbound traffic, a global external Application Load Balancer gives one anycast IP, managed certificates, Cloud CDN and Cloud Armor (WAF and rate limiting) in front of Cloud Run, GKE or buckets. Each of these pieces has its own hourly and per-GB charges, so draw the traffic path before you build it.

09Organisation policies, audit logs and guardrails

At company scale, the important controls sit above projects. Organisation policy constraints can forbid service account key creation, restrict resource locations to certain regions, block public IPs on VMs, enforce uniform bucket-level access and stop public sharing. Cloud Audit Logs record admin activity for free and can record data access (at extra cost) for compliance. Put sensitive projects behind VPC Service Controls to reduce data exfiltration risk: even a stolen credential cannot copy a BigQuery dataset to a project outside the perimeter. Use groups, not individual users, in IAM bindings, and review grants with IAM Recommender, which suggests removing permissions that were never used. Infrastructure should be in Terraform with remote state in a bucket, so every change is reviewed rather than clicked in the console.