Cloud Run and a Decision Tree for your Serverless Needs!

Before I begin: Opinions in the blog are my own and derived from my interest and experience, not representing my employer, other company or anyone else.

Serverless allows developers to focus on the thing they like to do the most — development — and leave the rest of the attributes, including infrastructure and maintenance, to the platform offerings. However, there are always some concerns and questions around which serverless option to choose. All serverless platform offerings are exciting with their capabilities, like:

• No-infrastructure maintenance
• Usage-based pricing
• Auto-scaling capabilities

Cloud Run stands out of the league by enabling us to:

• Package code in multiple stateless containers that are request-aware and invoke it via HTTP requests or scheduled as non request driven jobs
• Only be charged for the exact resources you use
• Support any programming language or any operating system library of your choice, or any binary as long as you containerize it

Check this link for more of Cloud Run features in its full context.

We realized that there is room for provisioning some tips to assist you in the process of choosing the most applicable Serverless option, covered in the sections below.

Common concerns around the choice of serverless

We have a problem when there are no choices, and we have a problem when there are too many choices. Let’s burst that bubble. Cloud Functions and Cloud Run are all Google Cloud’s serverless offerings but with different characteristics, approaches, and development scopes.

Cloud Functions are event-driven serverless functions that let you write individual Cloud Function code (with multiple helper “f”unctions within the “F”unction code) and invoke those functions on specific event triggers. Cloud Functions supports individual services that run in their own runtime environment, and data is not shared among services unless you involve a database or a writable file in Cloud Storage. Though typically Cloud Functions were used in use cases where we have clear and defined input to provide a reasonably short output and for dividing your workload into independent units of work, the extent to which customers engage Cloud Functions these days has expanded, please refer to the last section titled “Before you go” in this post below. For further details, refer to the documentation, here and here.

Cloud Run is a fully managed serverless platform that packages and runs your code/application in stateless individual containers and scales up and down as needed automatically, from 0 to only as much as you use with full integration with Cloud Code, Cloud Build, Cloud Monitoring, and Cloud Logging. It is great for web applications and services at scale. Check this link for more features of Cloud Run and in full context.

Then what about App Engine, you ask? App Engine is Google’s first fully managed serverless offering, created in 2008. Cloud Run is built as the next generation of App Engine that leverages the portability of containers and the k-native spec.

Cloud Run has full feature parity with App Engine Standard and allows for the ability to deploy from source– no knowledge of containers is needed. New users are encouraged to consider workloads on Cloud Run to benefit from more CPU and Memory(32 GB and 8 vCPU), a faster feature velocity and the ability to deploy multiple projects per region(App Engine has a limitation of one GCP project per region).

There are no plans to deprecate App Engine. It will continue to support its users and roadmap into the future.

A side-by-side listing of some key features (not a comparison):

A decision chart to help with the understanding at a high level

It is important to note that Cloud Functions 2nd Gen supports Concurrency and more useful features that almost narrows down the differences. You can find the list of advanced features and differences in Cloud Functions 2nd Gen here.

Before you go…

Having said that, I know right (sigh), there are always exceptions :) We have customers for Cloud Functions who use it for broader use cases beyond just a single page of code on their machine. For example, the one on ETL for the Integration layer is one of my all-time favorites. Our customers have success stories of enabling the integration from Data Ingestion to ML using Cloud Functions for the implementation. Cloud Run features and use cases are endless and you can dive deeper on specific use cases in the documentation.

Now that you have learnt some tips on the types and options available, how about taking it a step further and create your favorite application with Cloud Run? Reference the below resource for quick and easy steps:

Cloud Run Example: https://codelabs.developers.google.com/codelabs/cloud-run-hello#4