Compute Engine

Compute Engine runs virtual machines when you need OS-level control: custom images, persistent disks, startup scripts, and VPC networking. A FullStack Node.js team might use it for legacy monoliths, self-managed reverse proxies, or workloads that do not fit serverless or Kubernetes yet.

| Concept | Meaning | |---------|---------| | Instance | A VM with machine type, zone, and attached disks | | MIG | Managed instance group with autoscaling and rolling updates | | Startup script | Boot-time configuration such as `npm ci` and systemd unit |

					gcloud compute instances create api-1 \
  --zone=us-central1-a \
  --machine-type=e2-medium \
  --image-family=debian-12 \
  --tags=http-server
				

Prefer instance templates and MIGs over hand-patched single VMs. Use health checks, graceful shutdown on `SIGTERM`, and separate boot disks from durable data.

On interviews: when VMs beat Cloud Run or GKE; MIG rolling updates; preemptible/spot cost trade-offs; firewall tags versus broad open ports.

Common pitfalls: SSH-only deploys without immutable images; no autoscaling on traffic spikes; storing app state on the boot disk; forgetting zone redundancy.

The trade-off is maximum control and migration flexibility versus patching, capacity planning, and operational toil.

Checklist:

• Use MIGs and instance templates for stateless tiers.
• Externalize durable state to Cloud SQL or Cloud Storage.
• Automate deploys with images, not manual SSH edits.
• Set health checks and graceful shutdown for Node.js.