GCP Cloud Run for Virtually Free Serverless Containers

You've probably read about GCP Cloud Run in one of my posts or online and wondered if you could use it. Although it doesn't have the great publicity it deserves, it is a fantastic Google Cloud service for serverless containers at a great price. I'm here to answer the most common questions around Cloud Run to expand your horizon for serverless container service options.

What is Cloud Run?

Cloud Run is one of the serverless computing services from the Google Cloud Platform. In it, you run Docker container images that are purpose-built for your application.

You have two (2) ways of running Cloud Run. You can run it as a service or as a job. The main difference between the two approaches is that jobs have a finite life, while services don't. You usually run websites or APIs as a Cloud Run service and batch jobs as Cloud Run jobs.

How does GCP Cloud Run work?

Google Cloud Run uses Docker images to run serverless workloads. Those Docker images have all the application code bundled in, so they are ready to execute the code.

Cloud Run manages the concept of revisions and instances. A revision is a version of the Cloud Run service or job. You could have different revisions because you have updated your application code, made changes to the environment, or any other configuration change from the previous revision, which might trigger a new revision. A revision can have multiple instances of the Docker image running. An instance is a Virtual Machine running the Docker image you specify for your revision. It handles receiving your requests or jobs.

Essentially, instances can have two states: idle or active. Active instances are the ones handling requests or running jobs. An instance becomes idle after it finishes the request, and there's no other request to process. It stays idle for 15 minutes, and after that, it stops. If it receives a request while idle, it goes back to the active state. You can minimize cold starts by using idle instances that are always ready, but that increases the cost.

Does Cloud Run have any pitfalls?

Not every cloud provider service is perfect, and Cloud Run is proof of it. These are some of the main limitations regarding the service:

• Docker images can only come from the Artifact Registry and the Docker Hub (source here). You are limited to those two sources for images, which can be a deal-breaker, depending on your company policies. You could always pull an image locally and re-upload it to the corresponding registry.
• Cold starts can happen when there is no active or idle instance to handle your request. In this case, Cloud Run spins up a new instance to do so, but that can take a considerable amount of time, depending on your image. It means that the latency during the startup time of your instance will be high. Having a minimum amount of container instances will help you at the expense of an increased cost.

If you are interested in the service quotas (limits imposed by the Google Cloud Platform), you can read about those here.

How do I configure a Cloud Run service?

I have significantly more experience working with Cloud Run services, so we'll focus on going through the configuration for one of those. To simplify explaining it, I'll list the configuration components and walk you through what each of those means. I will use the Terraform documentation for the reference.

Scalability

You get to pick the minimum and maximum number of instances the service has. Choosing a minimum instance number greater than 0 ensures that several containers will always be idle. You also define the number of concurrent requests that each instance will handle.

For example, having a maximum number of instances of 10 and a maximum concurrency of 15 ensures your service can handle up to 150 simultaneous requests.

You configure the timeout for requests, which goes up to 60 minutes.

Execution permissions via Service Accounts

You define the Service Account that will execute the Cloud Run service. It means that the service inherits the permissions from the Service Account.

VPC configuration

You can place GCP Cloud Run services in VPCs (restricted to some regions). There are two options for configuring VPC access: direct VPC egress or VPC connectors. It defines how traffic for ingress and egress flows.

Container configuration

To configure the container, define the image, arguments, run commands, and environment. All of that ensures that you have a consistent container configuration each time. You can mount secrets into a container as environment variables.

Within the container configuration, you also define liveness and startup probes for each container, which verify if the container is alive and started, respectively.

Traffic routing

Traffic routing defines which percentage of traffic goes into the revision, allowing you to configure split traffic for AB testing.

How does Cloud Run integrate with other GCP services?

GCP being the integrated ecosystem it is, you can combine a Cloud Run service with multiple other GCP services. These are some scenarios and how to combine them with other GCP services.

• Custom domains for Cloud Run: To add a custom domain to a Cloud Run service, you should put an Application Load Balancer in front of it. You can then configure an APEX domain record against the Load Balancer IP. The Load Balancer will forward requests to the configured Cloud Run service. More information on that approach is here.
• Notifications for workloads: If you want to use a notification system for your workloads, you can use Cloud PubSub. You could have PUSH or PULL services, depending on the type of architecture that you need. PUSH services work better with Cloud Run, while PULL services work better with App Engine or Compute Engine. More information on that approach is here.
• Scheduling for workloads: To schedule some workloads, you could use Cloud Run Jobs or combine a GCP Cloud Scheduler (or more than one) to send HTTP requests to the target Cloud Run Service. More information on that approach here.
• Databases for workloads: You can natively connect a Google Cloud SQL instance to the Cloud Run service. Alternatively, you can directly connect with a database service using the traditional mechanisms offered by the database service. More information on that connection is here.
• Remotely building workloads: You can use Cloud Build to prepare the Docker images for your workload in Google Cloud. It is the perfect choice to abstract and standardize the image where your builds happen, removing local computers from the equation. More information on that connection is here.

Above, you have some use case scenarios that you might encounter, but there are dozens of ways to connect your Google Cloud Run instances with other Google Cloud services. You can even connect to services like AWS CloudFront.

Are there any alternatives to Cloud Run?

There are alternatives to Google Cloud Run in Google Cloud. These are some of the most common ones and how they differ from Cloud Run.

• Google Cloud Function: You can use a Cloud Function to focus on the application code of the function you want to run. The new Cloud Functions engine in Google Cloud uses Cloud Run as the backend, so essentially, you are abstracting the Docker image part of it.
• Compute Engine: This Cloud Computing service is an Infrastructure as a Service, which means you handle all the provisioning and scaling. You handle all the operational aspects, needing more expertise and time commitment.
• Google Kubernetes Engine: GKE is a service that allows you to run Kubernetes workloads in the cloud. You can use it to work with Kubernetes.
• Google App Engine: This platform simplifies deployments, but you retain significantly less control than with Cloud Run. For example, this service scales more slowly than Cloud Run.

Should I use Cloud Run GCP?

If you are looking for ways to run some personal projects or small workloads in the cloud, paying the least amount possible, Google Cloud Run might suit you. Working with enterprise-scale applications is an option since Cloud Run can scale significantly.

I recommend you look at your use cases and analyze how you need it to scale, when, and how long it runs. After you analyze that, you are ready to pick which service you can use.