Google Cloud Run Reviews & Insights

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

In our organization we use Google Cloud Run, and now Cloud Run functions, for all kinds of applications. We use it as microservices for API applications, we use it to deploy GenAI application running with Langchain, and all kinds of other stuff. The big advantage of Cloud Run is that it is almost self managed, we only it to create our Docker container, and specify some configuration about memory, cpu, and instances, and all the rest is managed by Google. Rarely or never had problems with Cloud Run itself.

Microservices and RestFul API application as it is fast and reliant. Seamless integration with event triggers such as pubsub or event arc, so you can easily integrate that with usecases with file uploads, database changes, etc. Basically great with short-lived tasks, if however, you have long-running processses, Cloud Run might not be idle for this. For example if you have a long running data processing task, other solutions such as kubeflow pipelines or dataflow are more suited for this kind of tasks. Cloud Run is also stateless, so if you need memory, you will have to connect an external database.

We participated in a trial of modernizing our continuous integration and deployment methods and how we would orchestrate the various resources that need to stand up and down during the different pipelines dynamically. We had to re-architect parts of these pipelines to accommodate the new stateless, serverless infrastructure paradigm. We ran some tests over about a quarter on this and similar offerings.

As our product is event-driven, we were well-versed in this method of using Google Cloud Run. We had various checkpoints in our pipelines during a build, sending events to messaging systems or recording/auditing some steps very well suited to stateless event processing, such as was provided. That said, I don't think participating in a build pipeline is the most effective use of Cloud Run.

We use it for running simple web applications that aren't ready to be brought into the full deployment pipeline.

For prototyping or quick deployment, it works as an interesting step between containerized deployment (Kubernetes) vs pure Compute Engine (raw servers).

It's not well suited for Kubernetes shops, or for teams that would prefer more hardware control.

We use Google Cloud Run to host small parts of our websites and the backend systems for our mobile apps. It helps us deploy and manage these pieces without worrying about servers. Cloud Run makes it easier for us to build, scale, and maintain our applications, saving time and money along the way.

Any application small medium to large sizes, mainly i used if for small hr application to push multi builds in different testing environments to prod usge by end users

In the evolution towards digital products, high availability becomes a critical requirement to enhance the user experience of our customers. In the healthcare industry, demand is often affected by seasonality (people get sick more in winter), so having robust applications built on auto-scalable infrastructure minimizes availability risks, allowing progress on other business and user requirements.

Integration with Google Cloud Run is appropriate when investment in infrastructure is prohibitively expensive, such as having a building contingency for high availability. Additionally, since it is auto-scalable, costs are calculated based on resource usage, avoiding expenses from idle infrastructure.The handling of sensitive information could be a disadvantage, as it remains in the hands of third parties. On the other hand, I wouldn't use this solution for applications that manage states since there is no disk-level persistence.

We use Google Cloud Run for our dockerized Node.js-based GraphQL backend. It's perfect for horizontal scaling in a straightforward way and facilitating branch deployments via its revisions.

If you have a standard backend that needs to serve frontend requests or requests from other clients and it can be in wrapped in a Docker image, it's pretty perfect. The auto scaling works excellently and supports branch deployment and other deployment strategies really well.

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.