Google Cloud Compute
Google Cloud compute services run applications as virtual machines, Kubernetes workloads, managed containers, or queued jobs. You choose how much infrastructure control to keep and how much operation to hand to Google.
itCloud computing | OpenSkills.info
Course pathWalk it in order
Look it upDip in anytime
Go furtherLeaves this page
Intro
Google Cloud Compute
Google Cloud compute is not one product. It is a set of execution models. You can operate virtual machines, schedule Kubernetes workloads, run managed containers, or submit finite work to a job queue.
Start with the workload, not the product name. Ask what must run, how it starts, how long it lives, how it scales, and which infrastructure controls you need.
Compute Engine gives you virtual machines and operating system control. Google Kubernetes Engine, or GKE, gives you managed Kubernetes. Cloud Run runs code or containers on a managed application platform. Batch queues tasks and provisions the compute needed to finish them.
Each step toward a more managed service removes some infrastructure work. It also narrows the execution contract. The best choice is the least operational surface that still meets the workload's requirements.
Choose the execution model
Use Compute Engine when the workload needs operating system or kernel control, a specific machine shape, attached accelerators, custom images, or software that expects a virtual machine.
Use GKE when Kubernetes is a requirement. GKE manages the Kubernetes control plane. Autopilot also manages worker nodes. Standard mode leaves more node and cluster configuration with you.
Use Cloud Run when an application can fit its managed container contract. A Cloud Run service handles requests or events through a managed endpoint. A Cloud Run job runs tasks to completion. A worker pool runs continuous non-HTTP background work.
Use Batch when work is finite, queueable, and described as one or more tasks. Batch provisions and removes Compute Engine resources for the job. It favors scheduled throughput over an interactive request path.
These choices can work together. A public service might run on Cloud Run while a data-processing stage uses Batch. A GKE application can call services on other Google Cloud products. A Compute Engine fleet can sit behind Cloud Load Balancing.
Continue the course
This section is part of the paid course.
See pricing to subscribe, or log in if you already have access.
Where this skill leads
Relevant careers
See how this topic contributes to broader role-level skill maps.
Sources
- https://docs.cloud.google.com/docs/compute-area/choose-compute-options
Supports
- Google Cloud compute selection begins with workload requirements and the required level of operating system control, orchestration, and scaling
- Compute Engine provides self-managed operating system control, GKE provides Kubernetes, Cloud Run provides serverless managed execution, and Batch provides job-queue orchestration
- https://docs.cloud.google.com/compute/docs/overview
Supports
- Compute Engine is an infrastructure service with self-managed virtual machine and bare metal instances
- Compute Engine supports Linux and Windows operating systems, durable storage, and management through console, command line, API, and client libraries
- https://docs.cloud.google.com/compute/docs/regions-zones
Supports
- Zones are deployment areas within regions
- Resource location and scope affect availability and failure design
- https://docs.cloud.google.com/compute/docs/disks
Supports
- Compute Engine offers durable network block storage and local disk choices with different persistence, replication, and performance behavior
- Disk placement and backup behavior must match the workload's durability requirement
- https://docs.cloud.google.com/compute/docs/instance-groups
Supports
- Managed instance groups create and maintain matching VMs from an instance template
- Managed instance groups support autohealing, autoscaling, regional multi-zone deployment, and automatic updates
- Unmanaged instance groups do not provide the same automated fleet services
- https://docs.cloud.google.com/compute/docs/autoscaler
Supports
- A managed instance group autoscaler adds VMs when load grows and removes VMs when demand falls
- Autoscaling behavior is defined by the group's autoscaling policy
- https://docs.cloud.google.com/load-balancing/docs/load-balancing-overview
Supports
- Cloud Load Balancing distributes traffic across multiple application instances
- Google Cloud offers application and network load balancers with internal, external, regional, and global scopes
- Load balancers route traffic to healthy backends
- https://docs.cloud.google.com/compute/docs/access/service-accounts
Supports
- A service account is an identity used by an application or compute workload
- Applications on VMs can use attached service account credentials without embedded secret keys
- Google recommends a user-managed service account with only the required IAM roles
- https://docs.cloud.google.com/compute/docs/instances/spot
Supports
- Spot VMs use excess Compute Engine capacity at lower prices
- Compute Engine can reclaim Spot VMs at any time
- Spot VMs fit fault-tolerant workloads that can withstand preemption
- https://docs.cloud.google.com/kubernetes-engine/docs/concepts/kubernetes-engine-overview
Supports
- GKE is a managed implementation of Kubernetes for containerized applications
- Google manages the Kubernetes control plane
- Autopilot manages worker nodes while Standard provides more infrastructure control
- Kubernetes workloads run as Pods on cluster nodes
- https://docs.cloud.google.com/kubernetes-engine/docs/concepts/autopilot-overview
Supports
- Autopilot is a managed GKE operating mode focused on workloads
- Google manages nodes, scaling, security, and other infrastructure settings in Autopilot
- https://docs.cloud.google.com/run/docs/overview/what-is-cloud-run
Supports
- Cloud Run is a managed application platform for code, functions, and containers
- Cloud Run provides service, job, and worker-pool resource types
- Cloud Run services handle requests and events, jobs run tasks to completion, and worker pools handle continuous non-HTTP work
- Cloud Run container instances are disposable and their writable file systems are not durable
- Cloud Run supports revisions, traffic rollout, scaling, service identity, and Google Cloud integrations
- https://docs.cloud.google.com/batch/docs/get-started
Supports
- Batch schedules, queues, and executes finite processing workloads
- A Batch job contains tasks and runnables plus the resources needed to execute them
- Batch provisions and removes Compute Engine resources for jobs
- https://docs.cloud.google.com/monitoring/docs/monitoring-overview
Supports
- Cloud Monitoring provides metrics, dashboards, alerting, and integrations for Google Cloud resources and applications
- Compute Engine application metrics and logs can be collected through the Ops Agent
- https://docs.cloud.google.com/monitoring/agent/ops-agent
Supports
- The Ops Agent is the primary telemetry agent for Compute Engine instances
- The Ops Agent collects logs, metrics, and traces
- https://github.com/GoogleCloudPlatform/awesome-google-cloud
Supports
- The fetched list includes Functions Framework, Online Boutique, Bank of Anthos, and Awesome Cloud Run as compute ecosystem resources
- Functions Framework is described as an open source set of libraries for portable Google Cloud functions
- Online Boutique is described as a multilingual microservices sample running on GKE
- Bank of Anthos is described as a GKE sample integrating several Google Cloud products
- https://github.com/steren/awesome-cloud-run
Supports
- The fetched list curates Cloud Run documentation, quickstarts, interactive tutorials, samples, languages, tools, and deployment resources