Compute Engine, GKE, Cloud Run and Multicloud Products: Business Value of Google Cloud Infrastructure (Cloud Digital Leader)

Google Cloud's infrastructure offerings give an organization four ways to run applications, each trading control for less operations work: Compute Engine virtual machines, Google Kubernetes Engine (GKE) for containers on Kubernetes, Cloud Run for containers without servers, and Cloud Run functions for small pieces of event-driven code. A fifth group of products extends Google Cloud beyond its own regions into other clouds and customer data centers.

The more of the stack Google runs, the less the customer manages and the more closely cost follows real usage. The more of the stack the customer keeps, the more it can control, which matters for applications that cannot change.

Definitions of virtual machines, containers, serverless computing and autoscaling, and the migration terms rehost, replatform, refactor and reimagine, belong to task 4.1 of the exam guide. This lesson focuses on the business value of each product and on choosing between them.

Compute Engine lets an organization create and run virtual machines (VMs) on Google's infrastructure, so it can rent computing capacity on demand instead of buying, housing and maintaining its own servers. Its business value comes from three things.

• A fast, low-risk path to the cloud. A VM runs an operating system of the customer's choice, such as Linux or Windows Server, so an existing application can move without code changes. This is the usual home for a rehost (lift-and-shift) migration and for software that is licensed to, or certified on, a particular operating system.
• Control. The customer chooses the machine size, the OS and everything installed on it. Predefined and custom machine types let it match CPU and memory to the workload.
• Spending that follows use. Instead of a large up-front hardware purchase (capital expenditure), the organization pays for VM capacity while it runs (operating expenditure) and can resize, add or remove VMs as demand changes.

The trade-off is responsibility. Under the shared responsibility model, Google secures the hardware and the virtualization layer, and the customer looks after the guest operating system and everything installed on it. VMs are billed while they run, so it is autoscaling, schedules and the right pricing option that align Compute Engine cost with demand.

Compute Engine cost is optimized by matching each part of the demand to the right pricing or scaling option. The exam expects you to recognise which lever fits which usage pattern.

The levers combine. A common pattern is to commit to the steady baseline that runs all year and let an autoscaled managed instance group add on-demand VMs for spikes. Managed instance groups can also recreate VMs that fail health checks (autohealing), which supports availability.

Compute Engine has other options for specific needs. Sole-tenant nodes are physical servers whose VMs all belong to one customer, which helps with per-core software licensing and with rules that require isolation from other customers. Custom machine types let you choose an exact combination of vCPUs and memory. Compute Engine also applies sustained use discounts automatically to some machine types that run for a large part of the month.

Modern application development is a way of building software, using flexible architectures and managed services, that lets an organization deliver changes faster, scale and recover better, and spend less effort and money on running infrastructure. The exam guide names five benefits.

• Flexible architectures such as microservices. A microservices application is split into small, independent services (for example search, recommendations, payments), each built, deployed and scaled on its own. A monolith is one program deployed as a single unit, so every team waits for one joint release.
• Accelerated deployment through managed services. When Google runs the platform, teams spend their time building features. Pairing a managed platform with an automated build-and-release pipeline (continuous integration and delivery) is what makes frequent, small, low-risk releases routine.
• Cost optimization. Each service scales separately, and serverless services cost little or nothing when idle, so capacity is not bought for the busiest feature everywhere.
• Enhanced scalability and resilience. A busy service, such as search during a holiday, scales out by itself. A fault in one service stays in that service instead of taking down the whole application.
• Improved operational efficiency. Google takes over routine work such as patching, backups, capacity planning and hardware failures.

Managed services follow the shared responsibility model: they move infrastructure work to Google, while the application itself, its data and who can reach it remain the customer's to look after. In return for that convenience, the customer accepts Google's choices about the underlying platform, and pricing usually stays usage-based.

Google Kubernetes Engine (GKE) is Google's managed Kubernetes service for deploying, managing and scaling containerized applications, so an organization gets Kubernetes without installing or operating the Kubernetes control plane itself. Kubernetes is the open-source system that schedules and runs containers across a cluster of machines.

• Less operations work. Google runs the control plane and can upgrade clusters automatically. Node auto-repair replaces unhealthy machines. Installing, securing and upgrading Kubernetes is specialist work, and GKE removes most of it.
• Portability. GKE runs open-source Kubernetes, so the same containers and Kubernetes configurations can run on other Kubernetes environments, on premises or on other clouds. This reduces the risk of lock-in to one provider.
• Kubernetes features at scale. GKE suits organizations with many containerized services, or workloads that rely on Kubernetes-specific features such as custom operators.

As with any managed service, the split of responsibility still applies: Google runs Kubernetes, and what runs inside the containers is the customer's own work.

Autopilot and Standard modes

GKE has two modes of operation. In Autopilot mode, Google also manages the nodes (sizing, patching and scaling them) and by default you pay for the CPU, memory and storage your running pods request rather than for whole nodes (some specialized hardware classes, such as GPUs, are billed per node). In Standard mode, you create and size node pools yourself and pay for the nodes, which gives more control over the machines. Choose Autopilot when you want Kubernetes with the least operations work; choose Standard when you need control over node configuration.

Serverless computing means the customer deploys code or a container and Google provisions, scales and manages all the servers, so the organization pays for actual use and has no infrastructure to operate. Google Cloud's serverless compute products are Cloud Run and Cloud Run functions.

Cloud Run

Cloud Run is a fully managed platform that runs any container, in any language and with any system libraries, without servers or clusters to manage. It scales automatically with incoming requests, including down to zero instances when nobody is using the service, and you are billed for the resources used. The business value is:

• Cost that follows demand. A service is billed for the requests it handles, so long quiet periods cost little or nothing, and a sudden surge is absorbed without capacity planning.
• Language freedom. Anything that can be packaged in a container can run, whatever its language, framework or system libraries.
• Focus on code. With no servers or clusters to run, developers spend their time on the application.

Cloud Run functions

Cloud Run functions (formerly Cloud Functions) run a short, single-purpose piece of code in response to an event, such as a file landing in Cloud Storage, a Pub/Sub message or an HTTP call. You write only the function, in a supported language runtime; Google packages and runs it, and it scales to zero between events. Typical uses are glue tasks between services: reacting to a new file, transforming a message or calling another system when something changes.

App Engine is Google's older serverless application platform. Its standard environment runs code in a set of supported language runtimes, whereas Cloud Run accepts any container image.

The right compute platform is the one that meets the workload's hard constraints with the least operations work and cost. Read the scenario for the deciding facts first, then pick.

An organization does not have to choose one platform for everything. Each workload is placed by its own constraints, so a single company commonly uses all three, and the mix changes as applications are modernized.

Other infrastructure options exist for special cases. Bare Metal Solution provides dedicated physical servers in facilities close to Google Cloud regions, for specialized workloads, such as some licensed enterprise databases, that need hardware rather than VMs.

Several Google Cloud products run on, or work across, other clouds and customer data centers, so an organization can use Google's technology where its data and applications already are. The exam guide's examples are AlloyDB Omni, BigQuery Omni, GKE Enterprise, Cloud SQL and Looker.

Similar names, different jobs

Several of these products share a name with a Google Cloud service, and each does a different job.

Product names change. Google folded the GKE Enterprise edition into standard GKE in 2025, so its multicloud and fleet features are now simply part of GKE, although the exam guide still uses the old name. GKE on AWS is in maintenance mode, so for clusters already running on other clouds, such as Amazon EKS or Azure AKS, the current route is to register them as attached clusters in a fleet.

Together, these offerings let an organization move quickly first and modernize at its own pace, paying only for what each workload needs. A typical journey looks like this:

1. Exit the data center by rehosting unchangeable applications on Compute Engine, using committed use discounts for steady servers and autoscaling for variable ones.
2. Modernize suitable applications into containers and microservices, running Kubernetes-dependent services on GKE and simple request-driven services on Cloud Run.
3. Automate builds and releases on managed platforms so teams release more often with less risk.
4. Extend to wherever the data lives, with BigQuery Omni, AlloyDB Omni, Looker, GKE fleets and Google Distributed Cloud for multicloud, hybrid and edge needs.

APIs and Apigee, which connect these modernized services to partners and customers, are covered in task 4.3.