Software Engineering

---

Kubernetes: A Strong Motivator to Explore Cloud Run

I once joined a team working on a distributed architecture application. It included a frontend app, a backend (later microservices), and an API Gateway. The applications were deployed on Kubernetes and ran smoothly. However, there was one major issue with Kubernetes—not with the tool itself, but with the lack of infrastructure expertise within the team. The team was mainly comprised of frontend developers with a knack for backend work, but no dedicated DevOps.

In theory, the setup was such that the application development team would focus on app development, while the infrastructure team managed Kubernetes. In practice, this meant that whenever the application team needed to tweak Kubernetes, they had to wait for days or even weeks.

I wondered why the team had chosen Kubernetes when no one was well-versed in its advanced concepts. I didn’t get an answer, but it was a valuable lesson on the importance of selecting the right tools for the job.

Fortunately, we had the opportunity to experiment with Google Cloud Run, enabling the application team to break free from dependence on the infrastructure team. We decided to deploy one service on Cloud Run instead of Kubernetes.

Understanding Cloud Run

Google Cloud Run is a fully managed serverless platform offering the following features:

• Simplifies running stateless, request-driven containers.
• Supports a wide range of programming languages and integrates seamlessly with other Google Cloud services.
• Automatically scales to handle fluctuating traffic.
• Pay-per-use pricing ensures cost-effective resource utilization.

What is Cloud Run?

Cloud Run removes the complexity of running stateless HTTP containers by providing a fully managed serverless environment with automatic scaling and pay-per-use pricing. Compatible with many programming languages, Cloud Run allows developers to focus on building applications without worrying about infrastructure management.

Deploying containerized applications is straightforward—just build an image and let Cloud Run handle the rest, from scaling to networking.

When I first piloted a microservice on Cloud Run, I used a prebuilt Docker image and a few lines of Terraform to deploy the service and experiment. Deploying another service that required integration with Cloud SQL was trickier but manageable—a promising sign since I’m not a DevOps engineer. This wouldn’t have been as quick or easy on Kubernetes.

---

---

Benefits of Using Cloud Run

Cloud Run offers a flexible, scalable, and cost-effective platform for deploying containerized applications.

Your responsibility is to create and build the image, while Cloud Run handles the rest. You can build images in various ways, such as using Cloud Build. When deploying my first workload on Cloud Run, I set up a private Docker repository in GCP and configured a GitHub Actions pipeline to build my image. While not strictly necessary, the specifics of my project required it. The simplest approach is using Cloud Build, which can automatically build an image, for example, after a push to the main branch.

Another advantage of Cloud Run is its compatibility with various programming languages, enabling you to leverage mature tech stacks for your projects. I deployed an application in Node.js, but by default, Cloud Run also supports Go, Java, Python, Ruby, .NET Core, and PHP.

The pay-per-use pricing model ensures you only pay for resources you use, making it an attractive option for businesses of all sizes. My project had low traffic, meaning we didn’t pay anything for Cloud Run as we stayed within the free usage tier. However, be cautious—there are numerous stories of serverless costs skyrocketing unexpectedly. Carefully evaluate if this pricing model suits your use case and scale.

---

Use Cases for Cloud Run

Cloud Run is an excellent choice for various scenarios, including:

• Web applications
• APIs
• Microservices
• Event-driven services

Whether you’re working on a simple web app or a complex microservices architecture, Cloud Run’s stateless container deployment capabilities offer scalability and performance for your application.

---

My Journey from Kubernetes to Cloud Run

As the tech leader, I was tasked with implementing the first service using Cloud Run. Additionally, I had to ensure that both the new service and the legacy monolith were hidden behind a new API Gateway.

Challenges Along the Way

In theory, migration is straightforward, but in reality, additional circumstances often turn simple tasks into significant challenges.

Architects often fall into the trap of using familiar tools instead of selecting the best solution for the specific problem. This phenomenon is called the “golden hammer,” where one technology is favored for solving every problem, even when better alternatives exist. I encountered this issue with managed services. We migrated everything at once to managed services.

Simultaneously migrating the backend from Kubernetes to Cloud Run and the API Gateway from a custom Node.js service to Google’s managed API Gateway was daunting. From this project, I learned that tackling multiple large tasks simultaneously is a recipe for disaster.

---

Lessons From This Journey

1. Cloud Run Isn’t As Simple As It Seems

Although Cloud Run is marketed as an easy serverless solution, I quickly realized that entering this space without fundamental knowledge of cloud and DevOps is challenging. We had to learn a lot—from containerization basics to cloud networking and secret management. While it wasn’t rocket science, it wasn’t exactly a walk in the park, either.

2. Economics Matter

In our case, with a small-scale application, Cloud Run turned out to be virtually free. We stayed within the free tier and didn’t have to worry about costs. However, beware—serverless costs can skyrocket with increased traffic. I’ve seen projects where serverless bills soared higher than a Falcon Heavy rocket. Carefully assess the economics of serverless solutions for your scale and needs.

3. Integration with Google Cloud Ecosystem

Cloud Run integrates seamlessly with other Google Cloud services. Whether it’s Pub/Sub for event handling, Cloud SQL for databases, or Secret Manager for sensitive data, everything works like clockwork.

4. Resistance to Change

I noticed an interesting dynamic—DevOps specialists and Kubernetes experts often viewed Cloud Run as the “younger sibling” trying to play with the adults. There was skepticism, partly driven by fears about job security. After all, why would teams need DevOps if developers can manage deployments themselves?

5. The Value of Developer-DevOps Hybrids

Developers interested in DevOps, Cloud Run, and Terraform are invaluable. In my team, we had two such individuals, and they were instrumental in facilitating a smooth migration and building knowledge within the team.

---

When Is Cloud Run a Good Choice?

1. When Your Team Lacks Kubernetes Expertise

Kubernetes is a powerful tool, but do you always need a tank to buy groceries? If your team comprises mainly frontend and backend developers without deep Kubernetes or infrastructure as code knowledge, Cloud Run can be a great alternative.

In one project, I worked with skilled frontend and backend developers who could build amazing apps. However, when it came to tweaking Kubernetes configurations, they’d ask, “Can someone help us with ingress configurations?” With Cloud Run, much of this can be handled independently.

2. When Dependence on DevOps Becomes a Bottleneck

In many companies, DevOps teams are small but support numerous product teams. This often means waiting weeks for Kubernetes configuration changes.

Cloud Run can liberate teams from this dependency. Developers can deploy and manage their services without waiting for DevOps. It’s like moving from a hotel (where you depend on staff for everything) to your own apartment (where you make decisions yourself).

3. When You Need a Quick MVP

I recall wanting to test an idea quickly. With Cloud Run, I launched the first version of my app in one afternoon.

Cloud Run is ideal for rapidly validating ideas—you don’t need to design an entire infrastructure or worry about scalability. Deploy your app and see if there’s demand. If the idea succeeds, you can always transition to a more advanced solution.

4. When Your Application Is Relatively Simple and Stateless

Cloud Run excels at hosting stateless applications that can scale horizontally. For simple backends, image-processing services, or CRUD apps, Cloud Run is perfect.

However, if your app requires complex state management, long-lived connections (like WebSockets), or advanced routing, consider other options.

Bonus: When You’re Counting Every Penny

Cloud Run’s pay-per-use model is excellent for small to medium-sized applications. If your app has low traffic, you might pay next to nothing (or nothing at all, thanks to the free tier). This makes it ideal for startups and small teams needing to control costs.

Keep in mind, though, that “serverless” doesn’t always mean “cheaper.” At scale, traditional hosting might be more cost-effective. But until then, Cloud Run can save significant infrastructure expenses.

---

Potential Pitfalls

Not everything is as rosy as the Google Cloud advertisements might suggest. During my journey with Cloud Run, I encountered several pitfalls worth considering before migrating:

Complex Setups Aren’t Always Straightforward

When it comes to advanced configurations, Cloud Run can reveal its more challenging side. Multi-region setups? Load balancing? These aren’t always a simple “click deploy and forget.”

For instance, I had to configure an application across two regions with a load balancer. While Google’s documentation is solid, I spent several days wrestling with the configuration and implementing it using infrastructure as code (IaC). Additionally, each region requires a separate Cloud Run instance, which complicates deployment management.

Costs: The Devil Is in the Details

Cloud Run costs can be like driving an old BMW with a large engine—fun at first, but potentially shocking by month’s end, especially if traffic surges.

The internet is full of horror stories about serverless costs spiraling out of control. To avoid this:

• Set budgets and alerts.
• Monitor resource usage regularly.
• Understand the pricing model before moving to production.

Monitoring and Debugging

Monitoring and debugging in a serverless environment differ from traditional applications. You can’t just SSH into a server to inspect issues. Instead, you rely on Google Cloud tools, which require a different mindset and knowledge.

Best practices include:

• Setting up proper logging from the start.
• Utilizing Cloud Monitoring.
• Configuring appropriate alerts.
• Preparing dashboards for key metrics.

For me, the biggest challenge was shifting from a “server mindset” to a “serverless mindset.” However, once I adapted, I found Cloud Run’s monitoring tools quite user-friendly.

---

Conclusion

Cloud Run is a fantastic tool, but like everything in IT, it’s not a silver bullet. It’s ideal for teams looking to move away from Kubernetes and DevOps dependency, especially for simpler applications and MVPs. Kubernetes remains a robust solution and will likely continue to dominate container orchestration, particularly in larger organizations.

The choice between Cloud Run and Kubernetes depends heavily on your organizational strategy—whether you prioritize speed and simplicity or full control and advanced orchestration capabilities. There are no bad choices, only different contexts and needs.

---

If you’d like to stay updated on my experiences with cloud solutions and application architecture, subscribe to my newsletter. I share practical insights and thoughts that can help you make better technology decisions.