How would you decide between Cloud Functions, Cloud Run, and GKE for a new workload, beyond just 'serverless is simpler'?

Cloud Functions fits small, single-purpose, event-driven units of work (a single trigger, a single focused task). Cloud Run fits containerized applications wanting serverless operational simplicity without that single-function constraint — a full multi-route web service or worker. GKE fits workloads needing genuine infrastructure-level control, continuous operation without a cold-start trade-off, or Kubernetes-specific ecosystem capabilities. The sensible default is starting with the simplest platform that fits and migrating up only as real complexity or scale demands it, not starting with GKE's full complexity by default.

The three options sit on a spectrum of abstraction versus control, and the right choice follows from the workload's actual requirements — event-driven simplicity, containerized flexibility with serverless operations, or genuine infrastructure control — not from a general preference for "simpler is better."

• The workload's actual triggering pattern (event-driven, HTTP, always-on) needs to match what each platform is actually designed for.
• The team's operational capacity and desired level of infrastructure control should inform the choice, not be an afterthought.
• The decision should account for genuine cost/scaling behavior differences between the three, not just initial development convenience.

Cloud Functions fits genuinely small, single-purpose, event-driven units of work: a function reacting to a Pub/Sub message, a Cloud Storage event, or a simple HTTP request, doing one focused thing — Cloud Functions' deployment model (a single function, a single trigger) is purpose-built for this granularity, and forcing a larger, multi-endpoint application into this model fights against how it's designed to be used.

Cloud Run fits containerized applications wanting serverless operational simplicity without Cloud Functions' single-function granularity constraint: any application packaged as a container (a full web service with multiple routes, a background worker, anything you can containerize) runs on Cloud Run with the same serverless benefits (scale to zero, pay-per-use, no cluster to manage) as Cloud Functions, but without being constrained to a single-function-single-trigger model — this is the right fit for "I want serverless operations, but my application is more than one small function."

GKE fits workloads needing genuine infrastructure control or capabilities the serverless platforms don't provide: fine-grained control over networking (custom CNI behavior, specific node-level configuration), workloads needing to run continuously without the scale-to-zero cold-start trade-off being acceptable, complex multi-service architectures benefiting from Kubernetes' broader ecosystem (service mesh, custom operators, StatefulSets for genuinely stateful workloads with complex identity requirements) — GKE trades operational simplicity for this control and flexibility.

Cost/scaling behavior differs meaningfully between the three, and matters for the actual decision: Cloud Functions and Cloud Run both scale to zero and charge per-use, which is cost-efficient for genuinely intermittent workloads but means paying the cold-start cost when scaling from zero; GKE nodes run continuously (unless using GKE Autopilot's more serverless-like billing, or careful cluster autoscaling down to a genuine minimum), which is more cost-efficient for consistently high, steady traffic but means paying for capacity even during low-traffic periods unless carefully managed.

A common, sensible progression is Cloud Functions → Cloud Run → GKE as complexity/scale genuinely grows: a small, event-driven task starts as a Cloud Function; if it grows into a multi-endpoint service or needs more flexibility than a single function provides, migrating to Cloud Run (same container, same serverless operational model, more architectural freedom) is a natural next step; only once genuine infrastructure-level control or Kubernetes-specific capabilities are needed does GKE become the right answer — starting with GKE for a workload that would be perfectly served by Cloud Functions is usually taking on unnecessary operational complexity upfront.

Starting with the simplest platform that fits (Cloud Functions or Cloud Run) and migrating up only when genuinely needed avoids premature operational complexity, but does mean a potential migration effort later if the workload's needs outgrow the simpler platform — this is generally the better trade than starting with GKE's full complexity for a workload that doesn't yet need it, since the migration effort (when and if it's actually needed) is usually smaller than the ongoing cost of unnecessary Kubernetes operational overhead from day one.

• Cloud Functions fits small, single-purpose, event-driven units of work — its deployment model is built for this specific granularity.
• Cloud Run fits containerized applications wanting serverless operational simplicity without Cloud Functions' single-function constraint.
• GKE fits workloads needing genuine infrastructure control, continuous operation without cold-start trade-offs, or Kubernetes-specific ecosystem capabilities.
• A common, sensible pattern is starting with the simplest platform that fits and migrating up (Cloud Functions → Cloud Run → GKE) only as genuine complexity or scale requirements emerge.

• Google Cloud: Choosing a compute option
• Google Cloud: Cloud Run documentation