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

71–80 of 320 posts

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

#71

Post by taylorlapeyre »

mrkurt wrote: post #30
taylorlapeyre wrote: post #14

The main thing I want is pipelines - review apps, staging apps, and promotion to production, all integrated closely with GitHub, along with a slack integration that lets me do all of it in a public chatroom. Until another service has all of this, we’re sticking with Heroku.

First, Heroku's pipelines and GitHub integration are (or, I guess, were) excellent. We (Fly.io) intentionally didn't build a pipeline replacement. We exist for one reason: to run apps close to users. We're just now to the size where we can do that well. It'll be a while before we can get good at a second thing. Heroku shipped them something like 8 years after they launched. At the same time, GitHub actions and Buildk…

Yeah, totally get that.

> I think there's a chance that emulating Heroku that closely is a path to failure in the 2020s.

I'm not sure I agree, considering that a different platform emulating this exact setup with ~zero configuration is basically everything we want! GitHub actions is (I agree) really great and very versatile, but I'll take Heroku's UI over digging through actions plugin documentation for hours any day.

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

#72

Post by kasey_junk »

sanjayio wrote: post #45
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.…

I’m always confused why edge services are always selling points given point 1. The most basic of backend services won’t be able to completely utilize edge services.

It’s a tremendous latency speed up for read heavy apps that can tolerate eventually consistent read replicas. Any app using a popular sql rdbms likely falls into this category at scale. Any app using a redid cache likely falls into this category at scale.

Also any app that has global clients and terminates ssl likely benefits from edge compute.

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

#73

Post by anurag »

taylorlapeyre wrote: post #66
anurag wrote: post #24

Earlier quoted context omitted.

Render has review apps ( https://render.com/docs/preview-environments ). We're actively working on pipelines (early access ETA late summer).

Any plans for a chatops extension for Slack? The best think about Heroku is being able to say "/deploy [app]/[branch] to [environment]", and have it Just Work, all with inline threads that convey status updates about the deployment. Does Render plan to build something like that?

No immediate plans, but I'd love to see this on Render at some point, and not just for Slack.

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

#74

Post by bsder »

mrkurt wrote: post #42
brundolf wrote: post #31

The only thing I don't like is their usage-based pricing. On Heroku I could pay $7 a month and know I'd never be charged more than that. I'm sure when you're scaling a service it's fine - maybe even better - to do it on a sliding scale. But for a fire-and-forget blog site, I don't want to have to worry about stuff like that.

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…

> And a bit of an own goal on our part.

More than a bit.

Simply give people the option to put a charge limit and let the app be offline when that limit gets hit. Don't make it the default, but do allow people to do it.

This would resolve 99% of the fear people have. And most people wouldn't set the limit anyway. However, your knowledgable people might set it, and those are the ones you're most trying to attract.

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

#76

Post by mrkurt »

EnKopVand wrote: post #69
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 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 because we have to pay for it (as does every other provider). We aren't yet in a position where we can just make it free without limits. Maybe next year. :)

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

#78

Post by twblalock »

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.

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

#79

Post by manmal »

nickjj wrote: post #57
tomjakubowski wrote: post #43

Earlier quoted context omitted.

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

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 quite well, but maybe you don’t even need that many. Depending on where most of your customers are, you could get good results with 3-4 for most users.

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

#80

Post by mrkurt »

sergiotapia wrote: post #33

My experience with Fly.io has not been a good one. If I could sum it up, it would be that the dev ux needs a lot of work, and it seems like they are mostly focused on the fundamentals of the platform first. Following their guide you get postgres not spinning up and linking to your app correctly and you have to nuke your entire app. The billing UI is weird and feels cobbled together. I don't feel secure using Fly righ…

It's very generous of you to assume we're focusing on underlying platform. It's true! But it's a difficult thing to notice when our service gave you papercuts.

We've just now grown large enough to have people focus full time on the in browser UX. If you feel like fiddling around again in a few months, let me know and I can hook you up with some credits. :)

The billing UI is definitely cobbled together. This is because I built it over a weekend and it's marginally better than "no billing UI". I have learned that if I'm building features, they probably aren't gonna be very good.

Post reply on HN