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

121–130 of 320 posts

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

#121

Post by mrkurt »

anon3949494 wrote: post #86
mrkurt wrote: post #70

Earlier quoted context omitted.

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.

Database read request are not the same as readonly HTTP requests. I am much happier having all requests hit my app process than I am trying to do the CDN dance.

Right now your choices are: run a database in on region and:

1. Use the weird HTTP header based cache API with a boring CDN

2. Write a second, JS based app with Workers or Deno Deploy that can do more sophisticated data caching

3. Just put your database close to users. You can use us for this, or you can use something like Cloud Flare Workers and their databases.

My hot take is: if something like Fly.io had existed in 1998, most developers wouldn't bother with a CDN.

Weirdly, most Heroku developers already don't bother with a CDN. It's an extra layer that's not always worth it.

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

#122

Post by joseph »

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?

I'd like to do any one-off job, not only scheduled ones; retrieving data and transforming or storing it, scraping a web page, running a database migration. My biggest annoyance with Fly is the assumption that everything is a long running application.

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

#123

Post by the_duke »

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'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.hetzner.com/robot/general/traffic/

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

#124

Post by nickjj »

nicoburns wrote: post #107
nickjj wrote: post #89

Earlier quoted context omitted.

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

For low-latency workers like that it might make sense to just run them on the same instance as the web servers.

Does Fly let you run multiple commands in separate Docker images? That's usually the pattern on how to run a web app + worker with Docker, as opposed to creating an init system in Docker and running (2) processes in 1 container (this goes against best practices). The Fly docs only mention the approach of using an init system inside of your image and also tries to talk you into running a separate VM[0] to keep your web app + worker isolated.

In either case I think the price still doubles because both your web app and worker need memory for a bunch of common set ups like Rails + Sidekiq, Flask / Django + Celery, etc..

[0]: https://fly.io/docs/app-guides/multiple-processes/

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

#125

Post by tptacek »

nickjj wrote: post #124
nicoburns wrote: post #107

Earlier quoted context omitted.

For low-latency workers like that it might make sense to just run them on the same instance as the web servers.

Does Fly let you run multiple commands in separate Docker images? That's usually the pattern on how to run a web app + worker with Docker, as opposed to creating an init system in Docker and running (2) processes in 1 container (this goes against best practices). The Fly docs only mention the approach of using an init system inside of your image and also tries to talk you into running a separate VM[0] to keep your we…

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.

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

#126

Post by vlunkr »

Trasmatta wrote: post #114
jpgvm wrote: post #100

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. For larger teams having a well defined API that delineates applications from infrastructure that doesn't require extreme specialist knowledge (it still requires some specialist knowledge but vastly less than direct manipulation of resources via something…

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

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

#127

Post by heartbreak »

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…

Last week I couldn't get Fly.io to spin up a simple Postgres database for my app. I've now been on Render for a week with multiple production apps, and so far it has been working fine.

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

#128

Post by teaearlgraycold »

iammiles wrote: post #120
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 strongly agree with your last paragraph. I used Heroku for my wedding website and I would 100% use it again on a project site. In about 15 minutes I was able to take my site from localhost to a custom domain with SSL with just a little more than a git push. I can't think of many solutions that are simpler than that.

Vercel and Github pages would be better IMO if it's a static site.

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

#129

Post by mulmboy »

tshaddox wrote: post #44
bri3d wrote: post #39

Earlier quoted context omitted.

The main reason is to use a chat solution is as a unified ledger / single pane of glass. Silly as it is, there isn't really a better solution out there for "integrate all of my third-party deploy, CI, build, etc. status updates in real time, in one place." Sure, someone can click into GitHub, but if you use another service to deploy into, does GitHub pipe the status of that service into your dashboard? How about erro…

Perhaps for looking back to see the history of things, a unified ledger is convenient. But as a notifications/alerts solution it’s terrible because it essentially guarantees that the signal to noise ratio will be incredibly low.

This just depends on how disciplined you are. We use a system where backend errors are logged to slack, and then we treat addressing the source of the errors as an immediate priority. Keeping the SNR high is a priority. Plus generally being very selective about what goes into the channel.

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

#130

Post by otterley »

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.

The same is true of ECS, but with a much simpler API, much tighter integration with load balancers, a no-charge control plane, and not having to upgrade every cluster every 3-6 months.
Post reply on HN