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

81–90 of 320 posts

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

#81

Post by ignoramous »

nehalem wrote: post #19

Being a small-scale Heroku user, I have a hard time deciding whether to stay with Heroku or move to render.com or fly.io. Before the latest incident, Heroku seemed to be frozen but stable. Now… I don't know. Are they even trying to bring back Github Connect? Fly.io seems cutting-edge but I feel I would not profit from their multi-region, close to the user infrastructure. So what are their tradeoffs? Render.com appear…

Fly.io isn't as much cutting-edge as it is a rethink on what devex on Cloud should look like. It is a fantastic offering that despite its shortcomings is really a delight to use. I use it for toy projects (mostly stateless, or state stored elsewhere but not on Fly.io), but there are plenty who run pretty serious workloads. Give it a spin! You'd be surprised how butter-smooth all that cutting-edge is.

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

#82

Post by ushakov »

datalopers wrote: post #62
ushakov wrote: post #34

i'm running https://wikinewsfeed.org on fly.io very satisfied so far and would definitely deploy there next time! the killer feature i like the most is automatic prometheus metrics collection one thing i don't really like about fly.io is the fact that they charge money for free Let's Encrypt SSL certs

They aren’t charging for the certificate so much as they’re charging for TLS termination, infrastructure, DNS, caching, handling invalidations, etc. It’s also 10 free then $0.10/mo per certificate thereafter (or $2/mo for wildcard). They also donate 50% of their TLS fees to Let’s Encrypt. So, yes, some users will have have to pay for certificates, but it seems extremely reasonable to me.

well, maybe

but, my expectation as a PaaS customer in 2022 is that you shouldn't need to pay for a SSL cert

the expectation is because nobody else charges for them anymore, not even their competitors

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

#83

Post by brundolf »

mrkurt wrote: post #76
EnKopVand wrote: post #69

Earlier quoted context omitted.

I don’t want an unlimited bandwidth promise, I want a cap that I know can never be exceeded. I mean, I use Azure professionally and one of the key reasons I don’t use it to host my own stuff is exactly because it could potentially become very expensive. I’d rather have my own stuff shut down until I decide what I want to do with it. Things like alerts are fine, professionally, but not for things like running a small…

We actually launched with that feature: https://news.ycombinator.com/item?id=22616857 No one took us up on it. What we found is that the majority of people want their stuff to stay up, and the right UX for "shut it down so you don't get billed" is not obvious. We ended up implementing prepayment instead. If you sign up and buy $25 in credit, we'll just suspend your apps when the credit runs out. Bandwidth is weird be…

I can't speak for your whole market, but I know for me the pre-loading flow sounds really clunky because I'd have to go and manually add funds each month (right?)

It's understandable if your usage data showed the fee-capping feature just wasn't popular enough to be worth maintaining, though that would surprise me based on this thread (but possibly HN just isn't representative of the whole market)

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

#85

Post by krn »

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?

> What would the ideal version of this feature look like for you?

I think that Render solved "Cron as a Service" beautifully:

https://render.com/docs/cronjobs

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

#86

Post by anon3949494 »

mrkurt wrote: post #70
anon3949494 wrote: post #61

Earlier quoted context omitted.

Yep, for anyone confused on how this works: You'd still be sending writes to a single region (leader). If the leader is located across the world from the request's origin, there will be a significant latency. Not to mention you need to wait for that write to replicate across the world before it becomes generally available.

This is the distribute-your-Rails-app-without-making-any-code-changes version of that story. It works great for apps that are 51% or more read heavy. You drop our library in, add a region, and off you go. The library takes care of eventual consistency issues. HTTP requests that write to the DB are basically the same speed as "Heroku, but in one place". If you're building infrastructure for all the full stack devs you…

It's also trivial to serve read requests from a caching layer or via a CDN. At any sufficient scale, you're probably going to need a CDN anyway, whether your database is replicated or not. You don't want every read to hit your database.

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

#88

Post by tomnipotent »

twblalock wrote: post #78
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.…

Even small companies should be multi-region, if they care about uptime.

No, they shouldn't. In many instances it's cheaper to tolerate downtime than to pay to avoid it, especially when there's no SLA involved.

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

#89

Post by nickjj »

manmal wrote: post #79
nickjj wrote: post #57

Earlier quoted context omitted.

> 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…

You don’t need to route every write to primary though, but only those writes that have dependencies on other writes. Things like telemetry can be written in edge instances. Depends on your application of course, but in many cases that should be only a tiny fraction of all requests needing redirects to primary. And why would you get 20 instances, all around the world right out of the gate? 6-7 probably do the job quit…

> You don’t need to route every write to primary though, but only those writes that have dependencies on other writes.

Thanks, can you give an example of how that works? Did you write your own fork of Postgres or are you using a third party solution like BDR?

Also do you have a few use cases where you'd want writes being dependent on another write?

> 6-7 probably do the job quite well

You could, let's call it 5.

For a 2gb set up would that be about $50 for the web app, $50 for the background workers, $160ish for postgres and then $50 for Redis? We're still at $300+?

I was thinking maybe 5 background workers wasn't necessary but frameworks like Rails will put a bunch of things through a background worker where you would want low latency even if they're happening in the background because it's not only things like sending an email where it doesn't matter if it's delayed for 2 seconds behind the scenes. It's performing various Hotwire Turbo actions which render templates and modify records where you'd want to see those things reflected in the web UI as soon as possible.

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

#90

Post by Shadonototra »

Fly.io is backed by YCombinator

In order to increase transparency on Hacker News, it would be nice it the title was changed to include the fact that's it's backed by YCombinator

https://www.ycombinator.com/companies/fly-io

--

I personally don't think it's better than Heroku, you have much less features, Heroku is much cheaper + they have an unbeatable free tier

Post reply on HN