SkarpSkarp

Chapter 6 of 26

Planning Compute: Choosing Between Compute Engine, GKE, Cloud Run, and Cloud Functions

When a scenario demands "the right compute service," know exactly how to weigh VMs, Kubernetes, and serverless options for cost, control, and scalability.

27 min readen

The Compute Choice Mindset

Why Compute Choices Matter

As an Associate Cloud Engineer, you must decide where workloads run: VMs, Kubernetes, or serverless. This choice affects cost, control, scalability, and your day-to-day operations.

The Control Spectrum

Picture a spectrum: Compute Engine (max control), then GKE, then Cloud Run, then Cloud Functions (least infra control, most managed). Moving right reduces ops work but also reduces low-level control.

Trade-offs to Balance

For each workload, weigh control (OS, network), scalability, operations effort (patching, cluster tuning), and cost model (always-on vs pay-per-use). Billing and budgets help catch bad choices early.

What You Will Do

You will learn a decision framework, study each service, walk through realistic scenarios, and then lock in knowledge with flashcards, quizzes, and thought exercises.

A Simple Decision Framework

Question 1: Containers?

Ask: is this workload already containerized, or can it reasonably be containerized? If not, or if you need full OS control, Compute Engine is usually the first candidate.

Question 2: Long-running vs Event-driven

Long-running APIs and web apps suggest Compute Engine, GKE, or Cloud Run. Short, event-triggered logic (Pub/Sub, Storage) points to Cloud Functions or Cloud Run.

Question 3: Required Control

Need OS-level tweaks, special agents, or custom kernels? Choose Compute Engine. Need Kubernetes APIs and multi-service control? Choose GKE. Want minimal ops? Prefer Cloud Run or Cloud Functions.

Context: Team and Migration

For lift-and-shift migrations, Compute Engine often comes first. Kubernetes-experienced teams may choose GKE. New microservices or prototypes often go to Cloud Run or Cloud Functions.

Compute Engine: When You Need Virtual Machines

What is Compute Engine?

Compute Engine gives you virtual machines in Google Cloud. You pick machine types, disks, and OS, and you are responsible for OS-level management and configuration.

When is it the Best Fit?

Use Compute Engine for lift-and-shift migrations, legacy apps that cannot be containerized, custom OS images, and workloads needing GPUs, TPUs, or special agents.

Control vs Responsibility

You get full control: SSH access, kernel tuning, custom software. The cost is higher operations effort: patching, backing up, securing, and autoscaling your VMs.

Exam Clues for Compute Engine

Watch for phrases like lift-and-shift, custom images, legacy OS, specialized hardware, or non-HTTP protocols with tight OS requirements. These often point to Compute Engine.

GKE: Managed Kubernetes for Containerized Apps

What is GKE?

Google Kubernetes Engine is a managed Kubernetes service. You deploy containers as Kubernetes workloads, while Google manages much of the control plane for you.

When to Use GKE

Use GKE for containerized microservices needing Kubernetes APIs, multiple services in one cluster, sidecars, and advanced traffic management via Kubernetes objects.

Control and Operations

GKE offers high control over pods, node pools, and networking. You still handle cluster upgrades, autoscaling configs, and workload tuning, especially in Standard mode.

Exam Clues for GKE

Look for explicit mentions of Kubernetes, Helm, sidecars, multi-service meshes, or requirements for Kubernetes-specific features like ConfigMaps or StatefulSets.

Cloud Run: Serverless Containers

What is Cloud Run?

Cloud Run runs stateless containers on a fully managed serverless platform. You provide a container image; Google handles servers, scaling, and networking.

When to Use Cloud Run

Use Cloud Run for HTTP APIs, web apps, and background workers that are stateless per request and do not need full Kubernetes power but benefit from autoscaling.

Control and Scaling

You control the container and some settings (concurrency, memory, CPU), but not VMs or clusters. Cloud Run scales to zero when idle and up rapidly on traffic spikes.

Traffic Splitting

Cloud Run supports traffic splitting between revisions, enabling canary and gradual rollouts without complex Kubernetes or load balancer configuration.

Cloud Functions: Event-Driven Functions-as-a-Service

What is Cloud Functions?

Cloud Functions lets you deploy single-purpose functions that run in response to events or HTTP calls. Google manages servers, runtimes, and scaling for you.

Event-Driven Use Cases

Use Cloud Functions to react to events like file uploads, Pub/Sub messages, or database changes, and to glue together services with small pieces of code.

Control and Limitations

You cannot control OS or containers. You must use supported languages and versions; this keeps ops simple but limits flexibility compared to Cloud Run.

Cloud Functions vs Cloud Run

Prefer Cloud Functions for simple event-driven logic in supported languages. Prefer Cloud Run when you need custom containers, multiple processes, or more HTTP control.

Comparing the Four Options with Concrete Scenarios

Scenario 1: Legacy Windows App

A legacy Windows service needs a specific OS and custom drivers, and cannot be containerized. Best choice: Compute Engine with Windows images and possibly a custom image.

Scenario 2: Microservices Platform

An e-commerce site has many containerized microservices and a team already using Kubernetes. Best choice: GKE for Kubernetes APIs, sidecars, and advanced traffic control.

Scenario 3: Image Processing on Upload

On Cloud Storage upload, create thumbnails automatically. Best choice: Cloud Functions with a Storage trigger, or Cloud Run via Pub/Sub. For simple logic, exam usually favors Cloud Functions.

Scenario 4: Spiky HTTP API

A stateless REST API sees unpredictable spikes; the team wants minimal ops and pay-per-use. Best choice: Cloud Run, which runs a container, scales to zero, and auto-scales on traffic.

Thought Exercise: Map Requirements to Services

Work through this thought exercise to solidify your intuition. Do not worry about being perfect; focus on your reasoning.

Scenario A: Batch financial report generator

  • Once per day, a heavy batch job runs for 3 hours, crunching data from BigQuery and writing PDFs to Cloud Storage.
  • It needs a custom library that is hard to compile in Cloud Functions.
  • You want to minimize cost outside the 3-hour window.

Question: Which compute option would you choose, and why?

Think:

  • Could this be a container? If yes, Cloud Run or GKE might work.
  • Do you need Kubernetes APIs? Probably not.
  • Is it event-driven? Yes (scheduled), but long-running.

Scenario B: Real-time chat backend

  • A WebSocket-based chat service must maintain long-lived connections.
  • It needs low latency and fine-tuned connection handling.

Question: Which option fits best?

Think:

  • Cloud Functions and Cloud Run are optimized for request/response and stateless processing.
  • Long-lived connections often need more control over networking and timeouts.

Scenario C: Audit log enrichment

  • Every time a Pub/Sub message arrives with an audit event, you add metadata and store it in BigQuery.
  • Logic is simple, written in Python, and events can spike.

Question: Which option is the simplest fit?

Pause and decide your answers before moving on to the quiz, where you will see similar patterns.

Tip: For each scenario, explicitly ask yourself the three core questions from the decision framework: containerized?, long-running vs event-driven?, required control?

Quick Check: Match Workload to Compute Option

Test your ability to pick the right compute service from a short scenario.

Your company wants to migrate a Java monolith running on a specific Linux distribution with custom OS packages. There is no time to refactor or containerize yet, but you must move it to Google Cloud quickly. Which service is the best initial fit?

  1. Cloud Run
  2. Google Kubernetes Engine (GKE)
  3. Compute Engine
  4. Cloud Functions
Show Answer

Answer: C) Compute Engine

Compute Engine is the best fit for a fast lift-and-shift of a monolithic app that depends on a specific Linux distribution and custom OS packages. You can create a custom image and run the app on VMs. Cloud Run and Cloud Functions require containerization or function refactoring; GKE also assumes containers and adds unnecessary complexity for an unchanged monolith.

Quick Check: Event-Driven vs Long-Running

Another scenario to reinforce when to choose Cloud Functions vs Cloud Run vs others.

You need to run small pieces of Python code whenever a file is uploaded to a specific Cloud Storage bucket. The code resizes the image and writes the result back. You want minimal operational overhead and do not need a custom runtime. What should you use?

  1. Cloud Functions with a Cloud Storage trigger
  2. Cloud Run with a custom container and manual polling
  3. GKE with a Deployment and CronJob
  4. Compute Engine with a long-running daemon
Show Answer

Answer: A) Cloud Functions with a Cloud Storage trigger

Cloud Functions with a Cloud Storage trigger is designed exactly for this pattern: event-driven, simple logic in a supported language, with minimal operations. Cloud Run could work via Pub/Sub, but it requires more setup. GKE and Compute Engine introduce unnecessary operational complexity.

Key Terms and Service Characteristics

Flip through these cards to reinforce core concepts and exam-friendly phrasing.

Compute Engine – primary strength
Provides virtual machines with full OS-level control, ideal for lift-and-shift migrations, custom images, legacy apps, and workloads needing specialized hardware or deep OS customization.
GKE – primary strength
Managed Kubernetes for containerized workloads that need Kubernetes APIs, multi-service deployments, sidecars, and advanced traffic and deployment strategies.
Cloud Run – primary strength
Fully managed serverless platform for stateless containers, offering automatic scaling (including to zero), request-based billing, and minimal operational overhead.
Cloud Functions – primary strength
Event-driven Functions-as-a-Service for single-purpose functions triggered by HTTP, Pub/Sub, Cloud Storage, Firestore, and other events, with very low operational overhead.
Best fit: lift-and-shift with custom OS image
Compute Engine. It lets you create and run custom images with the exact OS and packages your legacy app requires.
Best fit: multiple microservices using Kubernetes APIs
GKE. It supports Deployments, Services, ConfigMaps, Secrets, and other Kubernetes features for multi-service architectures.
Best fit: stateless HTTP API with spiky traffic and minimal ops
Cloud Run. It runs your containerized API, scales automatically with traffic, and scales to zero when idle.
Best fit: react to Cloud Storage file uploads
Cloud Functions with a Cloud Storage trigger, if your logic fits within supported runtimes and simple function code.
Control vs operations: Compute Engine
Highest control and highest operations effort: you manage OS patching, capacity planning, and many security hardening tasks.
Control vs operations: Cloud Run and Cloud Functions
Lower control over infrastructure but very low operations effort; Google manages servers, scaling, and most runtime details.

Hands-On: Deploying the Same Container to Cloud Run and GKE (Conceptual)

To connect this to your earlier CLI module, here is a conceptual example of deploying the same containerized app to Cloud Run and to GKE using `gcloud`. You do not need to memorize every flag for the exam, but understanding the workflow helps you reason about the services.

Assume you have a simple container image `gcr.io/PROJECT_ID/hello-app`.

1. Deploy to Cloud Run (fully managed)

```bash

From Cloud Shell, with PROJECT_ID already set

Enable APIs (one-time per project)

gcloud services enable run.googleapis.com

Deploy to Cloud Run

gcloud run deploy hello-app \

--image gcr.io/$PROJECT_ID/hello-app \

--platform managed \

--region us-central1 \

--allow-unauthenticated

```

Key ideas:

  • You do not manage servers or clusters.
  • You specify region, image, and some runtime settings.

2. Deploy to GKE

```bash

Enable GKE API

gcloud services enable container.googleapis.com

Create a GKE Autopilot cluster

gcloud container clusters create-auto hello-cluster \

--region us-central1

Get cluster credentials

gcloud container clusters get-credentials hello-cluster \

--region us-central1

Create a Kubernetes Deployment and Service

cat <<EOF > deployment.yaml

apiVersion: apps/v1

kind: Deployment

metadata:

name: hello-app

spec:

replicas: 2

selector:

matchLabels:

app: hello-app

template:

metadata:

labels:

app: hello-app

spec:

containers:

  • name: hello-app

image: gcr.io/$PROJECT_ID/hello-app

ports:

  • containerPort: 8080

---

apiVersion: v1

kind: Service

metadata:

name: hello-service

spec:

type: LoadBalancer

selector:

app: hello-app

ports:

  • port: 80

targetPort: 8080

EOF

kubectl apply -f deployment.yaml

```

Key ideas:

  • You manage a cluster and use Kubernetes manifests.
  • You define replicas, Services, and other Kubernetes objects.

Reflect: both run the same container, but Cloud Run hides infrastructure, while GKE exposes Kubernetes control.

Pulling It Together and Next Steps in Your Path

The Spectrum Recap

Compute Engine: VMs and full OS control. GKE: managed Kubernetes for containers. Cloud Run: serverless containers. Cloud Functions: serverless event-driven functions.

Exam Keywords to Watch

Lift-and-shift or custom OS suggests Compute Engine. Kubernetes or sidecars suggests GKE. Stateless HTTP and autoscaling suggest Cloud Run. Event triggers suggest Cloud Functions.

Cost and Governance Link

Budgets and alerts help control costs, especially for always-on clusters and VMs. The Google Cloud pricing calculator helps compare options for expected workloads.

Your Next Skarp Steps

Use the diagnostic and mock exams to practice these choices. Your gap guide and spaced review will revisit whichever compute trade-offs you find hardest.

Key Terms

Cloud Run
A fully managed serverless compute platform on Google Cloud for running stateless containers that automatically scale based on incoming requests.
stateless
A property of an application where no client-specific state is stored on the server between requests; each request can be handled independently.
Kubernetes
An open-source container orchestration system for automating deployment, scaling, and management of containerized applications.
autoscaling
The ability of a system to automatically adjust the number of running instances or resources based on load or demand.
event-driven
An architecture where code is executed in response to events such as messages, file uploads, or HTTP requests.
Compute Engine
Google Cloud's Infrastructure-as-a-Service offering that provides virtual machines with full OS-level control, suitable for lift-and-shift migrations and custom images.
lift-and-shift
A migration approach where an application is moved to the cloud with minimal or no code changes, preserving its architecture and behavior.
Cloud Functions
An event-driven Functions-as-a-Service platform on Google Cloud for running single-purpose functions in response to events or HTTP requests.
traffic splitting
A deployment technique where incoming requests are divided between multiple versions of a service, often used for canary or gradual rollouts.
Google Kubernetes Engine (GKE)
A managed Kubernetes service on Google Cloud for running containerized applications using Kubernetes APIs and abstractions.

Finished reading?

Test your understanding with a custom practice exam on this chapter.

Test yourself