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
How is this different than container hosted on Azure app service?
For example there’s no resource group to (over)allocate.
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?
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.
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.
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.
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.