16 - Cloud Run - Serverless Container Apps

Welcome to Day 16 of Learn GCP in 30 Days! Yesterday, you learned how to package software into portable Docker containers. Today, we run those containers with zero server management using Google Cloud Run.

🛑 The Core Problem: The 24/7 Idle Server Waste

In Week 2, we learned how to launch Compute Engine Virtual Machines to host web applications. While VMs are powerful, they come with big operational headaches:

What Existed Previously:

To host a website, you had to provision a Virtual Machine, install an OS, set up firewalls, configure load balancers, and keep the server powered on 24 hours a day, 365 days a year.

Problems Faced:

• 💸 Paying for Empty Servers: If your website gets 100 visitors in the morning and 0 visitors at night, you still pay for 24 hours of electricity, CPU, and RAM.
• 🛠️ Maintenance Fatigue: You are responsible for upgrading Linux security patches, updating language runtimes, and monitoring server health.
• ⚖️ Complex Scaling: Configuring load balancers and Managed Instance Groups takes 5 to 6 different setup steps.

How Present Technology Solves It:

Google created Cloud Run (Serverless Containers):

1. Zero Server Management: You don't manage any Linux OS, virtual machines, or hardware. You just hand Google your container image.
2. Instant Public HTTPS URL: Google automatically provisions a global URL with a free, auto-renewing SSL padlock certificate.
3. Scale-to-Zero Cost Savings: If zero users visit your site, zero containers run, and you pay exactly $0.00.
4. Instant Elastic Autoscaling: If 5,000 visitors suddenly click your link, Cloud Run spins up 50 container clones in milliseconds, handles the traffic, and shuts them down when traffic subsides!

🚕 Real-World Analogy: Owning a Bus vs. Hailing a Taxi (Uber)

• Traditional Virtual Machine = Buying a 50-Passenger Private Bus:
  • You must pay for the bus loan, insurance, fuel, and full-time driver every single month, even if only 1 passenger rides on Tuesday and 0 ride on Wednesday.
• Google Cloud Run = Calling an On-Demand Taxi (Uber):
  • You don't own the car. You don't pay for maintenance or oil changes.
  • A car arrives in seconds only when you book a ride.
  • You pay strictly for the exact seconds you are sitting in the car. When your trip ends, the driver leaves and your bill stops immediately!

🔑 Everyday Cloud Terms Explained in Plain English

1. What Does "Serverless" Actually Mean?

2. Scale-to-Zero (True Cost Efficiency)

Most cloud services charge you by the hour as long as they are turned on.

Cloud Run introduces Scale-to-Zero:

• When no HTTP requests are hitting your web app, Cloud Run pauses all running container instances.
• Your billing counter drops to $0.00 per second.
• When a new customer visits your URL, Cloud Run wakes up a container in ~500 milliseconds (called a Cold Start), serves the request, and goes back to sleep if no further traffic arrives.

3. Concurrency (Smart Resource Sharing)

In traditional serverless tools (like older AWS Lambda functions), 1 server instance could only handle 1 user request at a time. If 50 users visited simultaneously, 50 separate server instances had to boot up.

Cloud Run features High Concurrency:

• By default, a single Cloud Run container instance can handle up to 80 simultaneous user requests at the same time!
• This makes Cloud Run dramatically faster and much cheaper than older serverless architectures.

4. Automatic HTTPS & Free SSL Certificates

Normally, securing a website with HTTPS requires purchasing a domain, buying an SSL certificate, installing certificate files on Linux, and renewing them every 90 days.

With Cloud Run:

• The moment you deploy your container, Google gives you a unique global URL: https://hello-app-xxxxxx-el.a.run.app
• SSL encryption is configured and renewed by Google 100% automatically for free.

5. Revisions & Traffic Splitting (Canary Releases)

Every time you deploy a new version of your container image to Cloud Run, Google saves it as a numbered Revision (e.g., hello-app-00001, hello-app-00002).

You can use Traffic Splitting to test new code safely:

• Send 90% of website visitors to the stable Version 1.
• Send 10% of website visitors to the new Version 2 to test for bugs!

🧪 Hands-on Lab Activity: Deploy a Container App to Cloud Run

In this lab, you will deploy a containerized web application to Google Cloud Run using both the Web Console UI and Cloud Shell CLI!

Step 1: Enable the Cloud Run API

Option A: Web Console UI

1. Open console.cloud.google.com.
2. Press /, type Cloud Run Admin API, and click on it.
3. Click Enable.

Option B: Cloud Shell CLI

gcloud services enable run.googleapis.com

Step 2: Deploy Your Container to Cloud Run

We will deploy a sample container directly to Google Cloud Run.

Option A: Web Console UI (Click-by-Click)

1. In the GCP Console, press / $\rightarrow$ type Cloud Run $\rightarrow$ select it.
2. Click Create Service at the top.
3. Under Deployment Options, select Deploy one revision from an existing container image (Artifact Registry / Docker Hub).
4. Set Container image URL:
   • Enter Google's public test image: us-docker.pkg.dev/cloudrun/container/hello
   • (Or click Select to choose the hello-app:v1 image we pushed to Artifact Registry on Day 15!)
5. Configure the service:
   • Service name: my-first-cloud-run-app
   • Region: Select asia-south1 (or your nearest region)
6. Under Authentication:
   • Select Allow public access (Allows direct web access without authentication checks).
7. Under Billing:
   • Keep default Request-based (Charged only when processing requests; scale to zero when idle).
8. Click Create!
9. Wait 15 to 30 seconds. A green checkmark will appear with your live public HTTPS URL!

Option B: Cloud Shell CLI (Fast Track)

Run this single command in Cloud Shell:

gcloud run deploy my-first-cloud-run-app \
    --image=us-docker.pkg.dev/cloudrun/container/hello \
    --platform=managed \
    --region=asia-south1 \
    --allow-unauthenticated \
    --port=8080 \
    --memory=512Mi

Anatomy Breakdown: What does each line in the gcloud run deploy command do?

Step 3: Test Your Live Serverless Web App

1. Once the deployment finishes, Cloud Run outputs a Service URL:
   text

   Service [my-first-cloud-run-app] revision [my-first-cloud-run-app-00001-xyz] has been deployed.
   Service URL: https://my-first-cloud-run-app-482910-el.a.run.app
   

2. Click the URL or copy-paste it into a new web browser tab.
3. You will see a live webpage served directly from your serverless container with a secure HTTPS padlock!

Step 4: Test Traffic Splitting (Revisions)

Let's test Cloud Run's ability to update versions seamlessly without downtime:

1. In the Web Console, open Cloud Run $\rightarrow$ Click on my-first-cloud-run-app.
2. Click Revisions tab at the top.
3. Here you can see every version you have ever deployed.
4. Click Manage Traffic:
   • You can assign 50% traffic to Revision 1 and 50% traffic to Revision 2.
   • When you click Save, Cloud Run instantly splits live traffic at the network edge with zero lag!

🐙 Continuous Deployment: How to Auto-Deploy from GitHub

Just like Vercel or Render, Google Cloud Run supports 1-Click Continuous Deployment from GitHub:

How to Set It Up in 3 Steps:

1. When creating a Cloud Run service in the Web Console, select Continuously deploy from a repository (instead of picking a container image manually).
2. Click Set up with Cloud Build $\rightarrow$ Select GitHub $\rightarrow$ Choose your repository and branch (main).
3. Select your Build Type:
   • Dockerfile: Cloud Build automatically builds your Dockerfile.
   • Google Cloud Buildpacks: You don't even need a Dockerfile! GCP automatically detects your code (Python, Node.js, Go, Java) and packages it into a container automatically.
4. Click Save!

🧹 Step 5: Clean Up All Resources (Credit Safety Guarantee)

To guarantee your trial balance remains completely untouched ($0.00), delete the Cloud Run service when finished:

Option A: Web Console UI

1. Go to Cloud Run $\rightarrow$ Check the box next to my-first-cloud-run-app.
2. Click Delete at the top $\rightarrow$ Confirm deletion.

Option B: Cloud Shell CLI

gcloud run services delete my-first-cloud-run-app \
    --region=asia-south1 \
    --quiet

Signal vs. Noise: Key Concepts & Noise Filter

Common Doubts & Interview Traps

Q1: What is a "Cold Start" in Cloud Run, and how does it affect users?

• Answer: When a service has scaled down to 0 instances and a new request arrives, Cloud Run takes ~500ms to pull the container and start it. This initial latency is called a Cold Start. Subsequent requests are blazing fast (Warm Requests) because the container stays alive for a few minutes while traffic continues.

Q2: Compute Engine VMs vs. Cloud Run: When should I choose which?

• Answer:
  • Choose Cloud Run for modern web applications, microservices, and REST APIs that can run in containers, scale with HTTP traffic, and benefit from scale-to-zero cost savings.
  • Choose Compute Engine VMs for legacy monolithic applications, non-HTTP background servers, or applications requiring specific kernel extensions or custom GPU hardware configurations.

Q3: Can Cloud Run connect securely to private databases like Cloud SQL?

• Answer: Yes! Cloud Run uses Serverless VPC Access Connectors or direct Cloud SQL connections to talk to private databases inside your VPC without exposing the database to the public internet.

Daily Practice Drill & Self-Check

Test your understanding of today's lesson:

// Try answering these:
1. What happens to your Cloud Run cost when zero users visit your website at 3:00 AM?
2. Which gcloud flag must you include to make your Cloud Run application open to public internet visitors without requiring a Google login?
3. What feature in Cloud Run allows you to send 90% of traffic to Version 1 and 10% to Version 2?

🎉 Awesome work! You have completed Day 16!

You have mastered the art of deploying serverless container applications to Google Cloud Run, understanding scale-to-zero, instant HTTPS provisioning, and revision management.

Tomorrow on Day 17, we will explore another dimension of serverless computing: Cloud Functions - Event-Driven Code!

← 15 - Containers 101 and Artifact Registry | Next Topic → 17 - Cloud Functions - Event-Driven Code