What is serverless?

Serverless computing is a paradigm shift in application development that enables developers to focus on writing code without worrying about infrastructure. It offers a variety of benefits over traditional computing, including zero server management, no up-front provisioning, auto-scaling, and paying only for the resources used. These advantages make serverless ideal for use cases like stateless HTTP applications, web, mobile, IoT backends, batch and stream data processing, chatbots, and more.

GCP serverless compute portfolio

Serverless Functions & events

Cloud Functions

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.

Cloud Run

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 a GKE add-on.

Which serverless compute platform is right for you?

Use cases

Web applications

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.

Mobile backends

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.

APIs

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.

Periodic operations

Cloud Scheduler can send scheduled HTTP requests to trigger operations on a defined schedule. It can also target App Engine specifically or HTTP endpoints like Cloud Functions and Cloud Run.

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 on GKE allows you to easily run your serverless and stateful workloads together.
For example, you can deploy MongoDB from the Marketplace into your GKE cluster to use as a document
store for your serverless workloads. GKE gives you the flexibility to run anything in your cluster,
and you can use Cloud Run to deploy serverless workloads alongside.

Advanced tips and best practices

Here are some additional factors you may want to consider.

Partially-autoscaling architectures

If your architecture contains components that are not autoscaled or serverless,
autoscaled ones can overload these components. You can use a Cloud Pub/Sub topic and
set the max_instances property in Cloud Functions to queue calls to non-autoscaled components.

Free usage + billing limits

Many GCP products have a free tier that covers most if
not all of the resource usage for lightweight low-traffic applications. You can easily use Cloud Functions to configure billing limits.

By design, Cloud Functions only handles one request per instance, ensuring each request
has the full amount of compute and memory allocated to it. This may make rapid scaling slower
with Cloud Functions, but App Engine standard environment, Cloud Run, and Cloud Run on GKE can handle multiple
concurrent requests per instance. This means these services can scale faster by handling more traffic per
instance, but all requests in an instance must share resources.

Workload portability

Cloud Run is compatible with the Knative open-source API and runtime environment. This allows you
to move serverless workloads across Cloud Run, Cloud Run on GKE, or your own Kubernetes cluster.
You can even start running your workloads on Cloud Run and move to using Cloud Run on GKE, if you need
specific GKE features such as custom machine types or access to VPC.