Cloud Functions vs. Cloud Run: when to use one over the other
Jaisen Mathai
Group Product Manager, Google Cloud
Sara Ford
Senior Developer Relations Engineer
Embracing serverless architectures help you bring solutions to market faster at lower cost with decreased management overhead than traditional approaches. Cloud Functions and Cloud Run are two such serverless compute products from Google Cloud, and customers often ask us “when does it make more sense to use Cloud Functions or Cloud Run?”
Commerzbank AG is one such customer, and has developed a framework for helping to decide where to deploy and how to manage their serverless workloads. “We employ cloud-native services to benefit from their scalability, security, and serverless nature in order to deliver a future-proof and business centric foundation,” said Christian Gorke, Head of Cyber Center of Excellence, Big Data & Advanced Analytics at Commerzbank AG. “While each service comes with its own benefits, we mix and match those to fulfill our business needs.”
In general, we find that serverless workloads tend to fall into one of two categories: connecting your platform or running services. Connecting your platform typically involves writing discrete pieces of code that perform a single task and that benefit from simplicity. On the other hand, running services benefit from the flexibility of custom server configuration and the ability to perform multiple tasks.
In this post, we’ll provide an overview of Cloud Functions and Cloud Run and provide a framework to help you pick the best option for your workload.
Choosing a serverless product
Both Cloud Functions and Cloud Run can scale from zero to meet incredibly high demand. But there are trade-offs between the two in terms of simplicity and flexibility.
If you’re using a serverless product to connect your platform, you likely don’t need to configure a container to control the web server or language runtime. In this case, Cloud Functions manages this configuration on your behalf, letting you focus on what’s core to your business. Running services, on the other hand, requires more control of the container including choosing the web server or language runtime. For this use case, Cloud Run provides the flexibility needed for these configurations while managing the rest on your behalf.
Connecting your platform with Cloud Functions
Cloud Functions makes connecting your platform simple to build and easy to maintain — you’re just responsible for the code. Anyone on your team with coding knowledge can create a solution without having to package up the code. You can also choose from seven popular languages. Data scientists, for example, can get a python script running in the cloud with limited infrastructure knowledge.
Cloud Functions keeps productivity high and operations low by making each function its own independent component, isolating it from directly impacting other workloads. Changes and updates to one function are unlikely to impact another function.
We leverage Cloud Functions to process short-lived, event-based actions triggered from other systems such as Cloud Storage, Eventarc, or PubSub, e.g., for data pipeline automation.
Commerzbank AG
A common use case for Cloud Functions is responding when an object is added to a Cloud Storage bucket. The function might generate thumbnails of an image or run sentiment analysis on a text file. But there are many other examples for which customers choose Cloud Functions:
Transforming data and loading it into BigQuery
Creating a webhook that’s called by a third party (i.e., GitHub)
Use ML APIs to analyze data added to a database or storage bucket
Running services with Cloud Run
Cloud Run simplifies scaling and maintaining services by utilizing industry-standard containers. You can leverage existing tools and knowledge to package and deploy your service on Cloud Run, and let us manage the runtime infrastructure to host and scale it.
Cloud Run works well for a broad range of applications. It lets you deploy your service with a single containerized app. You can use any language, library, or binary to run your application. And Google handles server management and scalability for you, even for containerized legacy workloads such as three-tier Java applications.
Cloud Run comes into play when further customization is required, e.g., when embedding AI models or serving multiple interfaces for a longer period of time is required.
Commerzbank AG
A good candidate for Cloud Run is an eCommerce website that lists products for sale. But there are many other examples of applications for which you could choose Cloud Run:
Any web-based workload
REST or gRPC APIs for mobile apps or games
Internal custom backoffice apps
Using Cloud Functions and Cloud Run together
Cloud Functions and Cloud Run can be complimentary in a multi-workload landscape.
Combining both services boosts our productivity considerably since application teams can focus on business code instead of infrastructure and its dependencies, which is conveniently covered by Google Cloud.
Commerzbank AG
These are general guidelines for customers looking for the best product for their workload but we believe there are many factors to consider. You may want to leverage your team’s existing tools and expertise. Or you may have a specific set of Google Cloud products which have been approved for use.
Because the second generation of Cloud Functions is built on the enhanced infrastructure of Cloud Run, the decision of which product to use doesn't need to be a cause for analysis-paralysis. You can be immediately productive by writing simple code and deploying it quickly to Cloud Functions, and evolving it into a more complex web service later, by migrating it to Cloud Run, whose extra control is very easy to unlock.
We believe it's useful to consider these factors when choosing a serverless product. Doing so will help you deploy your workloads with the right balance of simplicity and flexibility, so you can deliver a solution quickly that’s easy to maintain and scale. To get started with serverless on Google Cloud try this Cloud Run quickstart or Cloud Functions codelab.