Comparing Google Cloud Serverless Compute platforms

Cloud providers are abstracting away the concept of a server: meet serverless. Instead of spinning up a bunch of servers, you just deploy your code or container image and the platform will spin up the required resources. But there are quite a few options when using Google Cloud.

Wietse Venema, writer of the book Mastering Serverless Applications with Google Cloud Run, created a nice architectural overview of all the serverless compute options.

It explains the layers of Googles Compute offerings from the infrastructure up to the running code. But if you have no idea what these services are, this overview might confuse you even more. How does Cloud Run compare to App Engine Flex for example? And what is the difference between Cloud Run for Anthos and Cloud Run? To answer these questions I created a quick overview of these platforms that will outline the use cases, benefits and limitations of these serverless compute offerings. Hope this helps when deciding between the various solutions.

TL;DR: Decision tree to choose a Serverless Compute platform

Google provides an overview on when to choose which serverless platform. But unfortunately the overview is not complete. I’ve extended it with some extra requirements like HTTP streaming support and support for scale to zero. This image should provide enough information to help you choosing a solution.

Below I will go more in depth into the various serverless compute offerings of GCP. I will explain the benefits and drawbacks of each solution, what the solution actually provides and what the ideal use cases are.

Cloud Run: serverless containers

If you just want to run a container that listens on an HTTP endpoint and serves requests, Google Cloud Run does just that. Cloud Run does not build the container for you, that’s something you have to do yourself. Cloud Run only takes care of scaling your container when requests come in, and scales it down again when there is no traffic. Cloud Run implements the Knative API specification, but runs on Google’s own infrastructure instead of a Kubernetes cluster. More details on the implementation can be found in this blogpost by Ahmet Alp Balkan.

Cloud Run is ideal when you just want to a container that listens on an HTTP endpoint or a Pub/Sub topic, and you want to keep control over the underlying runtime. You don’t have to manage the server, configure a Kubernetes cluster or create auto scalers. Cloud Run takes care of that.

Overview

Typical use casesSimple web applications, batch jobs (> 15 minutes), machine learning jobs
InputContainer image
TriggerHTTP endpoint or Cloud Pub/Sub topic
Warm up time~ 2 seconds
Benefits
  • Usage based pricing (scale to zero)
  • Easy auto-scaling
  • Portability: runs any container
  • No infrastructure management (GKE still requires some maintenance)
Drawbacks

Cloud Run still has some compatibility issues with other Google Cloud services. Please check this page for more details.

Cloud Run for Anthos: serverless containers (sort of…)

If you already have a Kubernetes cluster (GKE) or if you need to use custom hardware, then it’s possible to install Cloud Run for Anthos on your Kubernetes cluster. This will add the serverless functionality of Knative to your cluster: scale to zero and auto-scaling. You will get the same benefits as with Google Cloud Run, with the additional benefit of support for HTTP/2 and HTTP streaming. If that’s a requirement for your application, then Cloud Run for Anthos is your only option.

Overview

Typical use casesSimple web applications, batch jobs (> 15 minutes), machine learning jobs
InputContainer image
TriggerHTTP endpoint or Cloud Pub/Sub topic
Warm up time~ 2 seconds
Benefits
  • Scale to zero functionality
  • Easy auto-scaling
  • Portability: runs any container
  • Supports HTTP streaming (websockets)
  • Supports HTTP/2 and gRPC
  • Runs on top of your Kubernetes platform (on-premise or GKE)
Drawbacks
  • You still need a pipeline to go from code to container image (you could leverage Google Cloud Build and Google Container Registry (GCR))
  • You need to manage the underlying Kubernetes cluster yourself (even GKE needs configuration and updates)

Cloud Functions: serverless functions

For single purpose workloads, running a complete container might be overkill. Especially if it’s event driven. Deploying a Cloud Function could be a better fit. Cloud Functions are single functions that can be triggered by an HTTP request or a Pub/Sub message. You just provide the function, the platform does the rest: packaging, deploying and running your code. When requests come in, it will automatically scale up and back to zero again. Functions can be an attractive tool for automating business actions such as responding to hiring a new employee or adding a customer to a CRM database. These low frequency events don’t warrant hosting a full server nor keeping dependencies of several layers up-to-date. There are some limitations: your function needs to be written in either Python, NodeJS, Golang or Java.

Overview

Typical use casesMicro batch jobs (> 9 minutes), image transformations, streaming processing
InputCode (single purpose function)
Supported languagesPython, Java, Golang or Node.js
TriggerHTTP endpoint, Cloud Pub/Sub topic, Cloud Storage bucket or Firebase event
Warm up time

~ 2 seconds (more details in this excellent blogpost)

Benefits
  • Packaging and deployment is done for you
  • Scale to zero functionality
  • Easy auto-scaling
Drawbacks
  • Only suitable for short running jobs (maximum duration is 9 minutes)
  • Does not support HTTP streaming (websockets)
  • Does not support HTTP/2 and gRPC

App Engine Standard: serverless applications

If you need a solution to go from code to running application without setting up a deployment pipeline, then App Engine might be the best solution. Google App Engine just takes your code and deploys it. You pay for what you use: it scales up automatically and back to zero when desired. There are a few limitations: it doesn’t support websockets, HTTP/2 and gRPC, and you need to write your code in one of the supported languages. If you need more flexibility, App Engine Flex might be a better solution.

Overview

Typical use cases
  • Simple webapps written in one of the supported languages
  • Fast prototyping
  • More complex API's with various routes
InputCode
Supported languagesSpecific versions of Node.js, Python, PHP, Ruby, Java and Go
TriggersHTTP endpoint
Warm up time> 500 ms (even faster with a resident instance)
Benefits
  • Packaging and deployment is done for you
  • Scale to zero functionality
  • Easy and rapid auto-scaling
Drawbacks
  • Doesn't support websockets
  • Doesn't support HTTP/2 and gRPC

App Engine Flexible: serverless applications with custom runtimes

If App Engine is compelling, but too limited in terms of supported runtime, App Engine Flexible might be a better choice. It has a few benefits: support for custom runtime using container images and support for websockets. It also supports background processes, because it doesn’t scale to zero. This could be a benefit or a drawback, depending on your requirements. Other drawbacks are slower deployment and scale up times. App Engine Flexible leverages Cloud Build to build a container using the provided container image and your code. That’s why it scales slower compared to App Engine Standard.

Overview

Typical use cases
  • Simple webapps written in any language
  • Fast prototyping
  • More complex API's with various routes
InputCode
Supported languagesAny language using a custom runtime (container image)
TriggersHTTP Endpoint
Warm up timeMinutes
Benefits
  • Packaging and deployment is done for you
  • Supports any language using custom container images
  • Easy but slower auto-scaling
  • Supports websockets
Drawbacks
  • Doesn't scale to zero (needs 1 instance minimum)
  • Scaling takes more time
  • Longer deployment and warm up time compared to App Engine
  • Doesn't support HTTP/2 and gRPC

Conclusion

If you build stateless applications, and you don’t want to manage the underlying infrastructure, the serverless solutions are quite compelling. Whether you want to quickly prototype an application, rapidly autoscale your application or perform taks in response to background events, serverless is your friend.

When making a choice between these offerings, keep these things in mind:

  • If you already have a CI/CD in place and package your code in containers, consider Cloud Run (for Anthos).
  • If you just want to run a simple function, and creating a container would be overkill, Cloud Functions is the best option.
  • If you don’t have a CI/CD in place, and you just want to develop and deploy your entire application, App Engine (Flex) is the go-to solution.
  • If you are building an application that uses HTTP/2 then Cloud Run for Anthos is your only option. But keep in mind that you need to have a Kubernetes cluster up and running.
  • If your use-case involves a few hundred or thousand requests per day, Cloud Run or Functions are fine. Millions of requests or more should utilize AppEngine, Kubernetes or Compute engine to avoid per-request charges driving up costs.

Good luck in choosing the right solution for your situation! If you need any help, you know where to find us :)

Back to blog