[tlarkworthy]

Cloud Run is an alternative to fly.io that scales to zero so it can be much cheaper but with added cold starts.

[aenis]

But, to get a cloud run based setup:

- you need an elb - and this is not cheap (if you have an efficient backend, the elb will dwarf compute costs) - no persistent volumes, and you are encouraged to use gcs or firestore - each region requires a new deployment. No big deal but certainly not super easy to automate, esp. given the need to run behind an ELB (which you need on gcp to have a WAF) - google sdks for some languages suck big time. Most of python sdk is not async friendly, unbelievable as it seems.

I do use cloud run for projects big and small, and rather like it, but its hardly a competitor to fly.io imho.

[tlarkworthy]

Yeah the load balancer bit sucks, I forgot about that. I use terraform for multi region deploys but yeah, the load balancer is a major cost.

[bobnamob]

Isn’t the whole appeal of fly that they’re geolocated near your users, reducing latency so you can use fancy serverside rendering stacks like Phoenix?

Cold start latency kinda ruins that no?

[aenis]

Latency on cloud run is not an issue, in my experience (been using it around 4 years now, on a fairly large scale).

Its generally fast as is, and if you want to pre-allocate a minimum # of instances, cold starts are less of a problem (basically only if you are suddenly stampeded by a spike in traffic). But the whole smart routing and localized storage concepts are left for you to implement. You can have a bunch of cloud run services behind an ELB that does geo-proximity based routing but firestore is region-bound, and cloud spanner can be very expensive. Not saying there are no workarounds but it seems to me fly.io offers a much lower cost of entry here.

[tlarkworthy]

No cloud Run instance supports 1000 concurrent users and stays active for 15 min after no traffic, so only a small subset of users should ever hit a cold start.