GCP Cloud Run — Serverless Stateless Containers
Google cloud platform’s fully managed compute platform for stateless containers.
What is Cloud Run?
Google has announced “Managed Service for Containers” called “Cloud Run” on 10th April, 2019. It allows us to use our images and run them in managed environment. Cloud Run is a fully managed compute platform that automatically scales your stateless containers.
Let’s understand where this service stand. We have,
1. We have Kubernetes environments (managed services like GKE, EKS or self-managed on-prem Kubernetes clusters)
2. We have Function as a Service (FaaS) — like Google Cloud Function, AWS Lambda, Azure Functions. We use provided language/library for code.
Now, GCP Cloud Run seats between above two.
Cloud Run is serverless, it abstracts away all infrastructure management, so you can focus on what matters most — building great applications. Cloud Run is built upon an open standard, Knative, enabling the portability of your applications.
Key Features are,
・Any language, any library, any binary
・Leverage container workflows and standards
・Pay‐per‐use — Only pay when your code is running, billed to the nearest 100 milliseconds.
Hands-on 💻
- Log into “Google Cloud Platform” account.
- Open “Cloud Shell”
3. Pull our sample application from Docker Hub and push same image into Google Container Registry (GCR)
# Pull image from Docker Hub
docker pull bhargavshah86/kube-test:latest
# TAG image for GCR
docker image tag bhargavshah86/kube-test:latest asia.gcr.io/[PROJECT-ID]/kube-test:latest
# Push image into GCR
# [region].gcr.io/[PROJECT-ID]/[IMAGE:TAG]
docker push asia.gcr.io/[PROJECT-ID]/kube-test:latest4. Go to “Cloud Run” and Create Service.
5. Click Create to deploy the image to Cloud Run and wait for the deployment to finish.
6. Once finished, Click the displayed URL link to run the deployed container.
Key highlights:
・Rollbacks, gradual rollouts, and traffic migration — Cloud Run allows you to specify which revisions should receive traffic and to specify traffic percentages that are received by a revision. This feature allows you to rollback to a previous revision, gradually roll out a revision, and split traffic between multiple revisions.
・Resource model — In the diagram, Service A is receiving many requests, which results in the startup and running of several container instances. Note that Service B is not currently receiving requests, so no container instance is started yet.
Each revision receiving requests is automatically scaled to the number of container instances needed to handle all these requests. Note that a container instance can receive many requests at the same time. With the concurrency setting, you can set the maximum number of requests that can be sent in parallel to a given container instance.
・Concurrency values — By default Cloud Run container instances can receive many requests at the same time (up to a maximum of 80). Note that in comparison, Functions-as-a-Service (FaaS) solutions like Cloud Functions have a fixed concurrency of 1.The following diagram shows how the concurrency setting affects the number of container instances needed to handle incoming concurrent requests:
・Configuration — Maximum Memory 2GB (default 256MiB), CPU 2vCPUs (default 1vCPU), $PORT default 8080.
Curious about How we created our sample application, refer below
Quickstart: Build and Deploy, refer below
Conclusion:
- Google Cloud Run represents a major development for many customers of Google Cloud Platform who want to use both serverless and container technologies in their applications.
- Vendor lock-in and cold start are the two major issues with FAAS serverless model. With Google Cloud run you don’t need to worry about both these big issues. As its containers, you can move anywhere and with the concurrency model of cloud run the cold start problem is handled to a good extent.
- It’s going to make it very, very simple for people who are running containerized, stateless web servers today to get serverless benefits.
