Part 4 of a 6 Part Series on Deploying on Google Cloud Platform

We recently did five mock deployments on Google Cloud Platform using different methods in an effort to understand the nuances associated with each method.

The five methods we investigated were:

We will be examining each of the 5 approaches over the coming weeks and wrap it all up with an article that talks about our findings in the context of all five approaches.

For our fourth article in the series we will be deploying an application on Google Cloud Platform using Cloud Run.

Cloud Run Approach

Cloud Run is the “Container to Production in seconds” solution that Google Cloud Platform offers. It allows users to deploy and run request-serving containers, or even small jobs to a fully managed, serverless platform.

Cloud Run integrates very well with other GCP services like Cloud Build and Artifact Registry. Its pricing model is very simple. The user pays for the time their code is running, rounding down to 100ms.

Cloud Run uses a Docker image as its smallest unit of deployment, which simplifies the developer experience. It also scales indefinitely depending on the number of requests received, which makes it a reliable solution.

Additionally, developers can use any programming language they want since Cloud Run works with Docker containers instead of language runtimes.

cloud run instance group

When to use Cloud Run

Cloud Run is a good solution for serverless applications written in pretty much any language.

It leverages the flexibility of Docker containers while incorporating some really interesting features like automatic application scaling. This makes it a good option for running microservices, as long as the user doesn’t need node allocation and networking features.

Cloud Run is also a good option for organizations that could benefit from the pricing flexibility of serverless applications.

How we implemented it

For this solution we have used a terraform project that declares the following resources:

  • A VPC with a subnet for connecting Redis and CloudRun
  • A Redis instance to store data
  • A CloudRun service that runs the application

The project contains a simple Counter Application consuming a Redis Memory Store.

Main Components


Here is the Terraform block declaring the Redis instance.

Copy to Clipboard


Here we declare the connector that will be used to allow the application to access the Redis instance.

Copy to Clipboard

CloudRun Service

In the CloudRun Service we set parameters like region, image, and the application environment variables among other details.

Copy to Clipboard

Other components

The complete solution with other components can be found in our repository:

Pros and cons

Pros Cons
“Container to production in seconds,” and Google really means it Some events available for Cloud Functions are not available in Cloud Run (like Firestore)
Simple and unified developer experience, each service implemented by a Docker image Not very useful for applications with background tasks
Scalable serverless execution based on number of requests received It can add complexity to the application, making the architecture harder to understand
Support for code written in any language, thanks to Docker
Can be integrated into GKE clusters using Anthos
Simple pricing model, you pay for the time your code is running

Share Me

Related Reading


Don’t miss a beat

Get all the latest NearForm news, from technology to design. Sign up for our newsletter.

Follow us for more information on this and other topics.