[015a]

Here's something very specific I've been thinking about recently.

I think Google Cloud Cloud Run is obscenely ahead of its time. Its a product that's adjacent to so many competitors, yet has no direct competitor, and has managed to drive a stake into that niche in a way that makes it such a valuable product.

Its serverless, but not "Lambda Serverless" or "Vercel Serverless" which forces you to adopt an entirely different programming model. Its just docker containers. But its also not serverless in the way Fargate or ACS is "serverless"; its still Scale to Zero.

There's a lot of competition in the managed infrastructure space right now (Railway, Render, Fly, Vercel, etc). But I haven't seen anyone trying to do what Cloud Run does. Cloud Run has its disadvantages (cold starts are bad; it also could be a great fit for background workers/queue consumers/etc, but Google hasn't added any way to scale replicas beyond incoming HTTP requests yet).

But the model is so perfect that I wish more companies would explore that space more, rather than retreating to "how things have always been done" ("pay us $X/mo to run a process") or retreating to the much more boring "custom serverless runtime", "your app is now only a 'AWS Lambda app' and cant run anywhere else congrats".

[mrkurt]

(I am bias because I work on Fly.io)

Fly Machines are more powerful than Google Cloud Run IMO. You can treat them like cloud run, or manage them directly and implement your own Serverless model.

Our PaaS orchestration is implemented entirely I. The client CLI, and it manages Fly Machines directly: https://fly.io/docs/machines/

[ajcp]

At the risk of being on the outside here, I'd have to agree.

To go a bit further I'm honestly quite interested(?) in how CGP has sought to differentiate itself from the two other providers by offering this kind of "plug and play" feel to cloud. Certainly there is value to be gained from the absolutely granular service offerings of AWS/Azure, but there's a point when it starts to feel like all I'm doing is building control towers for island landing strips.

I just want my cloud providers ML service to talk to the data lake on the same cloud tenant without having to architect my way through 15 network nics, 30 service accounts, and 4 VDI...

[latchkey]

Cloud Run is great, but imho Cloud Functions are even better. It is just a simple http handler.

The entire deployment can be easily defined in github actions. Combine that with Cloud Tasks and a Cloud SQL Postgres instance and you have a near infinitely scalable solution.

I ran a system like this where over 30k servers across 7 different data centers all over the US, were hitting cloud function endpoints 24/7 with 30-50+ RPS and I never had a single failure or outage over multiple years. Even better, the whole thing never cost more than about $100/month.

[maccard]

Azure has container _instances_ - https://azure.microsoft.com/en-gb/products/container-instanc...

DigitalOcean iss not wildly far off it either.

ECS + Fargate is the closest AWS has to it, but you need to do IAM and Networking to utilise it. If you're in AWS already, it's pretty good, albeit with some frustrating limits

[015a]

Yup my bad, I meant ACI, not ACS.

Correct me if I'm wrong, but these are actually not close to Cloud Run. Cloud Run's differentiator is its scaling metric; it scales with incoming requests, and has strict configuration to assert that each replica only handle N concurrent requests. You could maybe get something like this set up on ACI or Fargate, but it'd require stringing together five or six different products. You can also definitely wire up those to autoscale on CPU%, but (1) this is not scale-to-zero, and (2) CPU% kinda sucks as a scaling metric, right? Idk I've never been happy with systems that autoscale on CPU%.

[jiggawatts]

Azure has mostly implemented this now. ACI was a single instance, but they have scalable Container Apps now. These are just a dumbed down abstraction hiding a managed Kubernetes cluster beneath that you never interact with directly.

[kastden]

Container Instances is bad though, and you'll regret using it. There is Azure Container Apps but it requires some more setup in advance.

[lijok]

Maybe I’m misunderstanding something but what you’re describing is what AWS Lambda has been able to do for a long time now. You can run an api in a docker container with no Lambda-specific code.

[dmattia]

My understanding is that your docker image must have the lambda runtime interface client installed on the image in order to work.

It's not a huge step usually to add the RIC, but it's a bit more tied in to AWS than CloudRun is, which can run arbitrary docker images, if I understand.

[lijok]

That's right - you have to package awslabs/aws-lambda-web-adapter into your docker image which proxies the API-GW/ALB requests through.

[meowtastic]

Isn't AWS App Runner similar?