Google Cloud Compute Options

What Are Google Cloud Compute Options?

Compute is the engine that runs your application code. On Google Cloud, "compute" is not a single product — it is a family of services that span the entire abstraction spectrum from raw virtual hardware to fully managed event handlers. For the Cloud Digital Leader (CDL) exam, you must understand the four main options: Compute Engine (IaaS), Google Kubernetes Engine (GKE) (managed containers), Cloud Run (serverless containers), and App Engine / Cloud Functions (PaaS / FaaS).

Choosing the right compute option is one of the most consequential decisions a business makes when adopting Google Cloud. The wrong choice can lead to ballooning operational costs, sluggish release cycles, or wasted engineering time on infrastructure plumbing. The right choice frees teams to focus on customer value rather than operating systems.

The CDL exam does not ask you to write kubectl commands or pick specific machine types. Instead, it asks business questions: "A retailer needs to migrate a legacy Java application without rewriting it — which compute option fits best?" or "A startup wants to pay nothing when no traffic arrives — what should they use?" This study note builds that decision framework using concrete Google Cloud product names, the shared-responsibility model, and Taiwan-friendly analogies.

By the end of this chapter you will be able to map any business scenario to the right Google Cloud compute service, explain who manages what at each abstraction layer, and articulate the cost and operational trade-offs of moving up the stack from IaaS to FaaS.

The IaaS, CaaS, PaaS, FaaS, SaaS Spectrum

Cloud computing services sit on a spectrum of abstraction. The further "up the stack" you go, the more Google manages for you, and the less you need to worry about. Understanding this spectrum is the single most important concept for choosing a compute option.

Infrastructure as a Service (IaaS)

IaaS gives you virtual hardware: a virtual machine (VM) with CPU, RAM, disk, and a network interface. Google manages the physical data center, the hypervisor, and the underlying network. You manage everything above the hypervisor: the operating system, patches, runtime libraries, middleware, your application, and your data. On Google Cloud, the IaaS product is Compute Engine.

Containers as a Service (CaaS)

CaaS abstracts away the operating system. You package your app into a container image (typically Docker), and Google runs that container on a managed Kubernetes cluster. You no longer patch OS kernels, but you still manage the container image, the application runtime inside it, and your scaling policies. On Google Cloud, this is Google Kubernetes Engine (GKE) in Standard mode. GKE Autopilot pushes further up the stack by managing the nodes as well.

Platform as a Service (PaaS)

PaaS abstracts away both the OS and the container runtime. You just upload your source code, and Google figures out how to run it — choosing the runtime, scaling instances, and handling load balancing. On Google Cloud, this is App Engine (Standard or Flexible) and, in a serverless-container hybrid form, Cloud Run.

Functions as a Service (FaaS)

FaaS is the most abstracted compute model. You write a single function (e.g., "when a file lands in this bucket, resize it"), and Google runs that function only when an event triggers it. There are no servers, containers, or runtimes to manage. On Google Cloud, this is Cloud Functions (now called Cloud Run functions in the latest generation).

Software as a Service (SaaS)

SaaS is the top of the stack — you don't manage code at all, you just consume the application. Google Workspace (Gmail, Docs, Drive) is the canonical SaaS example, though it's outside the "compute options" question for CDL.

白話文解釋（Plain English Explanation）

The compute spectrum can feel abstract when you're staring at console screenshots. The best way to internalize it is to map each option to a real-world equivalent that everyone in Taiwan already knows. The three analogies below all show the same idea — moving from "you do everything" to "you just consume" — but each highlights a different facet of the decision.

Analogy 1 — Buying a Car vs Renting vs Taxi vs Uber

Imagine you need to get around Taipei every day. You have four options.

Buying a car (on-premises) means you pay a huge upfront cost, you maintain it yourself (oil changes, tires, registration), and you pay even when it sits in the garage. This is the traditional data center: high Capex, high responsibility, low flexibility.

Renting a car long-term (Compute Engine / IaaS) is like leasing a sedan for a year. You don't own it, but you still drive it, choose the route, fuel it, and decide where to park. You can pick a compact car, an SUV, or a truck depending on the job — just like picking a general-purpose, compute-optimized, or memory-optimized machine family on Compute Engine. You also handle the OS patches and the application stack inside the VM.

Taking a taxi (App Engine / PaaS) is like telling a driver "take me to Taipei 101." You don't pick the model of the car, you don't drive, and you don't refuel. You only specify the destination (your application code). The driver (App Engine) figures out which car to use, how fast to go, and which roads to take. You pay per ride.

Calling an Uber per minute (Cloud Run / Cloud Functions) is even more on-demand. You only pay while you're inside the car. The moment you arrive, the meter stops — this is scale-to-zero. If a million people call Uber at the same New Year's Eve moment, the network spawns a million simultaneous rides. You don't see the cars when nobody calls; they don't cost you a cent. This is exactly how Cloud Run scales request-driven HTTP workloads.

Analogy 2 — Cooking Yourself vs Central Kitchen vs Food Delivery vs Buffet

You need to feed 1,000 customers every day for your business. How do you handle the kitchen?

Cooking it yourself in your own kitchen (on-premises) means buying ovens, hiring chefs, maintaining ventilation, and handling food safety inspections. Everything is on you.

Using a Central Kitchen with rented equipment (Compute Engine) is like leasing industrial-grade ovens and stoves. The building and electricity are provided, but you still hire the chefs, design the menu, and decide how much to cook. If a chef quits or an oven breaks, you replace it.

Using a Central Kitchen with standardized stations (GKE / containers) is the modern restaurant chain model. Each "station" is a container — a pre-packaged dumpling line, a noodle station, a drink bar. The kitchen manager (Kubernetes) decides how many stations to open based on customer demand, replaces broken stations automatically, and routes orders to the right station. You don't deal with individual ovens any more, you deal with stations.

Ordering food delivery on demand (Cloud Run) means you don't operate a kitchen at all. When a customer orders, a delivery rider picks up exactly that order from a network of restaurants. If no one orders for an hour, you pay nothing. When a thousand orders come in at lunch, a thousand riders mobilize. This is stateless, request-driven, scale-to-zero serverless.

Self-service buffet (App Engine Standard) is the curated PaaS experience. The vendor controls the menu (supported runtimes: Python, Java, Node.js, Go, PHP, Ruby), the stations, and the layout. Customers (developers) just show up with their plate (source code) and pick what they need. Super fast, very opinionated.

Analogy 3 — Building a House vs Apartment vs Hotel vs Airbnb

You need a place for your application to live.

Building a house from scratch on a plot of land (on-premises) is the traditional data center. You own the land, you pour the concrete, you wire the electricity, you fix the roof.

Renting an apartment (Compute Engine) is IaaS. The building (data center) is managed by Google. You get a unit (VM), pick your size (machine type — e2-medium, n2-standard-4), decorate it (install your OS and apps), and pay monthly rent. You can keep it for years. You also handle pest control inside your unit (OS patching).

Staying in a hotel (App Engine / GKE Autopilot) is PaaS-flavored. You show up with a suitcase (your code). The hotel provides housekeeping, electricity, breakfast, security. You don't worry about plumbing or wiring. You pay per night, and if you're not staying, you don't pay.

Booking an Airbnb per night (Cloud Run / Cloud Functions) is the most flexible. You pay only for the exact nights you stay. If you cancel last minute, no charge. If you need a room for one hour to host a meeting, you can find that too. This is event-driven, pay-per-execution serverless. Cloud Functions takes it further — you don't even rent a whole place, you just rent a meeting room for the 30 seconds you actually use it.

Compute Engine (IaaS) — Full Control VMs

Compute Engine is Google Cloud's flagship IaaS product. It provides Linux and Windows virtual machines running on Google's global infrastructure. You pick the machine family, the size, the disk, the operating system image, and the network configuration — then you SSH in and install whatever you want.

Machine Families on Compute Engine

Google Cloud groups Compute Engine VMs into machine families optimized for different workloads:

• General-purpose (E2, N2, N2D, N4): Balanced CPU and memory for web servers, small databases, dev/test, and most everyday workloads. E2 is cost-optimized; N4 is the latest performance generation.
• Compute-optimized (C2, C3, C4): High clock speed and CPU performance for gaming servers, HPC simulations, and CPU-bound batch jobs.
• Memory-optimized (M1, M2, M3): Large RAM-to-CPU ratios for in-memory databases like SAP HANA, large Redis caches, or high-performance analytics.
• Accelerator-optimized (A2, A3, G2): VMs with attached NVIDIA GPUs (T4, L4, A100, H100) or Cloud TPUs for AI/ML training and inference.
• Storage-optimized (Z3): Local SSD-heavy nodes for high-IOPS workloads.

Preemptible and Spot VMs

For fault-tolerant batch workloads, Google offers Spot VMs (previously called Preemptible VMs). Spot VMs cost 60–91% less than standard VMs but Google can reclaim them with a 30-second warning at any time. They are perfect for video transcoding, scientific computing, or large-scale batch analytics where you can checkpoint and resume.

When to Pick Compute Engine

• Lift-and-shift migrations: Legacy applications that cannot be containerized — they expect specific OS versions, kernel modules, or licensed software.
• GPU workloads: AI training, 3D rendering, scientific simulation. These almost always run on Compute Engine A3/G2 VMs because they need direct GPU access.
• Custom kernel or networking: Applications that need raw socket access, custom routing, or specific Linux kernel modules.
• Long-running, predictable workloads: Use committed use discounts (CUDs) for 1- or 3-year commitments and save 20–60%.

Google Kubernetes Engine (GKE) — Orchestrated Containers

Google Kubernetes Engine (GKE) is Google's managed Kubernetes service. Kubernetes itself was invented at Google (based on the internal "Borg" system) and donated to the Cloud Native Computing Foundation. GKE runs Kubernetes for you, handling control-plane upgrades, node provisioning, and integration with the rest of Google Cloud.

Standard vs Autopilot

GKE comes in two flavors:

• GKE Standard: You manage the node pools (the VMs that run your containers). You pick node sizes, autoscaling rules, and version upgrades. You pay for the nodes whether they're busy or idle.
• GKE Autopilot: Google manages the nodes for you. You only specify the workload (Pod definitions), and Google decides what VMs to provision behind the scenes. You pay per pod-second of vCPU and memory — much closer to a serverless billing model.

When to Pick GKE

• Microservices architecture: Dozens or hundreds of small services that need to talk to each other, with rolling deployments, service discovery, and traffic management.
• Multi-cloud or hybrid: Kubernetes is portable, so the same manifests work on GKE, on-prem with GKE Enterprise, or on AWS / Azure.
• Stateful workloads with strong orchestration needs: Databases with custom replication, queue systems, or stream processors where Kubernetes operators provide the lifecycle automation.
• Existing Kubernetes expertise: Teams that already know kubectl, Helm, and operators will be productive immediately.

Cloud Run — Serverless Containers

Cloud Run runs your container image as a serverless service. You build a Docker container, push it to Artifact Registry, and Cloud Run handles everything else: HTTPS endpoints, load balancing, autoscaling from zero to thousands of instances in seconds, and traffic splitting for canary releases.

Key Properties of Cloud Run

• Scale-to-zero: When no traffic arrives, instances spin down to zero and you pay nothing.
• Per-request billing: You are charged only for the CPU and memory used while serving requests, rounded to the nearest 100 milliseconds.
• Stateless by default: Each request is independent; durable state belongs in Cloud SQL, Firestore, or Cloud Storage.
• Any language, any library: As long as it runs in a Linux container and listens on $PORT, Cloud Run will run it.

Cloud Run Services vs Jobs

• Cloud Run services handle HTTP, gRPC, or WebSocket requests — typical web apps, APIs, and webhooks.
• Cloud Run jobs run batch tasks to completion (e.g., a nightly database export). No HTTP listener required.

When to Pick Cloud Run

• Stateless web apps and APIs: Especially with bursty traffic patterns.
• Internal microservices: Replace small GKE deployments without the cluster overhead.
• Webhooks and event handlers: Pub/Sub push subscriptions, GitHub webhooks, Stripe callbacks.
• Anything you can put in a container: Including Python ML inference, Node.js APIs, or Go binaries.

App Engine and Cloud Functions — PaaS and FaaS

App Engine

App Engine is Google Cloud's original PaaS, launched in 2008. You upload source code in supported languages (Python, Java, Node.js, Go, PHP, Ruby, .NET) and App Engine handles everything else — runtime, scaling, load balancing, even versioning and traffic splitting for blue-green deployments.

App Engine comes in two variants:

• App Engine Standard: Highly opinionated runtimes, very fast scale-up (milliseconds), scale-to-zero. Best for typical web apps in supported languages.
• App Engine Flexible: Runs your app inside a Docker container on Compute Engine VMs. Slower scale-up (minutes), no scale-to-zero, but supports any language or custom dependency.

Cloud Functions

Cloud Functions (the FaaS service, now also delivered through Cloud Run functions) runs a single function in response to an event. Triggers include:

• HTTP requests
• Pub/Sub messages
• Cloud Storage object events (new file uploaded, file deleted)
• Firestore document changes
• Cloud Scheduler cron jobs

You write a function, deploy it, and Google handles the rest. Functions scale from zero to thousands of concurrent executions automatically.

When to Pick App Engine vs Cloud Functions vs Cloud Run

• App Engine Standard: Traditional monolithic or small-service web apps where you want zero ops and don't need a custom container.
• Cloud Functions: Event-driven "glue code" — resize an image when uploaded, send a notification when a row is inserted, run a nightly cleanup at 3 AM.
• Cloud Run: Containerized workloads that need full language flexibility, longer request durations (up to 60 minutes), or larger memory.

Decision Framework: Choosing the Right Compute Option

Google publishes an official "Choosing a compute option" guide at https://cloud.google.com/docs/choosing-a-compute-option, and the CDL exam expects you to reason through similar trade-offs. Here is the simplified framework:

Step 1 — Do You Need Full OS Control?

• Yes (custom kernel, GPUs, legacy binaries, license-locked software): Use Compute Engine.
• No: Continue.

Step 2 — Is the Workload Containerized?

• Yes, with complex orchestration needs (microservices, stateful sets): Use GKE (Autopilot preferred).
• Yes, stateless HTTP service: Use Cloud Run.
• No, just source code: Continue.

Step 3 — Is It Event-Driven or Request-Driven?

• Event-driven, single-purpose function: Use Cloud Functions.
• Full web app with multiple endpoints: Use App Engine or Cloud Run.

Step 4 — Do You Need Scale-to-Zero?

• Yes: Choose Cloud Run, Cloud Functions, or App Engine Standard.
• No (steady workload): Compute Engine with committed use discounts is the cheapest.

Autoscaling Across Compute Options

Autoscaling is the ability of a compute platform to automatically add or remove capacity based on load. Every Google Cloud compute option supports some form of autoscaling, but the mechanics differ.

• Compute Engine: Managed Instance Groups (MIGs) scale VMs based on CPU utilization, load balancer requests per second, or custom metrics. Scale-up takes 30–90 seconds (boot time).
• GKE: Horizontal Pod Autoscaler (HPA) scales pods based on CPU/memory or custom metrics. Cluster Autoscaler scales the underlying nodes. Scale-up is faster than Compute Engine because containers boot in seconds.
• Cloud Run: Scales based on concurrent requests per instance (default 80). Scale-up is sub-second. Scale-down (including to zero) is gradual to avoid cold starts.
• App Engine Standard: Scales based on request queue length and pending requests. Sub-second scale-up.
• Cloud Functions: Scales per-event. Each event triggers a function execution; concurrency is per-instance and can be tuned.

The general rule: the higher up the abstraction stack, the faster autoscaling responds, because there is less infrastructure to provision.

Pricing and Cost Optimization

Each compute option has a distinct pricing model. Understanding these models is critical for the Cost Optimization pillar of the Google Cloud Architecture Framework.

• Compute Engine: Per-second billing (1-minute minimum). Discounts: Sustained Use Discounts (SUDs) apply automatically for VMs running ≥ 25% of the month. Committed Use Discounts (CUDs) for 1- or 3-year terms. Spot VMs for fault-tolerant workloads.
• GKE Standard: Pay for the underlying nodes (Compute Engine pricing) plus a small cluster management fee.
• GKE Autopilot: Pay per pod-second of requested vCPU, memory, and ephemeral storage. No idle node cost.
• Cloud Run: Pay for CPU and memory used while serving requests (and optional always-allocated CPU). Per-100ms billing.
• App Engine Standard: Pay per instance-hour. Free tier includes 28 frontend instance hours per day.
• Cloud Functions: Pay per invocation + compute time + memory. Free tier of 2 million invocations per month.

For CDL questions about "minimizing waste when traffic is unpredictable," the answer is almost always a serverless option (Cloud Run, Cloud Functions, or App Engine Standard) because they scale to zero. For "predictable steady-state workload at the lowest cost," the answer is Compute Engine with committed use discounts.

How Compute Options Integrate with Other Google Cloud Services

No compute option exists in isolation. Each integrates with Google Cloud's wider ecosystem:

• Networking: All compute options can sit behind Cloud Load Balancing and Cloud CDN for global distribution.
• Identity: IAM controls who can deploy, manage, and invoke compute resources. Service accounts give workloads themselves the identity they need to access other Google Cloud services.
• Storage: Cloud Storage for objects, Cloud SQL for relational data, Firestore and Spanner for NoSQL and globally consistent data, BigQuery for analytics.
• Messaging: Pub/Sub for asynchronous events that trigger Cloud Functions or Cloud Run.
• Observability: Cloud Logging and Cloud Monitoring automatically capture metrics and logs from every compute service.
• CI/CD: Cloud Build builds container images and deploys to any compute target. Artifact Registry stores those images.

This integration is part of the cloud value proposition: by choosing Google Cloud compute, you also get a fully integrated platform without having to wire components together yourself. Read more about this in /en/certs/gcp/cdl/topics/cloud-value-proposition.

Migration Paths: From VMs to Containers to Serverless

Many enterprises follow a modernization journey across compute options:

1. Lift-and-shift to Compute Engine: Move existing on-prem VMs as-is to Compute Engine. Fast migration, minimal code change. Tools: Migrate to Virtual Machines (formerly Migrate for Compute Engine).
2. Containerize the app: Package the application into a Docker container. Run it on GKE for orchestration or Cloud Run for serverless simplicity.
3. Decompose into microservices: Split monoliths into small services, deploy each as a Cloud Run service or GKE workload. Use Pub/Sub for async communication.
4. Extract glue code to Cloud Functions: Periodic jobs, event handlers, and integrations move to Cloud Functions for zero-ops execution.

Each step reduces operational overhead and increases agility, but also requires more refactoring. CDL exam questions about "modernization strategies" expect you to recognize this progression. For deeper context on the VM-to-container shift, see /en/certs/gcp/cdl/topics/containers-vs-vms.

Cost Governance for Compute Workloads

A common CDL question: "How does a business prevent compute costs from spiraling out of control?" Google Cloud provides several governance tools:

• Budgets and budget alerts in the Billing console notify finance teams when spending crosses thresholds.
• Quotas cap the maximum compute resources a project can consume.
• Labels tag VMs, GKE workloads, and Cloud Run services with cost centers and environments for chargeback and showback reports.
• Recommender suggests rightsizing opportunities — under-utilized VMs that can be downsized, or idle instances that can be deleted.

For a deeper treatment of these tools, see /en/certs/gcp/cdl/topics/cloud-financial-governance.

Frequently Asked Questions

Q: Which Google Cloud compute option should a startup with no traffic yet choose?

A: Cloud Run. It scales to zero, so the bill is essentially zero until customers arrive. It supports any language packaged in a container. As the startup grows, Cloud Run can handle hundreds of thousands of requests per second, and if microservices complexity emerges, the same container images can move to GKE Autopilot with minimal effort.

Q: Can I run a Windows application on Cloud Run?

A: Not in the typical sense — Cloud Run runs Linux containers. For Windows workloads (e.g., legacy .NET Framework apps that need Windows Server), use Compute Engine with a Windows Server image. Modern .NET (Core / 6+) apps run fine on Cloud Run as Linux containers.

Q: What's the difference between GKE Standard and GKE Autopilot?

A: GKE Standard gives you full control of node pools — you pick machine types, manage autoscaling, and pay for nodes whether busy or idle. GKE Autopilot has Google manage the nodes for you, billing per pod-second of requested resources. Autopilot is the recommended default for new workloads; Standard is for cases that need fine-grained node control (e.g., custom kernels or specific machine types).

Q: Is App Engine being deprecated in favor of Cloud Run?

A: No. App Engine remains a fully supported PaaS option, and many production apps still run on it. However, Google's strategic direction is Cloud Run for new serverless workloads because it offers more flexibility (any container, any language) while still scaling to zero. App Engine Standard remains attractive for teams that prefer a source-code-only deployment experience.

Q: When should I use Cloud Functions instead of Cloud Run?

A: Use Cloud Functions when the workload is a single-purpose, event-driven function — for example, "resize an image when uploaded to Cloud Storage" or "send a Slack alert when a Pub/Sub message arrives." Use Cloud Run when you have a full web application, multiple endpoints, longer request durations, or need fine control over the container image. The latest generation of Cloud Functions (Cloud Run functions) actually runs on the Cloud Run platform, so the line is blurring.

Q: Do I need to know Kubernetes for the CDL exam?

A: Not at the technical level — you won't be asked to write YAML or kubectl commands. But you should recognize what Kubernetes does (container orchestration, autoscaling, service discovery) and when GKE is the right answer (microservices, multi-cloud portability, complex orchestration needs).

Summary

Google Cloud offers a full spectrum of compute options spanning IaaS, CaaS, PaaS, and FaaS:

• Compute Engine (IaaS): Full-control VMs with machine families, GPUs, and Spot pricing. Best for lift-and-shift, GPU workloads, and OS-level customization.
• GKE (CaaS): Managed Kubernetes for containerized microservices. Autopilot mode minimizes operational overhead.
• Cloud Run (Serverless containers): Stateless HTTP services with scale-to-zero, any language, any container.
• App Engine (PaaS): Source-code deployment with managed runtimes. Standard mode scales to zero.
• Cloud Functions (FaaS): Event-driven functions with per-invocation billing.

The right choice depends on business priorities: full control vs minimal ops, predictable cost vs scale-to-zero, custom OS vs managed runtime. As a Cloud Digital Leader, your job is to map each business scenario to the right service and articulate the trade-offs to stakeholders. Master this framework and you will confidently answer any compute-related question on the CDL exam.