Cloud Run is a fully managed compute platform that enables you to run requests or event-driven stateless workloads without having to worry about servers. Yes, that's right; it's serverless, meaning you won't have to manage any server or VM instances yourself as Google will do it for you.

With Cloud Run, you only pay for the resources that you consume. You do not pay upfront; instead, you pay when your deployment is receiving traffic. We'll talk more about how Cloud Run's pricing works later, but for now, I will cover how Cloud Run scales.

The standout feature of Cloud Run would be its ability to scale from zero (0). Your application automatically scales up and down from 0 depending on the traffic it receives. How this works:

• Every service on Cloud Run contains containers that house your packaged code. You can define the maximum number of instances your service can use, ranging from 0 to 1000.

• Within the service, an internal load balancer efficiently distributes incoming requests across the available containers.

• As traffic increases, Cloud Run responds by automatically adding more containers to meet the demand. It dynamically manages the scaling process, creating new containers as needed.

• When the demand decreases, Cloud Run quickly adapts. It stops directing traffic to surplus containers, and if required, it can shut down these idle containers. This ensures cost-effective resource utilization as you're billed only for actual resource consumption.

Container-based vs source-based

Depending on your app's requirements, you can choose between a source-based or container-based approach with Cloud Run. If your primary goal is to quickly turn your code into a deployed HTTPS endpoint for user access, a source-based approach may be more suitable as it's quicker to set up.

On the other hand, if you opt for a container-based development approach, this is where Cloud Run shines. Packaging your code into a container allows Cloud Run to take care of numerous tasks, including setting up an HTTPS server. In this scenario, all that's required from you is to ensure your application can effectively handle incoming web requests.

Use cases

This is the section where we identify common use cases for using Cloud Run. It is not limited to just these use cases and in the section after we will cover when not to use Cloud Run.

1. Stateless Applications and Easy Deployment: Cloud Run is an ideal choice for stateless applications that don't require persistent storage. This simplicity in architecture allows for straightforward deployment with just a single command: gcloud run deploy.

2. Advanced Applications with Performance Boost: Even for more advanced applications like e-commerce websites, Cloud Run can be a suitable option. To enhance performance and security, consider enabling Cloud CDN to optimize content delivery and Cloud Armor to filter malicious inbound traffic using content-based policies.

3. Microservices at Scale: Cloud Run is well-suited for running microservices. You can deploy up to 1000 microservices within a project, utilizing various communication protocols such as RPC, REST, or gRPC. Additionally, Pub/Sub can be used to forward HTTP requests to a Cloud Run service, facilitating communication between microservices.

4. Internal Organization Applications: Large organizations often have internal applications primarily used for their teams. While these applications may not require high availability, they can benefit from Cloud Run's ability to run indefinitely. Cloud Run doesn't impose a limit on how long your application can run, thanks to its serverless architecture.

5. Cost-Effective Data Processing: Cloud Run is a cost-effective choice for data processing applications. You only pay for the resources used during actual processing, making it an efficient option for tasks like data transformation, analysis, and batch processing.

6. Event-Driven Applications: For event-driven applications, Cloud Run provides an excellent framework. Implementing Pub/Sub allows you to manage and process events effectively, ensuring that your application responds dynamically to incoming events and triggers.

Other options

Google has many other options to offer too, the main ones are:

• Compute Engine (uses server)

• Google Kubernetes Engine (uses server)

• Cloud Run (serverless)

• Cloud Functions (serverless)

1. Long-Running Jobs: If your application involves running particularly long and resource-intensive jobs, especially those exceeding an hour in duration, and breaking them down into smaller tasks isn't feasible, you might want to consider alternative Google Cloud services like Compute Engine or Google Kubernetes Engine (GKE). This is because Google Cloud Run is designed for stateless, short-lived workloads.

2. Massive Data Processing: Earlier did mention that Cloud Run is good for processing data however for scenarios requiring the processing of massive data loads, Google Cloud Dataflow is better suited. Dataflow offers powerful data transformation capabilities, parallel processing, and auto-scaling, making it an excellent choice for big data workloads.

3. Off-the-Shelf Applications: If you are dealing with off-the-shelf applications or legacy software that requires a consistent and long-running environment, Cloud Run may not be the best fit. Google Compute Engine and Google Kubernetes Engine offer more control and stability for these types of applications, ensuring they remain available and operational.

4. Non-Request Handling Applications: If your containerized or cloud-based applications don't require processing incoming HTTPS requests or any other type of backend logic, Cloud Run might not be the most efficient choice. For example, applications designed exclusively for background data processing, scheduled batch jobs, or tasks that don't involve handling HTTPS requests may find better suitability on platforms like Google Compute Engine or Google Kubernetes Engine, which are optimized for stateful and non-HTTPS use cases.

5. Stateful Applications: Applications that require maintaining state or data persistence are better suited for Google Compute Engine or Google Kubernetes Engine. These platforms allow you to manage stateful workloads effectively and provide more control over the environment, including data storage and application state management.

How to set it up

cloud.google.com/run/docs/quickstarts

This is Google's official starting guide for Cloud Run, and it's an excellent resource to refer to if you're new to this platform. The guide offers step-by-step instructions, best practices, and examples for getting started with Cloud Run. It's a valuable resource for those looking to deploy applications quickly and efficiently.

In the future, I'll also release more detailed blogs on deploying applications using different programming languages like Go, Node.js, and possibly Java.

Be sure to follow me to stay updated and not miss these upcoming guides.

Pricing

The pricing model on Cloud Run is unique. You only pay for the system resources you use while a container is actively handling web requests, with a granularity of 100 milliseconds. Importantly, you're also charged during the container's startup and shutdown phases. The beauty of this model is that you do not pay for anything if your container remains idle and isn't handling requests.

Furthermore, Cloud Run offers a generous free tier allowance, ensuring that many users can run their applications without incurring costs within certain usage limits. It's worth noting that there is a small fee for every 1 million requests you serve. Additionally, pricing can vary by region, so it's advisable to check the regional pricing details to understand the cost implications based on where your application is deployed

Watch out

Cloud Run is a fantastic platform that can automatically scale from serving just a few users to handling massive traffic loads. However, there's an issue that often goes unnoticed: infinite loops in your code. Picture this – you have a function in your app that's triggered when you upload an image to a storage bucket. It's easy to unintentionally create a loop here, and that can lead to your app endlessly consuming Google's cloud resources.

Now, here's the catch: Unlike Compute Engine and Google Kubernetes Engine, which use virtual machines and have predictable pricing based on allocated resources, Cloud Run and Cloud Functions operate differently. With these serverless platforms, you need to be more mindful of your code's behavior.

But don't worry, there are settings you can configure to prevent runaway resource usage. For instance, you can adjust your auto-scaling settings to limit the maximum number of instances that Cloud Run can create, ensuring it doesn't go beyond what you're comfortable with. Plus, Google provides alerts when there's a sudden spike in your app's traffic, so you can react promptly.

It's important to note that these considerations aren't unique to Google's Cloud Run; they apply to many other cloud platforms as well. The key factor is Cloud Run's auto-scaling feature, which can make the impact of infinite loops more pronounced and something you'll want to be on top of.

How to Burn Money in the Cloud // Avoid AWS, GCP, Azure Cost Disasters

This is a great video that goes over how to not burn money in the Cloud.

That's all!

Thank you for reading this blog. I hope you now understand the key features of Google's Cloud Run and its best use cases.

And be sure to look at my other blogs on terminal3

Feel free to message me on LinkedIn: My LinkedIn

You can also email me here: thedoublewaysproject@proton.me