Cloud Run: Use Cases & Building a Simple Service
Cloud Run is one of the Google serverless compute platform, on which the applications are executed within a container. It can rapidly scale up and down with respect to the varying requested demand. From the feature perspective, it seems quite close to another Google tool, App Engine or even App Engine flexible, however, the focus of Cloud Run is for the time being containerized app. The potential use cases for Cloud Run are web apps, public APIs, internal line-of-business apps, microservice-based apps, etc. There are alternative execution environments for the Cloud Run in the Google Cloud ecosystem such as Cloud Engine (standard VM), Kubernetes Engine(GKE), Dataflow or Cloud Function. For example, for long-running tasks or training machine learning models GKE or Cloud Engine is more suitable. For the massive data processing and streaming, Google Dataflow can perform better and for the simple event-based apps that can be executed up to 9 minutes Cloud Function could be a better fit. Shortly, before selecting the compute platform, we need to analyze our requirements like supported programming language, communication protocol, microservice-based approach, portability, auto-scaling, traffic load balancing, and the complexity of management of underlying resources, and then we should decide with which compute platform should we continue. The following image from Google resources may simplify our decision during the selection:
The general working mechanism of Cloud Run is illustrated in the another image by Google, which actually summarize nearly it's all aspects. The whole point is you need to call the Cloud Run using HTTP/HTTPS request from the internet or in the internal network, and then Cloud Run performs the required operations. Since it is serverless, the auto-scaling within the defined max-min interval, it will be done effortlessly.
In this tutorial, we introduce some standard use cases for Cloud Run and attempt to understand how image building operations are performed, and finally see the auto-scaling mechanism of Cloud Run.
Cloud Run Use Cases
As aforementioned, cloud run can be used for many scenarios, some of them are visually depicted below.
The first figure reflects the easiest use case, in which the client can consume the REST API implemented in the Cloud Run, which later persists the data sent by the client in the database.
In the second use-case, an e-commerce website runs in a cloud run service that interacts with a relational database, a cache solution and 3rd party apps. Clients can interact with this website after accessing the Cloud CDN (similar to AWS CloudFront)that stores the static data to improve the response time and a Cloud Armor (similar to AWS WAF)to filter the incoming traffic via content-based rules.
If the authentication is required, two components Cloud IAP and Identity provider can be included in the similar scenario. After authenticating the user, the Cloud Run service can be consumable.
A monolithic application can be converted into the microservice architecture model as below, and each cloud run can take over a specific task. Below, we see the web requests are accepted by a frontend cloud run service that directs the request either to Products or Orders Cloud Run, which later access to the Cloud SQL databases.
Cloud Run can also be integrated into the asynchronous use-cases, as shown below. For instance, the uploading a data into Cloud storage can trigger the Cloud run, which process the data and later publish the required message into the Pub/Sub message service. The subscriber of this service will be informed as soon as possible. Here, Cloud Function can also be placed if the use-case is appropriate.
As in many event-based services, a trigger-based approach such as setting a scheduler up to trigger a cloud run service it is also possible.
Building a Container Image for Cloud Run
Two approaches are available to produce the container images for Cloud Run. The first one is via Docker, which requires a Dockerfile including all required components to run the software, the second approach is to use buildpacks, which enables us to generate the container directly from the source code without writing an additional Dockerfile. A typical Dockerfile for a Node.js project would be seen as below:
The important part in the Dockerfile, as I mentioned in many previous articles, a multistage Dockerfile will reduce the size of the docker image. Why is this required, the reason is you don’t need to have the building libraries once your software is built, instead of keeping them in the image, we start with a new lightweight image that doesn’t include these building packages.
After the theory part, it is time to practice how we can create an image. There is a great example for the buildpack in the Google website as given below in a very concise format, and I tested it in the Cloud Shell environment. The code below enables first the cloud run service, set the compute region to us-central1, since Cloud Run is a region-dependent service. Afterward, the code is cloned from the GitHub repo, then the project is built via buildpack, now the image is ready, and it can be tested using docker container tool. The last command enables us to run the container in Cloud Run service. You may notice the source argument, which points out the path where the image is created.
# enable cloud rungcloud services enable run.googleapis.com
gcloud services enable run.googleapis.com
# set compute region
gcloud config set compute/region us-central1
# clone the 4buildpack samples repo
git clone https://github.com/GoogleCloudPlatform/buildpack-samples.git
# select the sample app and build with buildpack
cd buildpack-samples/sample-python
pack build --builder=gcr.io/buildpacks/builder sample-python
# run the new build app, hello world app
docker run -it -e PORT=8080 -p 8080:8080 sample-python
# build and run your sample app on Cloud Run
gcloud beta run deploy --source .Once the above commands are executed, the following result would appear in the shell. This means our Cloud Run service is reachable via the provided URL.
Service [sample-python] revision [sample-python-...-...] has been deployed
and is serving 100 percent of traffic.
Service URL: https://sample-python-abcs-ucxxxx.a.run.appDiving into Auto-Scaling in Cloud Run
Cloud Run has an internal load balancer, which adjusts the required size of the Cloud Run container counts. When an image is packaged in a Cloud Run service, a service configuration is created for the container, which observes the started container and its health states. In case there is a revision change, this configuration file will be updated so that the newest version will be loaded. It is also possible to use different versions at the same time and direct the traffic proportionally to each Cloud Run Service. Cloud Run service supports up to 1000 instances per default, however, it can be increased with the request.
In terms of the costs, you will be only charged if the container inside the Cloud Run is requested (during the request handling duration depicted in the figure below). If the container doesn’t handle any request, it will be shut down.
There is one crucial point which may impact the design of your application. Since the requests are in the form of HTTP, once the HTTP response is sent, all background operations in the cloud run won’t be finalized as shown above. Therefore, it is recommended to turn the background tasks into HTTP requests, such as using Cloud Tasks or Cloud Scheduling services. Cloud Run supports two additional web request types, namely, Websockets and gRPC.
Conclusion
The purpose of this article is to bring you to the world of Cloud Run, and we tried to find answers what are the use cases where Cloud Run can be applied, how building an image works with a code example and finally how the auto-scaling is applied. Apart from that, it is emphasized how the container app should be designed to prevent potential issues with the background tasks and how Cloud Run service is charged. The alternative solution in other Cloud platforms could be AWS Fargate and AWS Container Instance. This article is constructed on the Google documents and placed images are inspired from the Google images. We will continue with Cloud Run for a while in the next articles.