Cloud Run (Road to Google Associate Cloud Engineer 2020 certification)

Cloud Run is a totally managed service to deploy containerized application without having knowledge on Kubernetes. It’s based upon an open standard Knative allowing applications portability.

It’s suitable for stateless HTTP applications and it allows to use any languages and libraries.

There are 2 different typologies for the service:

• Cloud Run Fully managed
• Cloud Run for Anthos

Fully Managed vs Anthos

While the Fully Managed version runs Knative API on top of the Google infrastructure, the Anthos version is based on Google Kubernetes Engine. This allows more complex configuration as supported by Kubernetes.

The main differences between the 2 types:

• Billing: with Fully Managed you pay only when the application is running, billed to the nearest 100 milliseconds. With Cloud Run for Anthos, the price is part of the GKE or Anthos scheme. The Fully Managed is cheaper so when the cost is an important parameter, this the type to choose.
• Machine resources: the managed version is limited in terms of memory and CPU: 8GB for memory and 4 CPU max. With Anthos you have access to standard or custom machine types, including GPUs.
• Networking: The access to VPC/Compute Engine for Fully Managed is possible using the Serverless VPC access. Anthos gives more freedom for the network configuration and it allows the usage of Cloud Accelerators. Also, Fully Managed is suitable only for HTTP/HTTPS workload. With Anthos you can use other protocol like for example Websockets (this feature is in Pre-GA for the Fully Managed)

Below a table from Google Cloud documentation summarizing the differences:

Trigger Cloud Run (Fully Managed)

The first way to call an application deployed used Cloud Run is the http trigger.

When deployed, Google Cloud provide a https url for the Cloud run instances. That makes possible to use it for:

• Restful web API
• Private microservices
• Middleware or reverse proxy
• Web applications

Another GCP service that can be used as trigger is Pub/Sub (Push, Pull is not possible since Cloud Run allocates the CPU only processing the request)

Cloud Scheduler and Cloud Task can also start Cloud Run workloads since they can call http url: in this way, it’s possible to execute scheduled and asynchronous tasks.

Other two triggers will be soon available:

• Websocket
• gRPC

Restrict ingress traffic

When you deploy a Cloud Run application you can decide to accept HTTP/HTTPS traffic from:

• any source;
• internal: only from same project or the VPC Service control perimeter;
• internal and cloud load balancing: beyond the internal traffic, you can accept traffic from Internet through a Load Balancer (maybe combined with the Cloud Armor WAF).

Cloud Run or Cloud functions?

Both the services are serverless and fully managed. Cloud functions are quicker to setup and to develop (no Dockerfile to create for example) they are good for prototyping and optimal for low volumes.

Google Cloud website suggests to use Cloud Run instead of Cloud Functions:

• You’re using languages or runtimes not supported in Cloud Functions
• You want longer request timeouts (up to 15 minutes)
• You’re expecting large volume and need concurrency (80 concurrent requests per container instance)

Cloud Run in the certification test

I haven’t found many questions about Cloud Run in the tests I’ve done to prepare. Generally, Cloud Run is the right response to questions mentioning serverless services, usable with any programming languages and where developers doesn’t want to manage the complexity of Kubernetes.