Hacker News Reader

Comment by nicoburns | Hacker News Reader

Are the things you feel are missing from fly/render, or is it just a case of it not being worth switching an already set up project?

View on HN

Fly.io doesn't track Heroku buildpacks nor does it recommend buildpacks as a first class workflow. Buildpacks are very underdocumented. The official tutorial and guides pushes Docker as the "preferred" workflow. Docker is nice for environments like Rust/Go/when you have additional dependencies. For Ruby/Python/Node buildpacks are a lot easier. Your typical Heroku tutorial says "use cedar-XYZ pack for Python Z and everything will just work". The version of Heroku buildpacks tracked by fly is many years out of date (Heroku 18, https://fly.io/docs/reference/builders/). People use Heroku because they don't want to deal with DevOps or the differences between Ubuntu vs Debian vs Fedora for server side deployments. Docker is great for complex use cases but 80% of the time you just need to install dependencies and expose a port. Fly.io claims to have automated detection of environments but this isn't well documented at all. The docs doesn't explain when to use the automated detection and when it will fail.

In the entire fly.io documentation, there are only two mentions of buildpacks: https://fly.io/docs/reference/builders/ https://fly.io/blog/topic/buildpacks/

Fly.io hides behind clever engineering blog posts while pushing tremendous complexity on to the developer. While I appreciate the transparency and clever engineering hacks used in building Fly, the lack of a true managed database with a proper GUI and point in time backup and recovery makes it hard to consider Fly as a true Heroku alternative (the official Fly.io recommendation is to go to Crunchy Data for managed databases).

I mean, you're mostly right. Not about the "hiding behind blog posts" thing (we just like to write). But the rest of it, sure? We're not telling you to stop using Heroku. We love Heroku. Heroku is a big part of why we got into this.

Our primary benefit over Heroku isn't "the simplest possible DX". Heroku has that nailed! It's running apps close to users, easily scaling them up and out over the globe. I like us a lot (but then I would) for simple apps that will never need global scaling, but nobody at Fly.io is telling you that we've somehow obsoleted Heroku!

I'm confident that we'll get to parity with Heroku on DX; it's a thing we're serious about. But Heroku has had a long, long time to get these details right, and we're working on other things too. Give us a bit. :P

I want to use Fly, not Heroku. But Fly just doesn't seem to live up to my expectations right now :(

I understand that you believe your competitive advantages stem from the edge server deployments. Sure that may be true for certain serverless and HTML-over-the-wire workloads like Phoenix, but if you actually talk to your customers, a significant number of us want a Heroku replacement, not just fancy docker-at-edge.

It seems reasonable that we wouldn't be living up to your expectations; there's no single best place to host things, and Heroku is a great platform. We're Fly.io, not Fleroku.

I like this reply. Not a user of either system currently, but have done projects on both. The use-case for fly.io is strong, but everyone needs to focus on where they want to spend their time vs pay off.

I wish I could give you a concrete answer but it's been about 7 or 8 months since I last looked at alternatives. IIRC, it was something to do with Postgres restore support not being as good.

Reply on news.ycombinator.com