Google Cloud Run

Let's a small team ship faster with less operational overhead.

The main use is to host an image processing service. This involves generating large quantities of thumbnails, dividing large map images into tiles and extract geometries in floorplan PDF files. Using Cloud Run, we were able to reduce costs compared to using serverless solutions. It works very well for long processing times, with a 24-hour time limit per job. It's very practical and easy to deploy, eliminating the need for advanced DevOps knowledge.

It is suitable for serving applications in Docker images, as it has very good abstraction compared to Kubernetes, bringing more simplicity to deployment. It is also ideal for workloads that require a lot of processing time, as its limit is 24 hours.It is not very suitable for microservices applications with shared state, as communication between jobs is still somewhat limited. Another point is that configuring very complex workloads is still not easy to do using the tool.

We're testing the execution of a container version for our Vistadash product. This allow us to estimate costs in a controlled environment, which is also production ready.

The amount and detail of steps required to publish a container in Cloud Run are well suited for a production ready application. However, for testing purposes it may seem a bit too verbose. It would be desirable an option that would allow to run the container directyl from the registry, similar to other cloud providers.

We use a Docker container that converts images to smaller sizes and makes map tiles with large images for indoor maps for navigation. Using just serverless functions was not enough because of the time limit. Making conversions with images takes running time that was only supported using Google Run, which increases the time limit to 24 hours.

It's more suited for having tasks that involve calculation or conversions, like converting big images and tiles. Have tasks that take up to 30 minutes for each execution, Cloud Run is well-suited. But when considering smaller tasks the do not take so much time using Cloud Run is not indicated. Using Google functions is more suited.

We use Google Cloud Run in our organization to deploy the majority of containerized applications into it without owning any infrastructure from our end, which is one of the biggest relief with regards to Google Cloud Run because it takes care of auto scaling, manages latency issues, along with good redundancy with very solid backend support. post Cloud Run major infra management has been reduced to core for our team also it gives lot of savings.

if you dont want to take tension of infrastructure and scalability and managing DC this is the best approach and developers and concentrate more on coding part that servers, cloud run will take care of all that also it makes lots of savings in terms if handing infra. it does auto sclaing and more reliable and easy deployments.

Most of our platform services are deployed as Google Cloud Run services.

Recently, we have also turned towards Google Cloud Run jobs for performing flow run tasks managed by a job server.

Being an early startup, using Google Cloud Run helps us to keep a tab on our cloud costs based on usage.

Google Cloud Run enables microservices architecture as multiple cloud run services or jobs can be deployed while keep the cloud costs optimal based on actual usage.

Google Cloud Run services support auto scaling which helps satisfy performance requirements of applications.

Google Cloud Run services and jobs are integrated with Google cloud logging which simplifies troubleshooting of application errors.

We have been setting up some new micro services. As the load on them is not consistent throughout the day, we think that going serverless is the right decision. Also, we didn't want to deal with Kubernetes, at least at the moment. That makes Google Cloud Run our obvious choice.

If your cloud provider of choice is GCP, then Google Cloud Run is the obvious serverless solution. Such as our case, GCP has been selected over other providers e.g. AWS for certain reasons, then we have to deal with the disadvantages of Google Cloud Run, compared to AWS Lambda.

We use Google Cloud Run to host Google Tag Manager server side scripts.

To host GTM server side script, it is perfect and almost free.

We use Google Cloud Run to run various applications such as our NextJS front-end web app that is served to public users as well as for running various backend applications that typically perform async tasks or run our API infrastructure. Google Cloud Run helps make it really easy to scale up or down and easily deploy docker images.

Cloud run is well suited when you need to spin up a dockerised application or any stateless application like a web app or backend API. Its not so great when you have to run long-running or stateful applications (but I think that's well documented). I would also say its preferred for applications or tasks that don't require massive amounts of computing or RAM. Its better at running smaller applications that are horizontally scaled.

We use Cloud Run to deploy our isolated service application(s) that are logically far off from our main application but also share some of the resources and database tables with the main application. We use it to "fire and forget" out small serverless projects that don't need periodic maintenance and taking care of all the while maintaining performance and separation of concerns

For scenarios where you need an isolated workspace and application namespace, it is very well suited. It can run up a serverless instance of your application in seconds and will give strong guarantees over its runtime given that all dependencies were taken care of. For entangled workflows, its recommended to use a server/on prem solution