A first look at Google Cloud Run

Google has launched Cloud Run, a new solution for running serverless applications based on Docker containers, this month at its Cloud Next ’19 conference. What we can say now is this is an important step for serverless computing — deploying to Cloud Run is much easier than running containers on Kubernetes. It also has no architectural restrictions, which Lambda functions do. Semaphore provides seamless CI/CD pipelines to build, test and deploy applications to Google Cloud Run.

Imported from Disqus

Muhammad Junaid2 years ago

How is this different than container hosted on Azure app service?

Marko Anastasov Muhammad Junaid2 years ago

For example there’s no resource group to (over)allocate.


robwaldron2 years ago • edited

This blog seems misinformed. AWS Lambda and Azure Functions provide more than just run small functions. You can host a full ASP.NET Core service or NodeJS Express app in Lambda for instance. Cloud Run sounds nice, but isn’t offering anything groundbreaking. Maybe Cloud Run is more akin to AWS Fargate?

Marko Anastasov robwaldron2 years ago

No, with Fargate you start by provisioning a cluster (check this)
With Lambda you’re programming for Lambda specifically, and have to deal with CloudFormation, API Gateway… again UX that can be improved.


Jason robwaldron2 years ago

Worth pointing out that AWS Lambda limits concurrent requests per instance to 1 (as does Google Cloud Functions). So while you can run an entire webapp in a function, it may not be the most optimal use of resources, and you typically hit a lot more cold starts which, if your app is large, can be slow. Cloud Run allows up to 80 concurrent requests on an instance (you can also force it to be 1 if you like). I believe Azure does allow concurrency to an instance.


Martin Dingus2 years ago

The container listens for HTTP requests on port 8080.

This is incorrect. Cloud Run uses 8080 by default, but explicitly states you should not hard-code 8080, and should use the $PORT environment variable provided to the container instead.

Marko Anastasov Martin Dingus2 years ago

Thanks for pointing that out. I don’t see how it’s incorrect as the port is “always set to 8080” but I’ve updated the article to recommend $PORT.