Cloud Run functions
Cloud Run functions is a fully managed, serverless functions-as-a-service (FaaS) platform: you write a single-purpose function, Google builds the container, and it runs with no infrastructure to provision or servers to manage. A function is glue - a connective layer of logic that reacts to an event or an HTTP request and extends other cloud services. It scales automatically and is integrated with Cloud Observability for logging and diagnosis.
Two generations
Setting up a function
Two types of functions
- HTTP functions handle HTTP(S) requests.
- Event-driven functions handle events from your cloud environment.
HTTP functions
Use an HTTP trigger when you want to invoke a function with an HTTP(S) request. The function is assigned a URL and runs in response to requests to it - a good fit for a webhook or API that handles requests from other services.
To implement one, you write an HTTP handler and register it with the Functions Framework for your language. The handler accepts the request and response arguments, processes the request based on its method, and sends back an HTTP response.
Requests to HTTP functions require authentication by default - you can choose to allow unauthenticated requests at deploy time. Any background tasks the function creates (threads, processes, Promise objects) must be terminated before the response is sent.
Event-driven functions
Use an event-driven function when it should be invoked automatically in response to an event in your cloud environment. Event triggers are supported for Pub/Sub, Cloud Storage, Firestore, Firebase, and Eventarc sources, plus any Google Cloud service that supports Pub/Sub as an event bus. The exact sources available depend on whether the function is Cloud Run functions or 1st gen. For how each trigger is wired to a service, see the event triggers overview.
You implement an event-driven function as a CloudEvent function or a Background function, depending on your language runtime and generation:
What the 2nd generation adds
Because 2nd-gen functions run on Cloud Run, they gain its scale and rollout controls:
The exact limits behind those features:
- Instances with up to 32 GB of RAM and 4 vCPUs.
- Up to 1000 concurrent requests per instance - fewer cold starts and lower latency when scaling.
- Run-time limit up to 60 minutes for HTTP functions and up to 10 minutes for event-driven functions.
- A new revision on every deploy - split traffic between revisions or roll back to a prior one.
- Eventarc triggers from 90+ Google, external SaaS, and custom sources (by publishing to Pub/Sub).
- Standardized CloudEvents format to simplify event-handling code.
- Portable: move the function to Cloud Run or Kubernetes.
Features & benefits
- Seamless authentication uses service accounts; integration covers Cloud SQL, Bigtable, Spanner, and Firestore.
- Serverless means Google manages the software and infrastructure - no servers, framework updates, or OS patching - and autoscaling goes from a few invocations a day to millions with no extra work.
- Pay-as-you-go cost is based on the number of invocations, compute time, and outbound data-transfer fees.
Use cases
Language runtimes & source structure
You can develop functions in Node.js, Python, Go, Java, .NET, Ruby, or PHP (specific supported versions are in the Cloud Run functions documentation). Each runtime has required source-layout rules so the platform can locate your function definition:
- Node.js - loads source from
index.jsat the function root by default; set themainfield inpackage.jsonto change it.package.jsonalso declares the Functions Framework and any dependencies. - Python - loads from
main.pyat the root;requirements.txtdeclares the Functions Framework and dependencies. - Go - your function must be in a Go package at the project root;
go.moddeclares the Functions Framework.
Entry point
The entry point is the code executed when the function is invoked. It must be defined in your main file or root package, is a function or a class depending on the language, and is specified when you deploy the function.
Regions
The infrastructure that runs a function is in a specific region, managed by Google to be redundantly available across all zones within that region. Choose a region by latency and availability - generally the one closest to the function's users, while also considering where the other Google Cloud services your app uses are located, since spanning locations affects latency and pricing.
Cloud Run functions 1st generation has different regional availability from 2nd gen - confirm your target region supports the generation you're deploying.