🚀Google Cloud Run
Google Cloud Run — Beginner to Expert Notes
This section is about developing and running applications on Google Cloud, and the first service introduced is Cloud Run.
1. What is Cloud Run?
Cloud Run is a fully managed, serverless compute platform that runs applications packaged as containers.
In simple words:
You give Cloud Run your application/container → Cloud Run runs it → automatically handles traffic, scaling, HTTPS, and infrastructure.
Example:
You build a Java Spring Boot application:
Java Spring Boot App ↓ Container ↓ Artifact Registry ↓ Cloud Run ↓ HTTPS URL ↓ Users
2. What does "Serverless" mean?
Serverless does NOT mean there are no servers.
Servers still exist, but Google manages them for you.
Traditional VM approach
You have to worry about:
VM ├── OS ├── CPU ├── Memory ├── Networking ├── Patching ├── Scaling ├── Security └── Application
With Cloud Run:
You manage: Application Container Google manages: Servers OS Infrastructure Scaling HTTPS infrastructure
So you can focus more on writing application code.
3. What does Cloud Run actually run?
Cloud Run runs containers.
A container packages your application and everything it needs to run.
For example:
Container Image ├── Java ├── Spring Boot JAR ├── Dependencies └── Configuration
Cloud Run starts that container when it needs to process requests.
4. Cloud Run is for Stateless Applications
This is very important.
Cloud Run is designed primarily for stateless containers.
Stateless means:
The container should not depend on information stored only inside that particular container.
For example, don't assume:
Container A ↓ stores user session locally
and then expect the next request to always reach Container A.
Why?
Because Cloud Run can dynamically create and remove containers.
Traffic increases ↓ Container 1 Container 2 Container 3 Container 4
Later:
Traffic decreases ↓ Container 1 Container 2
Some containers disappear.
Therefore, persistent data should generally be stored in external services such as databases or object storage.
5. How does Cloud Run receive traffic?
Cloud Run can run containers that respond to:
HTTP/Web requests
Example:
User ↓ HTTPS request ↓ Cloud Run ↓ Container ↓ Application ↓ Response
It can also be triggered by events such as Pub/Sub events.
Example:
Application ↓ Publish event ↓ Pub/Sub ↓ Cloud Run ↓ Container processes event
6. Cloud Run is based on Knative
Cloud Run is built on Knative.
Knative is an open-source platform built around Kubernetes technologies for running serverless workloads.
Conceptually:
Kubernetes ↓ Knative ↓ Cloud Run technology
One advantage is that Knative provides an open approach to serverless container workloads.
The course mentions that Knative-based workloads can run:
- Fully managed on Google Cloud
- On Google Kubernetes Engine
- Anywhere Knative runs
7. Cloud Run Automatic Scaling
This is one of Cloud Run's biggest benefits.
Suppose your application normally receives:
10 requests/sec
Cloud Run might run only a small number of containers.
Traffic suddenly becomes:
1,000 requests/sec
Cloud Run can automatically create additional container instances.
Low traffic Container 1
↓
High traffic Container 1 Container 2 Container 3 Container 4 ...
When traffic decreases:
Container 1 Container 2 Container 3 Container 4
↓
Container 1
Cloud Run can even scale down to zero when there is no traffic, depending on the configuration.
8. Scale to Zero
This is a very important serverless concept.
Suppose nobody is using your application:
Requests = 0
Cloud Run can have:
Running instances = 0
When a request arrives:
User ↓ Request ↓ Cloud Run ↓ Starts container ↓ Application handles request ↓ Response
So you don't need to keep a VM running 24×7 just waiting for users.
9. Cloud Run Pricing
The basic idea from the course is:
You pay based on the resources used by your Cloud Run workloads rather than maintaining permanently provisioned servers.
Costs depend on things such as:
- CPU
- Memory
- Request processing/container time
- Number of requests
The course describes billing granularity in terms of 100 ms and says there is also a charge associated with requests.
Simple example
Suppose:
Application receives requests ↓ Container runs ↓ CPU + Memory consumed ↓ You are charged for the applicable usage
If there are no requests and your service is allowed to scale to zero, you don't keep paying for an always-running VM simply because it exists.
Note: Cloud Run pricing has evolved over time, so for real deployments you should check the current Google Cloud pricing page rather than relying on the course's exact billing wording.
10. CPU and Memory
Your container can be configured with CPU and memory.
For example:
Small application ↓ Less CPU Less memory ↓ Lower cost
Large application:
More CPU More memory ↓ Higher cost
So:
More resources generally mean higher cost.
11. Cloud Run Developer Workflow
The course gives a simple 3-step workflow.
Step 1 — Write the application
You can use your preferred programming language.
For example:
Java Python Node.js Go PHP C++ ...
Your application needs to start a server that listens for web requests.
For example, conceptually:
Application starts ↓ Server starts ↓ Listening for requests ↓ Cloud Run sends HTTP request
For your Java/Spring Boot background, think:
Spring Boot ↓ Embedded server ↓ HTTP endpoint ↓ Cloud Run
12. Step 2 — Build a Container Image
Your application needs to be packaged into a container image.
For example:
Source Code ↓ Build ↓ JAR ↓ Docker/Container image
A simplified Java example:
Spring Boot application ↓ application.jar ↓ Container image
The image contains what is needed to run your application.
13. Step 3 — Push Image to Artifact Registry
The container image is stored in Artifact Registry.
Think of Artifact Registry as:
A repository for storing software artifacts such as container images and packages.
So:
Your Application ↓ Container Image ↓ Artifact Registry ↓ Cloud Run
Cloud Run retrieves the image and deploys it.
14. Complete Container-Based Flow
Remember this flow:
DEVELOPER | ↓ Write Application | ↓ Build Application | ↓ Create Container | ↓ Artifact Registry | ↓ Cloud Run | ↓ HTTPS Endpoint | ↓ Users
This is one of the most important diagrams to remember.
15. What happens after deployment?
After you deploy your container image to Cloud Run:
Cloud Run ↓ Deploys container ↓ Provides HTTPS endpoint ↓ User sends request ↓ Cloud Run routes request ↓ Container handles request ↓ Response returned
You receive a unique HTTPS URL for the service.
Conceptually:
https://your-service-xxxxx.run.app
16. Dynamic Container Management
Cloud Run manages container instances according to traffic.
Suppose:
10 users
Maybe only a small number of instances are required.
Traffic increases:
10 users ↓ 100 users ↓ 1,000 users
Cloud Run can increase the number of container instances.
When traffic falls:
1,000 ↓ 100 ↓ 10 ↓ 0
Cloud Run can reduce instances accordingly.
This is called automatic scaling.
17. Two Ways to Deploy to Cloud Run
The course introduces two workflows:
A. Container-based workflow
You create the container yourself.
Source Code ↓ Build ↓ Container Image ↓ Artifact Registry ↓ Cloud Run
B. Source-based workflow
You give Cloud Run your source code.
Source Code ↓ Cloud Run ↓ Buildpacks ↓ Container Image ↓ Cloud Run
18. Container-Based Workflow
This gives you more control.
You decide:
- Base image
- Dependencies
- Runtime
- Configuration
- Build process
- Container setup
Example:
Java 17 + Spring Boot + Dependencies + Application JAR ↓ Container Image
Then:
Artifact Registry ↓ Cloud Run
Advantage
More control and transparency.
This is useful when you need specific runtime or container configuration.
19. Source-Based Workflow
Sometimes you don't want to manually create a Dockerfile/container.
You can provide source code and Cloud Run can build it into a container.
Conceptually:
Source Code ↓ Cloud Run Build Process ↓ Buildpacks ↓ Container Image ↓ Cloud Run
20. What are Buildpacks?
Buildpacks automatically transform application source code into a container image.
Instead of manually saying:
FROM Java image COPY application.jar ... RUN ...
Buildpacks can detect your application and determine how to build/package it.
For example:
Java source/application ↓ Buildpack detects Java ↓ Selects appropriate runtime/build process ↓ Container image
This makes the source-based workflow easier.
21. Why use Source-Based Deployment?
Imagine you have:
My Spring Boot application
You don't want to worry about:
- Writing Dockerfile
- Choosing base image
- Container configuration
- Build setup
You can use the source-based workflow.
Cloud Run handles much of the packaging process.
Easy way to remember:
Container workflow:
"I build the container."
Source workflow:
"Cloud Run builds the container for me."
22. HTTPS is Handled by Cloud Run
Another important feature:
Cloud Run provides HTTPS serving for your service.
Instead of manually setting up:
SSL certificate HTTPS configuration TLS termination
Cloud Run handles the HTTPS serving infrastructure.
So your application can mainly focus on:
Receive request ↓ Process request ↓ Return response
23. Cloud Run Supports Many Languages
Cloud Run isn't limited to Java.
The course mentions languages including:
- Java
- Python
- Node.js
- PHP
- Go
- C++
And even:
- COBOL
- Haskell
- Perl
The important concept is:
Cloud Run can run applications as long as you can package them into a compatible Linux container and the application follows Cloud Run's runtime requirements.
So you aren't restricted to a small list of programming languages.
24. Example — Java Spring Boot on Cloud Run
Imagine you build:
PaymentService
using:
Java Spring Boot
Your project:
payment-service/ ├── src/ ├── pom.xml └── application.properties
Build:
mvn clean package
Produces:
payment-service.jar
Then create a container:
payment-service.jar ↓ Container Image
Push:
Container Image ↓ Artifact Registry
Deploy:
Artifact Registry ↓ Cloud Run
Cloud Run gives you:
HTTPS URL
User:
POST /payment
↓
Cloud Run:
Container instance
↓
Spring Boot:
PaymentController
↓
Response:
Payment successful
25. What happens when traffic increases?
Suppose one container can handle a certain amount of traffic.
Initially:
Users ↓ Cloud Run ↓ Container 1
Traffic increases:
Users ↓ Cloud Run ↓ Container 1 Container 2 Container 3
Traffic increases further:
Container 1 Container 2 Container 3 Container 4 Container 5 ...
When traffic falls:
Container 1 Container 2 Container 3 Container 4
↓
Container 1
↓
Potentially:
0 containers
This is serverless autoscaling.
26. Cloud Run vs VM — Easy Comparison
| Feature | VM | Cloud Run |
|---|---|---|
| Infrastructure management | You manage more | Google manages it |
| Application packaging | Flexible | Container |
| Scaling | Configure/manage | Automatic |
| Scale to zero | Usually not the normal VM model | Yes |
| HTTPS infrastructure | You may configure it | Managed |
| OS management | You manage | Google manages |
| Serverless | ❌ | ✅ |
| Best for | Full server control | Stateless containerized apps |
27. Cloud Run vs Kubernetes
A useful way to understand the relationship:
Kubernetes
Gives you lots of control.
You ↓ Kubernetes ↓ Nodes ↓ Containers
You generally need to understand and manage more infrastructure concepts.
Cloud Run
Higher abstraction:
You ↓ Container ↓ Cloud Run ↓ Users
Cloud Run handles much of the infrastructure and scaling.
Simple memory trick
Kubernetes = more control
Cloud Run = more simplicity
28. Cloud Run vs Compute Engine
Think:
Compute Engine
"Give me a virtual machine."
You manage the VM/application environment.
Cloud Run
"Run my containerized application."
Google manages much more of the underlying infrastructure.
29. Why would a developer choose Cloud Run?
Cloud Run is attractive when you want:
✅ Container flexibility
✅ Serverless operation
✅ Automatic scaling
✅ HTTPS
✅ Scale to zero
✅ Less infrastructure management
✅ Pay-for-usage model
✅ Support for many programming languages
✅ Easy deployment
30. Important Limitations / Things to Remember
Cloud Run isn't automatically the best choice for every application.
Remember:
1. Stateless design
Don't rely on local container storage for permanent application data.
Use external storage/database where appropriate.
2. Request-oriented applications
Cloud Run is particularly suitable for applications that respond to HTTP requests or supported events.
3. Containerization
Your application needs to be runnable as a compatible container.
4. Startup time
When scaling from zero, there can be startup latency because a new instance needs to start.
31. Expert-Level Mental Model
Think of Cloud Run as a managed container execution layer.
USERS | ↓ HTTPS Request | ↓ ┌───────────────┐ │ Cloud Run │ └───────────────┘ | ┌───────────┼───────────┐ ↓ ↓ ↓ Container 1 Container 2 Container 3 | | | └───────────┼───────────┘ ↓ Application | ↓ Database / Storage
Cloud Run's job is essentially to manage the execution of your containerized application while abstracting away much of the infrastructure.
⭐ Most Important Exam Points
Remember these 10 points:
- Cloud Run = managed serverless compute platform.
- Cloud Run runs containers.
- It is designed primarily for stateless applications.
- It can respond to HTTP requests and events such as Pub/Sub.
- It can automatically scale up and down.
- It can scale to zero.
- You generally pay based on applicable resource/request usage, rather than maintaining a dedicated VM.
- Container images can be stored in Artifact Registry.
- Cloud Run can provide HTTPS serving for your application.
- You can deploy either a container image or use a source-based workflow with Buildpacks.
🧠 One-line memory trick
Code → Container → Artifact Registry → Cloud Run → HTTPS → Automatic Scaling → Users
And for source deployment:
Source Code → Buildpacks → Container → Cloud Run → HTTPS → Users
This is the core concept you should understand before moving to the next Cloud Run topics.
Yes 👍 you are thinking in the right direction, but there is one important distinction.
Docker
IMAGE ↓ Container
A container is the running instance of an image.
Kubernetes
Kubernetes adds another layer:
IMAGE ↓ CONTAINER ↓ POD
Actually, more precisely:
Docker Image ↓ Pod ┌──────┴──────┐ ↓ ↓ Container A Container B
A Pod is the Kubernetes unit that runs one or more containers.
Most commonly:
Pod └── Container
So you can think:
| Term | Meaning |
|---|---|
| Image | Blueprint/package |
| Container | Running instance of image |
| Pod | Kubernetes wrapper/unit containing one or more containers |
| VM/Node | Machine where Pods run |
Example
Docker Image payment:v1 ↓ Kubernetes Pod ↓ Container ↓ Java Spring Boot running ↓ Listening on :8080
If Kubernetes needs 3 replicas:
Image: payment:v1 ↓ ┌──────┼──────┐ ↓ ↓ ↓ Pod 1 Pod 2 Pod 3 ↓ ↓ ↓ C1 C2 C3
So don't say "Pod = Container".
Better remember:
Container = the application running from an image.
Pod = Kubernetes' unit that contains the running container(s).
And yes, when someone says "instance", they often mean a running copy of something, but the exact meaning depends on context.
Almost exactly — just one correction. 👍
Docker
IMAGE ↓ Container
One image can be used to create one or many containers:
IMAGE payment:v1 / | \ ↓ ↓ ↓ Container Container Container
So an image is not limited to one container.
Kubernetes
A Pod can contain one or multiple containers:
IMAGE ↓ POD ┌──────┴──────┐ ↓ ↓ Container 1 Container 2
But in real-world Kubernetes applications, one Pod usually contains one main application container. Multiple containers in one Pod are commonly used when they need to work very closely together, such as a sidecar.
🧠 Remember
IMAGE ↓ can create many CONTAINERS POD ↓ contains one or more CONTAINERS
So:
Image → Container
Pod → Container(s)
And Kubernetes Pods themselves run on Nodes (VMs/machines).
Yes. Think of a Pod as the basic running unit in Kubernetes.
Why do we need a Pod?
Kubernetes needs something to manage your running application. Instead of directly managing individual containers, Kubernetes manages Pods.
Kubernetes ↓ Pod ↓ Container ↓ Your Application
Main uses of a Pod
1. Run your application
For example:
Pod └── Spring Boot Container └── Java Application
Kubernetes can start, stop, restart, and replace the Pod.
2. Give the application a network identity
A Pod gets an IP address inside the Kubernetes cluster.
Other Service ↓ Pod IP ↓ Container
Kubernetes Services can then route traffic to Pods.
3. Run multiple tightly coupled containers together
Sometimes two containers need to work together:
Pod ├── Main application container └── Sidecar container
They share things such as:
- Network
- Storage volumes
- Pod lifecycle
Example:
Pod ├── Java application └── Logging sidecar
4. Kubernetes can scale Pods
Suppose you need 3 copies of your application:
Kubernetes ↓ ┌───────┼───────┐ ↓ ↓ ↓ Pod 1 Pod 2 Pod 3 ↓ ↓ ↓ Container Container Container
If one Pod fails:
Pod 1 ❌
Kubernetes can create a replacement:
Pod 1 ❌ ↓ New Pod ✅
⭐ Most important
Don't think:
Pod = container
Think:
Pod = Kubernetes' wrapper/management unit around one or more containers.
And the hierarchy is:
Kubernetes Cluster ↓ Node ↓ Pod ↓ Container ↓ Application
For a normal Spring Boot application, you will very commonly see:
Node └── Pod └── Spring Boot Container └── Java Application
Why Pod exists: Kubernetes uses the Pod as the unit for running, networking, scaling, restarting, and managing your application containers.
Comments
Post a Comment