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

151–160 of 320 posts

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

#151

Post by mrkurt »

daxfohl wrote: post #101

Heroku was magic for hosting college projects of 2010's complexity. The failure wasn't in the prohibitive cost at scale (though that factor didn't help); it was that for most real-world stuff we need IaaS, not PaaS. That has become more and more evident over the last ten years. I think if fly succeeds, they need to figure out edge IaaS, and not put all their eggs into edge PaaS. And I hope they do! I'm curious what a…

This is pretty much what I believe. This isn't HN frontpage worthy, but one of the things I'm most excited about is people running production CockroachDB clusters on Fly.io. It is still a little more difficult to use the underlying infrastructure than it should be, but we're getting close.

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

#152

Post by chillfox »

the_duke wrote: post #123
mrkurt wrote: post #76

Earlier quoted context omitted.

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'm actually very curious: why is bandwidth so much cheaper on more traditional VPS or dedicated server hosts like Hetzner ? This extends to their somewhat new-ish cloud product, where you get 20TB traffic included - even on a tiny instance. And it's 1 Euro per TB after that. [1] Do they just decide to not profit from bandwidth or are they doing something special that allows them to be so cheap? [1] https://docs.hetz…

I would love to hear the answer to this as well.

My guess is that they either don't profit from bandwidth or they have peering agreements from back when the internet was young.

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

#153

Post by mrkurt »

nickjj wrote: post #137
tptacek wrote: post #125

Earlier quoted context omitted.

It sounds like you're asking if we offer some alternative between running multiple processes in a VM, and running multiple VMs for multiple processes. What's the third option you're looking for? Are you asking if you can run Docker inside a VM, and parcel that single VM out that way? You've got root in a full-fledged Linux VM, so you can do that.

> Are you asking if you can run Docker inside a VM, and parcel that single VM out that way? You've got root in a full-fledged Linux VM, so you can do that. On a single server VPS I'd use Docker Compose and up the project to run multiple containers. On a multi-server set up I'd use Kubernetes and set up a deployment for each long running container. On Heroku I'd use a Procfile to spin up web / workers as needed. The F…

This is embarrassingly non obvious in the docs, but you can run workers/web just like you would on Heroku: https://community.fly.io/t/preview-multi-process-apps-get-yo...

Most people run workers in their primary region with the writable DB, then distribute their web/DB read replicas.

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

#154

Post by augstein »

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.

Does that mean if my webapps get DOSed or something like that, and I can‘t react very quickly, I could face a bill potentially in the thousands of dollars?

Currently considering switching from Heroku, but fixed pricing is a must. I‘d rather they shut down my apps temporality in case something is out of control, then get broke ;-)

Any other recommendations besides fly.io?

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

#155

Post by daxfohl »

mrkurt wrote: post #151
daxfohl wrote: post #101

Heroku was magic for hosting college projects of 2010's complexity. The failure wasn't in the prohibitive cost at scale (though that factor didn't help); it was that for most real-world stuff we need IaaS, not PaaS. That has become more and more evident over the last ten years. I think if fly succeeds, they need to figure out edge IaaS, and not put all their eggs into edge PaaS. And I hope they do! I'm curious what a…

This is pretty much what I believe. This isn't HN frontpage worthy, but one of the things I'm most excited about is people running production CockroachDB clusters on Fly.io. It is still a little more difficult to use the underlying infrastructure than it should be, but we're getting close.

Neat, I'd say that is absolutely HN frontpage worthy!

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

#156

Post by franciscop »

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 the reason I use Heroku and would never on a personal level use some of the bigger solutions, or apparently Fly.io. As an individual and despite being generally careful, I just cannot have a tiny risk of having a $100k+ accidental bill. I'd rather my project goes down if there's a DDOS attack, or if I made a typo and created an infinite loop. If I take some of my hobby projects to the "next level", it'd be def behind a LTD company.

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

#157

Post by mrkurt »

augstein wrote: post #154
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.

Does that mean if my webapps get DOSed or something like that, and I can‘t react very quickly, I could face a bill potentially in the thousands of dollars? Currently considering switching from Heroku, but fixed pricing is a must. I‘d rather they shut down my apps temporality in case something is out of control, then get broke ;-) Any other recommendations besides fly.io?

No, we don't bill people for traffic from attacks. We also waive fees from big, legitimate bursts. The intent of our bandwidth pricing is to allow high usage, sustained bandwidth workloads. It's not to sneak one over on you.

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

#158

Post by ramraj07 »

Trasmatta wrote: post #142
vlunkr wrote: post #126

Earlier quoted context omitted.

Really? I think it's a pretty obvious benefit. If you bundle something into a container, you can probably run it in kubernetes. This uniformity makes it incredibly easy to deploy and scale new applications.

I think what I've heard is the kubernetes end result is very often a massively overcomplicated infrastructure that nobody understands, that's a constant source of headaches and lost time due to leaky abstractions. Disclaimer: I've never actually used it myself. That's mostly just what I've read and heard from people who use kubernetes.

Basically depends on expertise. The parent commenter probably comes from a team of good well paid ops engineers who understand and set up k8s well. In any other org it’s the show you describe.

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

#159

Post by [deleted] »

vlunkr wrote: post #126
Trasmatta wrote: post #114

Earlier quoted context omitted.

> I think people misconstrue the benefits of k8s to be related to reliability or similar. Ultimately it's about the API and the consistency and productivity it offers I think this is the first time I've heard somebody say one of the benefits of kubernetes was productivity.

Really? I think it's a pretty obvious benefit. If you bundle something into a container, you can probably run it in kubernetes. This uniformity makes it incredibly easy to deploy and scale new applications.

[deleted]

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

#160

Post by quickthrower2 »

Fly.io is a reclaimer. Also see: Vercel, Digital Ocean, Dokku, Netlify, Firebase, Engine Yard, OpenShift, Appfleet, Github Pages, Render, AWS Amplify.

Heroku made it easier to deploy, but now it feels a tad bit bit more frictional than other services, including fly.io and these mentioned above. It is probably a bit outdated in that regard.

Post reply on HN