GCP serverless compute portfolio
Serverless Functions & events
An event-driven compute platform to easily connect and extend Google and third-party cloud services and build applications that scale from zero to planet scale.Learn more
Serverless http applications
App Engine standard environment
A fully managed serverless application platform for web and API backends. Use popular development languages without worrying about infrastructure management.Learn more
A serverless compute platform that enables you to run stateless containers invocable via HTTP requests. Cloud Run is available as a fully managed, pay-only-for-what-you-use platform and also as part of Anthos.Learn more
Which serverless compute platform is right for you?
* App Engine standard environment supports Node.js, Python, Java, Go, PHP
* Cloud Function supports Node.js, Python, Go
App Engine standard environment is good for minimal-ops web apps running in Node.js, Python, PHP, Java, and Go. Write your applications in a standard, idiomatic way using any language library. Fast deployment times and scaling responsiveness make the App Engine standard environment well suited for spiky workloads.
Asynchronous backend processing
Cloud Functions is for responding to data events in the cloud and lightweight processing like resizing an image uploaded to Cloud Storage or validating data when a value is modified in the Firestore database.
For traditional REST API backends for mobile applications, App Engine standard environment is an app platform that monitors, updates, and scales the hosting environment; all you need to do is write your mobile backend service code. Firebase provides a suite of powerful backend services that integrate directly into your mobile application: real-time NoSQL databases, authentication, hosting, file storage, and more. Firebase integrates with Cloud Functions so you can easily connect with the rest of your Google Cloud Platform services.
If you’re building a simple API (a small set of functions to be accessed via HTTP or Cloud Pub/Sub), we recommend using Cloud Functions. It is designed for bursty workloads, and its programming paradigm (functions) helps keep small-scale backend code well organized. For a more complex API (such as a REST API with many routes), we recommend using App Engine standard environment, as it may be easier to organize your many functions. If you depend on Cloud Endpoints for API management, we recommend using App Engine standard environment with Python 2.7 and Java 8 as it supports Cloud Endpoints.
Rapid prototyping and API stitching
For small-scale or “hackathon” projects that involve rapid prototyping and/or stitching together multiple APIs and services, we recommend using Cloud Functions. Its programming paradigm allows you to quickly develop both small-scale apps and/or “glue code” that stitches together existing APIs and services.
Running provider-agnostic containers
Docker containers are an industry standard and can run in any cloud or on-premises. Cloud Run can run containers in a serverless request-response fashion. We recommend using Cloud Run, unless you need custom hardware like GPUs or require a Kubernetes cluster, in which case you can run Cloud Run on GKE in your Google Kubernetes Engine cluster.
Combine serverless and stateful workloads
Cloud Run for Anthos allows you to easily run your serverless and stateful workloads together. For example, you can deploy MongoDB from the Marketplace into your Anthos GKE cluster to use as a document store for your serverless workloads. Anthos gives you the flexibility to run anything in your Kubernetes cluster, and you can use Cloud Run for Anthos to deploy serverless workloads alongside.
|App Engine standard environment||Cloud Functions||Cloud Run||Cloud Run for Anthos|
|Scale to zero||Pods2|
|Languages||Java, Node.js, Python, Go, PHP||Node.js, Python, Go||Any||Any|
|Access controls||Oauth 2.0, CICP, Firebase Authentication, Google Sign-In, Users API||Invoker IAM permission||Invoker IAM permission, CICP, Google Sign-In, Firebase Authentication||Cluster-only, VPC-only|
|HTTP/2 and gRPC|
|Request timeout||1 minute3||9 minutes||15 minutes||15 minutes|
|GPUs and TPUs|
|VPC connectivity||beta1||On roadmap|
1. Beta software has no SLA.
2. Cloud Run on GKE scales the number of pods to zero. The number of nodes per cluster cannot scale to zero, and these nodes are billed in the absence of requests.
3. Automatic scaling: 60-second deadline for HTTP requests.
Advanced tips and best practices
Here are some additional factors you may want to consider.