3 cool Cloud Run features that developers love
Earlier this year, we announced Cloud Run, a managed serverless compute platform for stateless containers. Cloud Run abstracts away infrastructure management, and makes it easy to modernize apps. It allows you to easily run your containers either in your Google Kubernetes Engine (GKE) cluster with Cloud Run on GKE or fully managed with Cloud Run.
Cloud Run has lots of great features and you can read the full list on the webpage. But in conversations with customers, three key features of the fully managed version of Cloud Run stand out:
Pay for what you use pricing
Once above the always free usage limits, Cloud Run charges you only for the exact resources that you use.
For a given container instance, you are only charged when:
- The container instance is starting, and
- At least one request or event is being processed by the container instance
During that time, Cloud Run bills you only for the allocated CPU and memory, rounded up to the nearest 100 milliseconds. Cloud Run also charges for network egress and number of requests.
As shared by Sebastien Morand, Team Lead Solution Architect at Veolia, and Cloud Run developer, this allows you to run any stateless container with a very granular pricing model:
"Cloud Run removes the barriers of managed platforms by giving us the freedom to run our custom workloads at lower cost on a fast, scalable and fully managed infrastructure."
Read more about Cloud Run pricing here.
Concurrency > 1
Cloud Run automatically scales the number of container instances you need to handle all incoming requests or events. However, contrary to other Functions-as-a-Service (FaaS) solutions like Cloud Functions, these instances can receive more than one request or event at the same time.
The maximum number of requests that can be processed simultaneously to a given container instance is called concurrency. By default, Cloud Run services have a maximum concurrency of 80.
Using a concurrency higher than 1 has a few benefits:
- You get better performance by reducing the number of cold starts (requests or events that are waiting for a new container instance to be started)
- Optimized resource consumption, and thus lower costs: If your code often waits for network operations to return (like calling a third-party API), the allocated CPU and memory can be used to process other requests in the meantime.
Read more about the concept of concurrency here.
Secure event processing with Cloud Pub/Sub and Cloud IAM
Your Cloud Run services can receive web requests, but also other kinds of events, like Cloud Pub/Sub messages. We've seen customers leverage Cloud Pub/Sub and Cloud Run to achieve the following:
- Transform data after receiving an event upon a file upload to a Cloud Storage bucket
- Process their Stackdriver logs with Cloud Run by exporting them to Cloud Pub/Sub
- Publish and process their own custom events from their Cloud Run services.
The messages are pushed to your Cloud Run container instances via the HTTP protocol. And leveraging service accounts and Cloud IAM permissions, you can securely and privately push messages from Cloud Pub/Sub to Cloud Run without having to expose your Cloud Run service publicly. Only the Cloud Pub/Sub subscription that you have set up is able to invoke your service.
You can achieve this with the following steps:
- Deploy a Cloud Run service to receive the messages (it listens for incoming HTTP requests, and returns a success response code when the message is processed)
- Create a Cloud Pub/Sub topic
- Create a new service account and grant it the "Cloud Run Invoker" role on your Cloud Run service
- Create a push subscription and give it the identity of the service account.
Run, don’t walk, to serverless containers
These are just a few of the neat things that developers appreciate about Cloud Run. To learn about all the other things to love about Cloud Run, check out these Cloud Run Quickstarts.