What is Google Cloud Platform?

Google Cloud Platform (GCP) is Google’s public cloud: you create projects, enable APIs, and provision regional resources (VMs, buckets, serverless services) through the Console, the gcloud CLI, or tools such as Terraform. Unlike a single rented server, GCP splits ownership by service—storage, identity, networking, and observability each have their own APIs and IAM surfaces.

This chapter opens the Google Cloud Platform series. You will deploy a small Express + TypeScript API that uploads and lists files in Cloud Storage, package it as a Docker image, and harden the path with IAM, VPC, Cloud Armor, and observability. The table below maps each later chapter to the capability it adds.

For a comparable compute story on another cloud, see Azure Compute.

Resource hierarchy

GCP organizes resources in a tree:

flowchart TB
  org[Organization]
  org --> folder[Folders optional]
  folder --> project[Project]
  project --> resources[APIs buckets Run services VPCs]

An organization is the root for a company domain. Folders group projects (for example production vs sandbox). A project is the unit of billing, API enablement, and IAM: every bucket, Cloud Run service, and VPC network belongs to exactly one project ID.

Project IDs are globally unique strings you choose at creation time (for example my-file-api-dev). Project numbers are numeric identifiers some APIs return; keep the ID in your shell config and scripts.

Regions, zones, and locations

Most GCP services are regional or multi-regional. A region is a geographic area (for example europe-west1). Zones are isolated locations within a region (europe-west1-b); zonal resources (Compute Engine VMs, zonal disks) can fail if that zone has an outage.

Cloud Run, Artifact Registry, and many storage buckets are configured with a location (region or multi-region). Pick a region close to users and compliant with data residency. The series examples use europe-west1 unless you substitute your own.

Projects, billing, and APIs

Every API call is tied to a project. Billing must be enabled on that project (or on a billing account linked to it) before most services create billable resources.

Services are gated by APIs. Enable what you need once per project:

1
gcloud services enable \
2
  run.googleapis.com \
3
  artifactregistry.googleapis.com \
4
  cloudbuild.googleapis.com \
5
  storage.googleapis.com \
6
  logging.googleapis.com \
7
  monitoring.googleapis.com

The Console APIs & Services page shows the same list. If a gcloud command fails with “API not enabled,” run gcloud services enable SERVICE_NAME.

Set defaults so commands target the right project and region:

1
gcloud config set project YOUR_PROJECT_ID
2
gcloud config set run/region europe-west1
3
gcloud config set artifacts/location europe-west1

gcloud, Application Default Credentials, and Cloud Shell

The Google Cloud SDK installs gcloud, bq, and other tools. Install from cloud.google.com/sdk or use the package manager for your OS.

Sign in for user credentials and create Application Default Credentials (ADC) for client libraries and Terraform:

1
gcloud auth login
2
gcloud auth application-default login

Verify identity and project:

1
gcloud auth list
2
gcloud config get-value project

Cloud Shell is a browser VM with the SDK preinstalled and project auth already wired. Use it when you cannot install the SDK locally; the same commands in this series work there.

Modern storage workflows prefer gcloud storage over the legacy gsutil wrapper. The Google Cloud cheat sheet collects common commands.

The example app for this series

The sample app is a stateless HTTP API:

• GET /health returns { "ok": true }
• GET /files lists object names in a bucket (implemented in the Cloud Storage chapter)
• POST /files accepts a multipart upload (same chapter)

Scaffold the repository locally:

1
{
2
  "name": "gcp-series-file-api",
3
  "type": "module",
4
  "scripts": {
5
    "build": "tsc",
6
    "start": "node dist/server.js"
7
  },
8
  "dependencies": {
9
    "express": "^4.21.0"
10
  },
11
  "devDependencies": {
12
    "@types/express": "^4.17.21",
13
    "typescript": "^5.6.0"
14
  }
15
}

1
{
2
  "compilerOptions": {
3
    "target": "ES2022",
4
    "module": "NodeNext",
5
    "moduleResolution": "NodeNext",
6
    "outDir": "dist",
7
    "strict": true,
8
    "esModuleInterop": true
9
  },
10
  "include": ["src"]
11
}

1
import express from "express";
2

3
const port = Number(process.env.PORT) || 8080;
4
const app = express();
5

6
app.get("/health", (_req, res) => {
7
  res.json({ ok: true });
8
});
9

10
app.listen(port, () => {
11
  console.log(JSON.stringify({ severity: "INFO", message: `Listening on ${port}` }));
12
});

Cloud Run expects the container to listen on PORT (default 8080). The Dockerfile builds TypeScript and runs the compiled server:

1
FROM node:22-bookworm-slim AS build
2
WORKDIR /app
3
COPY package.json package-lock.json ./
4
RUN npm ci
5
COPY tsconfig.json ./
6
COPY src ./src
7
RUN npm run build
8

9
FROM node:22-bookworm-slim
10
WORKDIR /app
11
ENV NODE_ENV=production
12
COPY package.json package-lock.json ./
13
RUN npm ci --omit=dev
14
COPY --from=build /app/dist ./dist
15
ENV PORT=8080
16
EXPOSE 8080
17
CMD ["node", "dist/server.js"]

Build and run locally before you push an image:

1
npm install
2
npm run build
3
docker build -t file-api:local .
4
docker run --rm -p 8080:8080 file-api:local
5
curl -s localhost:8080/health

Later chapters add the Storage client, environment variables for the bucket name, and a Cloud Build pipeline. You can also express the same infrastructure with Getting started with Terraform on Google Cloud if you prefer IaC over imperative gcloud steps.

How the series is structured

Each chapter is one focused service. You can read linearly or jump to a topic, but the hands-on steps assume the previous chapter’s resources exist (for example Artifact Registry before Cloud Run deploy).

Identity comes first: without service accounts and IAM bindings, automated deploys and runtime access to buckets fail with opaque permission errors. Registry and Run follow, then data (Cloud Storage), automation (Cloud Build), network controls (VPC, Cloud Armor), and finally observability.

Next: IAM in Google Cloud defines the deployer and runtime identities for this app.