Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Fly.io: The reclaimer of Heroku's magic

christine.website

Post reply on HN
Print view View original

51–60 of 320 posts

Re: Fly.io: The reclaimer of Heroku's magic

#51

Post by st3fan »

tptacek wrote: post #28
st3fan wrote: post #25

For me the missing bit in Fly is scheduled tasks. I know how to solve this by spinning up an app that runs permanently as a scheduler, but basic cron-like scheduling should be part of the platform IMO. All other FaaS-like service do this.

I'd love to do this, if for no other reason than I hate working with cron. What would you use it for? What would the ideal version of this feature look like for you? What kind of apps would you be more easily able to ship? Is it mostly so you wouldn't need to keep a single tiny running VM sitting around running cron?

Some apps are just that - a periodic task. Nothing more. Ideally a task project would have a git repo with a short fly.toml, a requirements.txt and a main.py. (In case of Python. I'm not familiar with using other languages on fly.io) I don't think it needs to be more complicated than that.

Re: Fly.io: The reclaimer of Heroku's magic

#52

Post by sanjayio »

atonse wrote: post #18
2c2c2c wrote: post #12

There's a lot of chat about fly.io on HN. possibly just because the founders and friends are posters here. Is there any in depth comparison between them and render.com ?

I think it is because they are refreshingly open about their stack and people love their writing tone. And the architecture seems solid.

Agreed, really enjoyed their tone on explaining SQLite and litestream.

Re: Fly.io: The reclaimer of Heroku's magic

#53

Post by DizzyDoo »

tptacek wrote: post #28
st3fan wrote: post #25

For me the missing bit in Fly is scheduled tasks. I know how to solve this by spinning up an app that runs permanently as a scheduler, but basic cron-like scheduling should be part of the platform IMO. All other FaaS-like service do this.

I'd love to do this, if for no other reason than I hate working with cron. What would you use it for? What would the ideal version of this feature look like for you? What kind of apps would you be more easily able to ship? Is it mostly so you wouldn't need to keep a single tiny running VM sitting around running cron?

The sort of things I have had running on a schedule (using Celery[0] or something like it) are sending a set of emails at a certain time, running a report or generating the data for reports, even running a backup of some data.

[0] - https://docs.celeryq.dev/en/stable/userguide/periodic-tasks....

Re: Fly.io: The reclaimer of Heroku's magic

#55

Post by mrkurt »

brundolf wrote: post #47
mrkurt wrote: post #42

Earlier quoted context omitted.

This is a problem. And a bit of an own goal on our part. I hate services that don't put a price on things like bandwidth (because there's always a price!). So we priced bandwidth and made it transparent. You can put an app on Fly.io and server petabytes of data every month, if you want. We'll never complain that you're serving the wrong content type. But the reality is – having an unlimited bandwidth promise is perfe…

I think it's also fine to just say "that's not our primary target market". Just thought it was worth pointing out as a (perhaps small?) segment of Heroku's market, if we're comparing apples to apples

Oh but you are! And it won't even cost you anything. I'd bet money your blog fits in our free tier, we just don't (a) tell you that and (b) solve the "what happens if there's a bandwidth burst" problem.

Re: Fly.io: The reclaimer of Heroku's magic

#56

Post by sanjayio »

mrkurt wrote: post #36
normie3000 wrote: post #6

How mature is fly.io?

We are DigitalOcean circa 2015 mature. Good enough for some very large customers, good enough for many developers, not some place I'd run pacemaker infrastructure.

Where would you feel comfortable running pacemaker infra? Half-joking here.

Re: Fly.io: The reclaimer of Heroku's magic

#57

Post by nickjj »

tomjakubowski wrote: post #43
anon3949494 wrote: post #37

After all the chatter this week, I've come to the conclusion that Heroku froze at the perfect time for my 4 person company. All of these so called "features" are exactly what we don't want or need. 1. Multi-region deployment only work if your database is globally distributed too. However, making your database globally distributed creates a set of new problems, most of which take time away from your core business. 2.…

> Multi-region deployment only work if your database is globally distributed too. However, making your database globally distributed creates a set of new problems, most of which take time away from your core business. Guess what? fly.io offers a turnkey distributed/replicated Postgres for just this reason. You use an HTTP header to route writes to the region hosting your primary. https://fly.io/docs/getting-started/m…

> Guess what? fly.io offers a turnkey distributed/replicated Postgres for just this reason. You use an HTTP header to route writes to the region hosting your primary.

Doesn't this take away a lot of the benefits of global distribution?

For example if you pay Fly hundreds of dollars a month to distribute your small app in a few datacenters around the globe but your primary DB is in California then everyone from the EU is going to have about 150-200ms round trip latency every time you write to your DB because you can't get around the limitations of the speed of light.

Now we're back to non-distributed latency times every time you want to write to the DB which is quite often in a lot of types of apps. If you want to cache mostly static read-only pages at the CDN level you can do this with a number of services.

Fly has about 20 datacenters, hosting a small'ish web app that's distributed across them will be over $200 / month without counting extra storage or bandwidth just for the web app portion. Their pg pricing isn't clear but a fairly small cluster is $33.40 / month for 2GB of memory and 40GB of storage. Based on their pricing page it sounds like that's the cost for 1 datacenter, so if you wanted read-replicas in a bunch of other places it adds up. Before you know it you might be at $500 / month to host something that will have similar latency on DB writes as a $20 / month DigitalOcean server that you self manage, Fly also charges you $2 / month per Let's Encrypt wildcard cert where as that's free from Let's Encrypt directly.

Re: Fly.io: The reclaimer of Heroku's magic

#58

Post by brundolf »

mrkurt wrote: post #55
brundolf wrote: post #47

Earlier quoted context omitted.

I think it's also fine to just say "that's not our primary target market". Just thought it was worth pointing out as a (perhaps small?) segment of Heroku's market, if we're comparing apples to apples

Oh but you are! And it won't even cost you anything. I'd bet money your blog fits in our free tier, we just don't (a) tell you that and (b) solve the "what happens if there's a bandwidth burst" problem.

Yeah, I also supposed that it would probably mostly fit in the free tier, which is great. But I'd lose a small amount of sleep over the possibility of getting a huge bandwidth burst (DDOS or otherwise) that goes straight to my bank account

A feature that could help would be giving people the option to set a cost limit, where if their site surpasses that limit in a given month you just pull it offline instead of charging more money. That's what I'd want for my blog site, and I've heard others request such a feature from other cloud providers

Re: Fly.io: The reclaimer of Heroku's magic

#60

Post by matthewcford »

mavbo wrote: post #20
2c2c2c wrote: post #12

There's a lot of chat about fly.io on HN. possibly just because the founders and friends are posters here. Is there any in depth comparison between them and render.com ?

Not in-depth, but two things that have stood out to me in assessing Render vs Fly are Render's lack of Multi-region apps and release phase scripts for running migrations. Easy multi-region apps seem to be a main selling point of Fly. However, both of the features I mentioned are on Render's roadmap (Multi-region apps has been on their roadmap since 2019, so maybe not a priority?)

these were the reasons we chose fly in the end; very happy with it
Post reply on HN