First off, thanks for the overview text. I really hate how many tech people just assume ‘you’ know what they mean because ‘they’ know what they mean. It’s like they’re trying to accentuate the autistic stereotypes!

>Pretty much what I have wanted since I first started learning about Docker.

Why? I have a use for lambdas in an application I’m working on. But I don’t really get why you want stateless containers that spool up and down on demand. Is it for things like “I need this entire existing program to run and can’t refactor it to a lambda itself”? I only need to do some API processing and data we work, so I’m not entirely sure what starless containers are for. Might be a dumb question!

Go Cloud Run: https://cloud.google.com/run/docs/quickstarts/build-and-depl...

Vs. Go Lambda: https://docs.aws.amazon.com/lambda/latest/dg/go-programming-...

The Cloud Run steps aren't that complex and you get something you can easily run on your local computer too.

You can definitely run Lambda functions locally, too: https://docs.aws.amazon.com/serverless-application-model/lat...

Good point. Though you still have “the cloud” calling your function versus truly having everything local.

As someone who works in Data Engineering, I'm a big fan of cloud-based docker containers with services like AWS Fargate/Google Run. It allows us to be able to pay for resource use rather than provisioning. For the longest time I had to justify the additional cost and constant maintenance of an n-th server just to accommodate for capacity at peak hours. Anecdotally, most of our batch jobs don't need high availability, so the startup time of a server-less docker is an acceptable trade-off to parallelism.

> It allows us to be able to pay for resource use rather than provisioning.

Not arguing against the choice, but at some level, you are paying for the provisioning costs of the cloud provider. The higher initial costs of provisioning is what you may be escaping, and instead paying on an ongoing basis (as if you’re leasing equipment and services).

Once your needs scale significantly, cloud providers would end up being quite expensive if your load is not highly variable.

It's compatible with Knative, which is easy to set up in GKE, so you can migrate loads over to that if you want more control over your compute costs. And of course, you can run Knative outside of GKE, too.

Disclaimer: I work on GCP but have only touched Cloud Run/Knative a little bit.

> if your load is not highly variable

Most real-world loads are in fact pretty variable.

You know you can also boot instances that bill at hour and less granularity right? Billing is probably the least compelling argument to a service like this.

Can it do serverful things like run cron jobs, suffer no warmup time, maintain efficient connections to Postgresql?

cron jobs in knative: https://www.knative.dev/docs/eventing/samples/cronjob-source...

from the description you will suffer warmup time, you just need to start a http server withing 4 minutes.

also cron jobs do not work since the computations only work as long as the container is running.

it also still does not support .net since gvisior does not support it :(

https://cloud.google.com/run/docs/reference/container-contra... https://cloud.google.com/run/docs/issues

it's basically AppEngine v3 (without long running stuff)

This seems like a competitor more to Fargate than to Lambda, right?

With Fargate you have containers running all the time, and you pay for that....from what I've seen of Cloud Run, you just pay when you're actually serving requests

With Cloud Run you're only paying for resources used, and with Cloud Run on GKE you're paying for the underlying cluster [1]. This also gives you the flexibility to optimize costs by shifting workloads between the two if desired.

[1] https://cloud.google.com/run/pricing

Closer to Lambda from a lifecycle perspective, because your code runs only when there’s a request (and you’re billed only during requests).

But also Closer to Fargate from a programming paradigm perspective, as the deployment unit is “container image”.

Definitely seems like it.

FYI - I just posted a review video where I walk through Cloud Run doing some demos. Check it out at: https://sysadmincasts.com/episodes/69-cloud-run-with-knative

So what OpenFaaS/OpenFaaS Cloud has been doing for 3 years :-)

With a subtle difference like you don’t have to manage the infrastructure that runs the machinery. :)

it's like appengine, but better!