Technical Lead at a construction company with 1-10 employees
MSP
Top 5
Apr 7, 2026
Google Cloud Run is something I have worked with and I have experience using it. The platform is very user-friendly, simple, and easy to use. The portability is highly portable. Google handles its infrastructure very well, so no infrastructure management has to be taken care of by my organization. You pay only when your code is running; there is no traffic or instance, so cost optimization is automatically handled. These aspects are good for Google Cloud Run. Day-to-day, I rely on the deployment feature of Google Cloud Run, as we deploy our services on Cloud Run, whatever jobs we are deploying. Basically, for deployment purposes only, we use Google Cloud Run in our day-to-day service. I can say it is around 30 to 50% time saved by my team since moving to Google Cloud Run. In many regions, the free tier allowance is around 1,000 virtual CPU and 300,000 GB seconds per month, which helps in reducing the cost; you are billed only when your code is running. I can say that 30 to 50% costs have been saved, and we can prevent costs from going high during peak hours by setting the maximum instance count and ensuring CPU memory allocation matches close to the actual service usage. By doing this, we handle it effectively. For someone considering Google Cloud Run, my advice is to start with a small application since it is pay-as-you-go. Keep things microservice-based so that each service is a small service running without incurring high costs. Optimize for high concurrency and reduce the number of instances, so billing occurs based on request. Design applications to mount on top of cloud storage using Filestore or NFS-based persistent systems and use global variables and lean images; this will help someone run and build their application quickly and efficiently in Google Cloud Run. Google Cloud Run is a very good tool that I use for deploying applications; its ease of deployment, auto scaling features, and resource optimization are very nice features that help individuals deploy their apps and solutions into the cloud without any hiccups. You just need to configure a couple of services, and since it follows a stateless microservice architecture, the services running take charge only when idle; they do not incur charges otherwise. That is a great aspect of Google Cloud Run. Additionally, GPU performance issues, VPC, and GPU performance are main pain points, but those concerns come later; once you start, you do not need those things until your applications grow larger. I would rate Google Cloud Run around eight out of ten, which reflects ease of deployment, resource optimization, and good documentation; I give it an eight for these aspects. However, I cut two points for storage management and the way it responds to behaviors, as these are drawbacks such as cold start and the complexity of configuring VPC networks.
Container Management is essential for efficiently deploying and maintaining applications in microservices architectures, enhancing scalability and reliability.This practice involves orchestrating containerized applications to optimize resources and streamline application lifecycle management. Users gain improved control over infrastructure, enabling faster deployment cycles and simplification of complex cloud-native operations. Popular solutions offer automated updates, clustering, and...
Google Cloud Run is something I have worked with and I have experience using it. The platform is very user-friendly, simple, and easy to use. The portability is highly portable. Google handles its infrastructure very well, so no infrastructure management has to be taken care of by my organization. You pay only when your code is running; there is no traffic or instance, so cost optimization is automatically handled. These aspects are good for Google Cloud Run. Day-to-day, I rely on the deployment feature of Google Cloud Run, as we deploy our services on Cloud Run, whatever jobs we are deploying. Basically, for deployment purposes only, we use Google Cloud Run in our day-to-day service. I can say it is around 30 to 50% time saved by my team since moving to Google Cloud Run. In many regions, the free tier allowance is around 1,000 virtual CPU and 300,000 GB seconds per month, which helps in reducing the cost; you are billed only when your code is running. I can say that 30 to 50% costs have been saved, and we can prevent costs from going high during peak hours by setting the maximum instance count and ensuring CPU memory allocation matches close to the actual service usage. By doing this, we handle it effectively. For someone considering Google Cloud Run, my advice is to start with a small application since it is pay-as-you-go. Keep things microservice-based so that each service is a small service running without incurring high costs. Optimize for high concurrency and reduce the number of instances, so billing occurs based on request. Design applications to mount on top of cloud storage using Filestore or NFS-based persistent systems and use global variables and lean images; this will help someone run and build their application quickly and efficiently in Google Cloud Run. Google Cloud Run is a very good tool that I use for deploying applications; its ease of deployment, auto scaling features, and resource optimization are very nice features that help individuals deploy their apps and solutions into the cloud without any hiccups. You just need to configure a couple of services, and since it follows a stateless microservice architecture, the services running take charge only when idle; they do not incur charges otherwise. That is a great aspect of Google Cloud Run. Additionally, GPU performance issues, VPC, and GPU performance are main pain points, but those concerns come later; once you start, you do not need those things until your applications grow larger. I would rate Google Cloud Run around eight out of ten, which reflects ease of deployment, resource optimization, and good documentation; I give it an eight for these aspects. However, I cut two points for storage management and the way it responds to behaviors, as these are drawbacks such as cold start and the complexity of configuring VPC networks.