Google Compute Engine

Google Compute Engine (GCE) is the IaaS component of Google Cloud that lets users create and run virtual machines on Google's infrastructure. GCE VMs run on Google's custom-designed servers using the KVM hypervisor, which provides strong isolation between instances. Each VM is a fully functional, standalone computer with its own operating system, disk, and network interfaces.

GCE provides flexibility and control over your computing environment. Unlike App Engine (PaaS) or Cloud Functions (FaaS), GCE gives you full root access, allowing you to install any software, configure the OS, and manage security. It is ideal for workloads that require specific OS configurations, legacy applications, or lift-and-shift migrations from on-premises data centers.

GCE offers several machine families optimized for different workloads: - General-purpose (E2, N2, N2D, N1): Balanced CPU-to-memory ratios, suitable for web servers, small databases, and development environments. - Compute-optimized (C2, C2D): High CPU-to-memory ratio, ideal for batch processing, media transcoding, and high-performance computing. - Memory-optimized (M1, M2, M3): High memory-to-CPU ratio, for large in-memory databases (e.g., SAP HANA) and memory-intensive analytics. - GPU-accelerated (A2, G2): Attach NVIDIA GPUs for machine learning, scientific computing, and graphics rendering.

Each machine type has predefined vCPU and memory combinations. Custom machine types allow you to choose specific vCPU and memory values (subject to limits: e.g., 1 vCPU requires at least 3.75 GB memory on N1).

An instance template defines the VM configuration (machine type, boot image, disk, network tags, etc.) and is used to create managed or unmanaged instance groups. Managed instance groups (MIGs) provide autoscaling, rolling updates, and self-healing. Unmanaged instance groups are just collections of VMs without these features.

GCE pricing is per second (minimum 1 minute) for compute time. There are three pricing models: - On-demand: Pay full price per second, no commitment. - Preemptible/Spot: Up to 60-91% discount, but instances can be terminated at any time (max 24 hours). Suitable for fault-tolerant batch jobs. - Committed Use Discounts (CUD): Commit to 1 or 3 years for 57% discount on vCPU and memory.

Disk and network egress are billed separately. Sustained use discounts automatically apply for instances running more than 25% of a month (up to 30% discount).

Each VM can have one or more disk volumes: - Persistent Disk (PD): Network-attached block storage, available as standard (HDD) or SSD. Can be resized online, snapshotted, and attached to multiple VMs in read-only mode. - Local SSD: Physically attached to the host server, very low latency but data is lost on stop/terminate. Up to 3 TB per VM. - Cloud Storage FUSE: Mount GCS buckets as file systems (not for persistent databases).

Boot disks can be public images (Debian, Ubuntu, CentOS, RHEL, Windows Server, etc.) or custom images. You can also use container-optimized OS for running Docker containers.

Each VM gets a primary internal IP address (private, from the VPC subnet) and optionally an external IP (ephemeral or static). VMs can be placed in a VPC network with firewall rules controlling traffic. You can create multiple network interfaces for multi-homing.

A VM goes through states: PROVISIONING, STAGING, RUNNING, STOPPING, STOPPED, SUSPENDING, SUSPENDED, TERMINATED. You can stop/start a VM (preserving persistent disks) or reset (reboot the OS). Suspending saves memory state to disk (RAM saved to a suspend file) for faster resume.

Create a VM with gcloud:

gcloud compute instances create my-vm \
  --zone=us-central1-a \
  --machine-type=e2-medium \
  --image-family=ubuntu-2204-lts \
  --image-project=ubuntu-os-cloud \
  --boot-disk-size=20GB \
  --tags=http-server

List instances:

gcloud compute instances list

SSH into a VM:

gcloud compute ssh my-vm --zone=us-central1-a

Stop and start:

gcloud compute instances stop my-vm --zone=us-central1-a
gcloud compute instances start my-vm --zone=us-central1-a

Create an instance template:

gcloud compute instance-templates create my-template \
  --machine-type=e2-medium \
  --image-family=ubuntu-2204-lts \
  --image-project=ubuntu-os-cloud

Create a managed instance group:

gcloud compute instance-groups managed create my-mig \
  --base-instance-name=my-instance \
  --template=my-template \
  --size=3 \
  --zone=us-central1-a

A financial services company wants to migrate its on-premises application servers to Google Cloud. They have 50 Windows Server VMs running a legacy .NET application with SQL Server. They use GCE to create VMs with the same vCPU and memory configuration as their on-premises servers. They use Migrate for Compute Engine (formerly Velostrata) to replicate the disks and perform a cutover. In production, they use managed instance groups with autoscaling based on CPU utilization to handle variable load. Common issues: mismatched machine types causing performance degradation, and forgetting to open firewall ports for database connections. They also use Cloud VPN to connect back to on-premises Active Directory.

A research lab uses GCE to run batch simulations for drug discovery. They use preemptible VMs with C2 machine types for compute-intensive tasks. They create a custom image with their simulation software and store results in Cloud Storage. They use a managed instance group with autoscaling based on queue depth (via Cloud Tasks). To handle spot terminations, they checkpoint progress to persistent disk every 10 minutes. Scale: up to 10,000 vCPUs concurrently. Pitfalls: preemptible VMs can cause long tail latency if not checkpointing; also, vCPU quota limits require pre-approval.

An e-commerce company runs a WordPress site on GCE. They use a single N2-standard-4 VM with a 100 GB SSD persistent disk. They attach a static external IP and use Cloud CDN to cache static assets. For the database, they use Cloud SQL instead of running MySQL on the VM. They configure a firewall rule to allow HTTP/HTTPS from 0.0.0.0/0 but restrict SSH to a bastion host. They use Cloud Monitoring to alert on high CPU. Common misconfigurations: not setting up a health check for the load balancer (if using one), and forgetting to enable deletion protection, leading to accidental VM deletion.