Google Cloud offers five distinct kinds of compute — Cloud Functions, App Engine, Cloud Run, Google Kubernetes Engine (GKE), and Compute Engine — arranged on a spectrum from most abstracted to least abstracted. Cloud Functions hide almost everything (you supply one function; Google runs it), while Compute Engine hands you a raw virtual machine and full responsibility for the OS, scaling, and networking. Cloud Run, GKE, and App Engine sit between those extremes, trading management overhead for control. Billing follows the same spectrum: usage-based at the abstract end (Functions, App Engine), resource-based at the concrete end (GKE, Compute Engine), with Cloud Run as a pay-per-request hybrid that scales to zero.
That's the summary an AI Overview would hand you. Here's what it can't show you: the actual decision boundaries — the specific signals ("I have a container and only HTTP traffic," "I need a sidecar," "I need a persistent local disk") that push a workload onto one service instead of another. Below is a side-by-side comparison table, a decision matrix, and a decision-flow diagram so you can place your own workload instead of memorizing five feature lists.
The 5 Compute Types at a Glance
| Compute type | Abstraction | Deploy unit | Billing | Scales to zero | Best for |
|---|---|---|---|---|---|
| Cloud Functions | Highest | A single function | Per invocation + runtime | Yes | Event glue, webhooks, ETL snippets |
| App Engine | High | App code (chosen runtime) | Per usage (min instances) | No (min kept warm) | Managed web apps, versioning + traffic splitting |
| Cloud Run | Medium-high | A container | Per request + CPU/mem used | Yes | Stateless HTTP containers, APIs, microservices |
| GKE (Kubernetes) | Medium | Containers in pods | Per node resources (Autopilot: per pod) | Node pools no (Autopilot pods yes) | Multi-service systems, sidecars, non-HTTP, CI/CD |
| Compute Engine | Lowest | A virtual machine | Per provisioned vCPU/RAM/disk | No | Lift-and-shift, databases, GPUs, special licensing |
Which should I use? If you have a container and only serve HTTP, start with Cloud Run. If you have many coordinated services or need Kubernetes primitives, use GKE. If you have a single event-triggered snippet, use Cloud Functions. If your app can't be containerized or needs a full OS, use Compute Engine. App Engine is the "managed web platform" middle path most new projects now skip in favor of Cloud Run.
Decision Matrix: Match the Signal to the Service
| If your workload… | …then use | …because |
|---|---|---|
| Is one function fired by an event (HTTP, Pub/Sub, Storage) | Cloud Functions | Zero infra, pay per invocation, scales to zero |
| Is a stateless container serving HTTP/S | Cloud Run | Serverless containers, scale to zero, SSL included |
| Needs sidecars, StatefulSets, or non-HTTP protocols | GKE | Full Kubernetes control and networking |
| Runs many services that must coordinate in one cluster | GKE | Shared cluster, service mesh, cluster autoscaling |
| Is an existing web app you want managed with versioning | App Engine | Traffic splitting + versioned deploys, no container build |
| Can't be containerized / needs a full OS | Compute Engine | Raw VM, any OS, any protocol |
| Needs persistent local disk (e.g. a database) | Compute Engine | Durable attached disks, resize without reboot |
| Needs GPUs or very large memory | Compute Engine | Customizable hardware up to thousands of vCPUs / TBs RAM |
| Is fault-tolerant batch you can restart cheaply | Compute Engine (Spot VMs) | 60–91% discount, reclaimable anytime |
Abstraction Levels
Before we go further, let's talk a bit about abstraction levels. Abstraction deals with ideas instead of events. To put this in the context of today's article, abstraction means that you focus more on running your application and less on how it is being executed.
The greater the abstraction, the less you have to worry about the environment and underlying infrastructure. And the more you can focus on the code you have written.
💡 The different types of compute in order of levels of abstraction:
-
Cloud Functions
-
App Engine
-
Cloud Run
-
Kubernetes
-
Compute Engine
As you start at the top of the list and move your way towards the bottom of the list, you get different levels of abstraction. If you want the most abstraction, you will want to use cloud functions. And if you want the least amount of abstraction, you will want to use Compute Engine.
Billing
In the previous section, we talked about how different types of compute give you different levels of abstraction. Cloud functions give you the highest level of abstraction. Each kind of compute also has other ways of handling billing.
Cloud functions and App Engine are billed based on usage. Meaning, each time you access the function/app, that counts as a request. You are then billed based on the number of requests.
Compute and Kubernetes are both billed based on resource utilization. Meaning you pay for CPU, Memory, and Storage usage.
Cloud run is a combination of these two billing models. We get into more detail about that when we get to the cloud run section.
📊 Billing types for each compute type:
-
Cloud Functions – usage
-
App Engine – usage
-
Cloud Run – usage/Resources
-
Kubernetes – Resources
-
Compute Engine – Resources
Compute Engine (Virtual Machines)
Compute Engine gives you virtual machines. This means you have a full operating system with full access to the CPU and Memory. And you have the greatest flexibility of what to run within your virtual machine.
Compute Engine is used by Google for building a lot of Google services. For example: Cloud SQL, GKE, Dataflow, Dataproc, Cloud Build, etc…
Things you should be thinking about
Compute instances are the lowest level of abstraction, so you are responsible for everything related to this machine. This includes, but is not limited to:
-
Your software
-
Operating system
-
CPU, RAM, Disk
-
Networking: Firewall loadbalancing, etc..
When to use Compute Engine
Compute Engine is the lowest level of abstraction. This means you have the most flexibility. But you also have the most management overhead. For these reasons, you should only use the Compute Engine if your application can't fit into the other compute models.
There are two primary reasons to use Compute Engine:
-
An existing application that does not run in a container
-
Special hardware/Software requirements
Compute Engine machines give you a lot of flexibility as far as hardware and software go. You can build machines with up to 160 vCPUs and 12 TB of memory. You can include GPUs. And you can install any operating system you want.
Good Fit When:
-
Existing system
-
Require 1:1 container VM mapping
-
Special Licensing requirements
-
Running databases
-
Require network protocols beyond HTTP/s
Benefits:
-
Good number of pre-built images
-
Can run whatever OS you want
-
Can run whatever applications you want
-
Hardware highly customizable
-
Can resize disks without rebooting
Machine Types
If you need to use Compute Engine to run virtual machines, it is good to know about the two different machine types:
Standard: Google's standard SLA (99.95% uptime)
Pre-emptible / Spot: Deep discount for interruptible workloads. Note: the older preemptible VM (max 24-hour lifetime) has been superseded by Spot VMs, which offer a 60–91% discount with no forced 24-hour restart — Google can reclaim them anytime capacity is needed, but they can otherwise run indefinitely. Use them for fault-tolerant, restartable batch and CI jobs.
Kubernetes (GKE)
GKE is Google's managed Kubernetes service. With a few clicks, Google will spin-up a Kubernetes master for you, then provision one or more compute instances with the Kubernetes agent on it. Once your Kubernetes cluster is live, you can start running your containers on it.
Containers are a newer technology that allows developers to ship applications that are ready to run without additional dependencies. This technology allows the developer to run the container on their workstation, then run the application in production with high confidence that it will work as expected.
🏗️ Kubernetes Architecture – Three main components:
-
Node: Server with OS running Kubernetes agents and Docker
-
Pod: Logical unit with its own IP address running containers
-
Container: Your sandboxed application
Every node contains at least one pod, and every pod contains at least one container. Every node can contain multiple pods, and every pod can contain multiple containers. However, a given pod will never have more than one copy of a given container.
Benefits:
-
Cluster autoscaling
-
Google manages master node
-
Cluster ready in ~5 minutes
-
High node utilization
-
Good abstraction compromise
Good Fit For:
-
Multiple environments
-
Full container advantage
-
CI/CD pipelines
-
Beyond HTTP/S protocols
Cloud Run
Cloud Run is a fairly new compute type on Google Cloud. You can think of Cloud Run as a combination of Kubernetes and Cloud Functions. It allows you to take a container and deploy it as easily as you could deploy a cloud function.
Once your container is created and set up in the registry, it just takes a few clicks to deploy that container as a Cloud Run application. Once the application is done deploying, you are given a URL for accessing that application.
Benefits:
-
Serverless agility for containers
-
Autoscaling to 0 nodes
-
SSL Termination included
-
Pay only what you use
-
No language/framework limits
Limitations:
-
Must run in container
-
Only HTTP/S requests
-
No persistent storage
-
Application must be stateless
Fully Managed vs Kubernetes
There are two ways to run your containers on Cloud Run. There is the regular way that runs as fully managed. Or, you can run your containers on your existing Kubernetes cluster.
By running your containers on your Kubernetes cluster, your application has the ability to access your private IP address space. This will allow your Cloud run application to be accessible by applications that cannot communicate over the internet.
Cloud Functions
Cloud functions are similar to Lambda on AWS. They are event-driven and run a set piece of code every time it is invoked. Cloud functions are my favorite kind of compute – I prefer to use them anywhere I can.
With Cloud functions, you pay per execution of the function. You do not pay for runtime. This makes them very cost-effective to use for many tasks. Many environments can use cloud functions for no charge.
Benefits:
-
Truly serverless
-
Great for ETL/transactions
-
Can glue systems via HTTP
-
Pay only for what you use
-
Auto-scales infinitely
Limitations:
-
Limited languages
-
Must interact via events
-
Can't lift & shift easily
-
Rewrite required for existing apps
Google App Engine
Google App Engine has been around longer than Google cloud has been around. It is a service for deploying serverless applications with minimal effort. In terms of layers of abstraction, it falls between Cloud Run and Cloud Functions.
When deploying your app engine application, you start by selecting the runtime you want to use (Node.js or Python), load your application code, press go, and your application is deployed. In terms of level of effort, it is pretty close to Cloud functions.
Benefits:
-
Autoscaling
-
Application versioning
-
Traffic splitting
-
No servers to manage
-
Optimized for web workloads
Constraints:
-
Limited languages (PHP, Go, Node, Python, Java)
-
Docker constraints in Flexible mode
-
Not best for very low traffic
-
Always keeps a minimum nodes running
3 Different Execution Environments
There are three versions of App Engine:
Standard: Legacy version, has been around the longest
2nd Generation Standard: Runs within containers (Recommended)
Flexible: Runs on full virtual machines
Recommended to run in 2nd generation standard unless you need specific VM sizes (Flexible) or have legacy code (Standard). App Engine is not as well-suited for extremely low-traffic applications as other compute types like Cloud Functions or Cloud Run because it always keeps a minimum number of nodes running.
Why Choose App Engine?
App Engine is optimized for web applications and allows developers to focus on code rather than infrastructure management. Key reasons to choose App Engine:
-
Developers focus on code
-
Optimized for web workloads
-
Great for variable workload
-
Built-in services and integrations
Summary
We've discussed the five primary types of compute on Google Cloud. Each type of compute targets a different level of abstraction and has its benefits and drawbacks.
In my opinion, Google Kubernetes Engine gives you the best mix of flexibility versus manageability. You get to customize the individual nodes that run your containers, but Kubernetes handles all the provisioning, scaling, etc for you.
💡 Key Takeaway: There is no right or wrong place to run your applications. Rather you have to weigh the benefits and drawbacks of each compute type and choose what works best for your environment and your application.