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

61–70 of 320 posts

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

#61

Post by anon3949494 »

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.

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.

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

#62

Post by datalopers »

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.

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

#63

Post by chasd00 »

if you're counting pennies just use dokku on a vps, there was even an article here on HN recently. By the time you outgrow it you'll have outgrown the vast majority of the new paas sites that are springing up trying to be the next Heroku and your choice of where to go next will be easier. In the meantime, you'll have saved all that effort on just picking where your app is hosted and, instead, spend it on actually delivering your app. crazy thought, i know.

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

#64

Post by detaro »

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.

That's also something that has kept me with VPS hosts over cloudy things for hobby stuff: a) included traffic amount is vastly higher there, leading to way lower cost per GB if you need it and b) they usually do just cap you if you exceed traffic and don't opt-in to pay more.

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

#65

Post by anamexis »

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…

Yes, there are hundreds of different ways you could accomplish this. Fly.io is a convenient and easy to use one.

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

#66

Post by taylorlapeyre »

anurag wrote: post #24
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.

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?

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

#67

Post by [deleted] »

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…

[deleted]

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

#68

Post by ignoramous »

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…

> We'll never complain that you're serving the wrong content type.

Cloudflare shouldn't restrict media (video, images, and audio) from its unlimited bandwidth promise for Workers and R2 (though, ToS doesn't yet reflect that).

https://news.ycombinator.com/item?id=28682885

> But the reality is – having an unlimited bandwidth promise is perfect for for a fire and forget blog site

I think, an auto flyctl pause -a when myapp exceeds $x in charges (with an auto-resume when the billing rolls over) may serve as a viable interim solution. May be this is already possible with fly.io's graphql api?

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

#69

Post by EnKopVand »

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…

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 app, blog or whatever, that you’re not sure where is heading.

I don’t think anything I’ve build on my own time has ever ended up breaking my bank, but signing up my credit card is a risk I’m never going to take, and I’m fairly certain I’m not alone in that. Of course I have no idea if there are enough of us to make small scale fixed prices products profitable at scale.

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

#70

Post by mrkurt »

anon3949494 wrote: post #61
sanjayio wrote: post #45

Earlier quoted context omitted.

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.

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 can target, this is a good way to do it.

Distributing write heavy work loads is an application architecture problem. You can do it with something like CockroachDB, but you have to model your data specifically to solve that problem. We have maybe 5 customers who've made that leap.

In our experience, people get a huge boost from read replicas without needing to change their app (or learn to model data for geo-distribution).

Post reply on HN