Cloud Functions supports several methods of running your functions outside of Cloud Functions itself. This is particularly useful for iterative development, and for situations where you want to test your function before deploying.
The ability to run your functions outside of Cloud Functions itself can be useful for several different use cases, such as local testing environments, data locality restriction compliance, and multi-cloud deployments.
Many development paradigms depend on being able to test your code relatively quickly.
Because testing code on Cloud Functions itself involves waiting for deployed code and log entries to become available, running and testing your function on your development machine can make the testing process (and, in turn, the development process) significantly faster.
Data locality restrictions
In some cases, regulations or policies may require data to be kept within a certain geographical, organizational, and/or network boundary that may not be accessible to Cloud Functions itself.
If a platform that complies with your data locality restrictions is compatible with one of Cloud Functions' abstraction layers, you can run your functions directly on that platform atop one of these layers.
Multi-cloud function deployments are an established pattern to mitigate downtime risk in reliability-critical environments. Deploying functions to environments other than Cloud Functions itself reduces the risk of your application experiencing unplanned downtime.
Before you can set up your own function hosting environment, there are two key choices you will need to make:
- Which layer of abstraction you want to use.
- Which type of function you will be running.
Cloud Functions itself uses a multi-layer architecture, much of which has been open-sourced. These open-source components allow you to run code designed for Cloud Functions on other platforms.
Two primary open-source components of this architecture that can be run outside of Cloud Functions itself are the Function Frameworks and buildpacks. This document explains the purpose of each of these layers and how they fit together.
The diagram below shows the typical layout of function deployments atop Cloud Functions, Cloud Run, and other container-based platforms:
Cloud Functions has three main types of functions:
HTTP functions can be triggered by arbitrary HTTP requests such as webhooks, whereas background functions and CloudEvent functions receive events produced by other Google Cloud Platform products.
While HTTP functions are supported by all Cloud Functions runtimes, this is not the case for CloudEvent Functions and background functions. These two function types are both triggered by any first-party event, but have different function signatures and event structures. Ruby and .NET only support CloudEvents functions, while Node.js, Python, Java, and Go only support background functions.
Choosing an abstraction layer
Function Frameworks are open-source libraries used within Cloud Functions to unmarshal incoming HTTP requests into language-specific function invocations. You can use these to convert your function into a locally-runnable HTTP service.
Cloud Native buildpacks are used to wrap HTTP services created by the Function Frameworks and build them into runnable Docker containers, which then run on Cloud Functions' container-based architecture.
Both options have advantages and disadvantages:
- Functions Frameworks-based environments often have lower resource needs
- Functions Frameworks do not require underlying containerization software (such as Docker)
- Functions Frameworks-based environments require underlying language infrastructure (such as package managers and language runtimes)
In general, we recommend using Functions Frameworks unless portability and/or containerization are specifically desired.
Running Functions Locally
Both Function Frameworks and buildpacks work by forwarding HTTP requests to your function. See Running Function Frameworks for more information on how to call locally running functions.