Choosing Between GKE and Cloud Run

Paul Durivage
Google Cloud - Community
3 min readFeb 8, 2022

So, you’ve written an app. And, like many developers writing apps in the A.D. (After Docker) epoch, you crammed all that code in a container. Now you’re left asking yourself: how should I deploy this to GCP?

There’s a number of ways to run a containerized workload on GCP: on a Google Compute Engine (GCE) instance, possibly backed by a managed instance group (MIG); App Engine Flex; on Cloud Run, a managed service for running containers; or — perhaps most complex of all — on a Google Kubernetes Engine (GKE) cluster.

For the purposes of this blog post, let’s remove from consideration two (almost-legacy-but-still-pretty-good) options: App Engine and GCE. Now we’re laser-focused on the two remaining services where most engineers have trouble making a choice: GKE and Cloud Run. So how does one choose?

No Bad Choices

Allow me a moment to opine about the reality of architectural choices, as it’s relevant here.

There’s no bad choices–at least no bad choices remaining. We’ve already removed a couple from our list for good reasons: AppEngine due to the higher level of boilerplate and necessary structure, and partially due to its limited support for programming languages and versions (despite having support for a custom runtime environment); and GCE, a bit of a legacy choice, which avoids the complexity of considering/maintaining the operating system of a VM and the components and configuration required to scale like using instance groups.

In most circumstances the distinct benefits and tradeoffs of guides us through the decision-making process, and that’s certainly the case here: GKE and Cloud Run are great, production-ready services for running containerized apps. We must simply evaluate them on their merits.

Let’s start by defining the requirements for our application. For example:

  • What is the container’s operating system?
  • How many containers comprise my application?
  • What are the application’s CPU and memory requirements?
  • Is the application stateless or stateful (with regard to the underlying runtime environment)?
  • Is the application event-based?
  • Does the application respond to events synchronously or asynchronously?
  • What kind of events will the application handle?
  • Do I want a managed service?

If you can answer the above questions, picking a runtime is pretty easy! In this case, the process of choosing is made simpler by the fact that there is one service that is considerably more limited than the other, restricting the possible number of use cases it can support.

Cloud Run

While it’s a drop-dead simple managed service for running a container, it is the more limited platform–that is, it supports the narrowest set of use cases, and is therefore a great place to begin an evaluation. Generally speaking, Cloud Run tends to be really useful for synchronous, event-driven applications and microservices. The canonical example of a synchronous, event-driven application is web application, but Cloud Run also supports asynchronous events from services like Cloud Tasks. Cloud Run allows applications to be invoked by many different triggers, like HTTP, gRPC, websockets, Eventarc, Pub/Sub, Cloud Scheduler, and Cloud Tasks.

GKE

GKE is essentially managed, cloud-native Kubernetes, a runtime and orchestration engine for containers, capable of coordinating the deployment of containerized workloads and their resources. While Kubernetes is extremely capable, it is also complex. Kubernetes clusters are typically comprised of many nodes for both the control plane and workloads, and as such, running a single-container workload on something as large and complex as Kubernetes is probably overkill.

It’s worth mentioning that the complexity of managing GKE has been mitigated to some extent: GKE with Autopilot moves towards an automated scale-on-demand model, automatically adding and removing nodes based on the requested resources of a given workload, making it similar to Cloud Run. However, even with Autopilot, one must still write Kubernetes manifests to deploy to GKE with Autopilot.

Decision Matrix

For simple use cases, this decision tree may assist you in choosing between Cloud Run and GKE but, before you decide, you should definitely read up on the container runtime contract. You may also find Google’s brief and concise Is my app a good fit for Cloud Run? documentation page to be quite useful.

Update Aug 2022: Cloud Run can now support up to 8 vCPUs and 32 GB of memory.

Update Nov 2023: Cloud Run supports up to 10 containers in a single service using the sidecar pattern.

--

--

Paul Durivage
Google Cloud - Community

Sometimes I sit in silence. Sometimes I solve problems with 1s and 0s.