(Almost) 2 years of using GCP Cloud Run
Tags: googlecloud, serverless
Published: 2020-12-29 17:35:50


In 2019 seems like totally madness go to production new GPC project in beta with only one region available, in my team we see the potential of the tool and gave it a chance, personally, I have to say that was the best decision we made so far in almost 2 years of work with this client.


![image.png](https://cdn.hashnode.com/res/hashnode/image/upload/v1609241520343/0bdk9WHZ3.png)

## What is Cloud run?
Cloud run is a GCP is a serverless compute service based on docker images running in a Knative cluster managed by Google, so, you only have to worry about writing the code and google handles the infrastructure. Have the following characteristics: 

- Managed service by google that auto-scales up to 1000 instances and down to 0
- is based on the open-source project Knative, so you can migrate to another Kubernetes cluster in another cloud.
- Gives you an HTTPS TLS certificate and a URL out of the box.
- You only pay if you're serving requests
- If an application can be packaged into a container image that can run on Linux (x86-64), it can be executed on Cloud Run.

## Similar cloud products
- AWS Fargate
- Azure Container Instances

## Is good for:
- Web sites and API's
- Private microservices, data transformation, background jobs, Async events

##  Is Bad for:
Long background jobs outside the request processing, cloud run request timeout are set to 15 minutes currently and will be increased to 60 minutes.

## How to deploy:

- Is very easy, just use **gcloud run** deploy
    - For pipelines, you need a service account with the right permissions
    - authenticate with the JSON key
    - then execute the deploy command
- Only can deploy from Google container registry.
- Support canary or blue-green deployments

## Cold starts
This is the most annoying part for me, we choose Java and spring framework to develop the services, this stack is great for traditional environments, but cloud run scales down to 0, so each startup consumes ~20 seconds, in 2020 is not an acceptable time at all.

Increasing the container resources we reduce the startup time to more than a half, but the final solution was migrating to [SparkJava](https://sparkjava.com/) another framework more lightweight, fortunately, we wrote our code using the clean architecture pattern, and the migration was painless.

some considerations:

- Google doesn't provide any guarantee of how long it will keep a service warm.
- Keep lazy loading in mind
- Prevent your app from crashing
- Use a suitable language/framework, Javascript, Typescript, go, python, or PHP are very suitable for cloud run.

## Scaling
Each Cloud Run service can scale by default up to 1000 container instances, a limit that can be increase via a quota request. Each container instance can handle up to 80 simultaneous requests.

## Monitoring and logging
Totally integrated with the Stackdriver suite, if you want you can configure the logs to the Stackdriver format, to easily make filters for log severity.

## Upcoming features
- You can keep an instance warm with no traffic (in beta), Google charge you less for this instance when isn't in use, (this will solve the cold start issue).
- Support VPC access (redis, memcached, private IP's)
- Programmatic Gradual deployment and rollout via gcloud command
- Multi region load balancing, this give you the 
    - Cloud CDN
    - Identity aware proxy
    - Cloud armor
- Deploy from yaml file
- 1hr of request timeout
- Graceful termination: Now it send you a signal before the container is shutting down

You can see more details in [this video](https://www.youtube.com/watch?v=os2FPR9WjY0&feature=emb_title)


I can write more in-depth guides on how to deploy it in a  CI/CD pipeline, or how to configure the logs to match the Stackdriver format, please if you want some of these articles just give me a comment.