Your web server on Cloud Run will look the same or identical to your web server on Fargate, but in terms of an computational and operational model, Cloud Run is more similar to Lambda and Cloud Functions.
Fargate is a service that removes the need to manage VMs underlying a container cluster. You still have container orchestration on top of it, and full flexibility in terms of what each container can do, both computationally and on the network; Fargate has no opinions or knowledge of what’s running inside your container. You can have completely idle containers, Fargate doesn’t mind.
Lambda provides a way to attach code to an HTTP endpoint. Lambda creates and uses instances of your code in response to requests, and understands when instances of your code are responding to requests. The lifecycle of instances of your code is tied to the requests Lambda receives. When no requests are being processed, no instances of your code are running.
Cloud Run provides a way to attach container images to an HTTP endpoint. Cloud Run creates and uses container instances in response to requests, and understands when your container instances are responding to requests. The lifecycle of your container instances is tied to the requests Cloud Run receives. When no requests are being processed, no container instances are running.
If you’ve already got a containerized web server that you’re running on Fargate or GKE, and you’ve set up a load balancer and autoscaling, etc., then moving to Cloud Run is easy, and moving to Lambda or Cloud Functions is a bigger, more disruptive step. And that initial move to Cloud Run is great! You’ll have the same functionality with a lot less hassle. What I intended to communicate in the article is that it shouldn’t be seen as equivalently good to Lambda or Cloud Functions, that running a full web server inside a container with Cloud Run should not be what you reach for next time.