Hacker News Reader

Comment by peteforde | Hacker News Reader

fly.io is a big deal.

It's not as easy as Heroku as there's no managed Postgres, but it's well-documented with a few paths.

However, the main reason Fly stands out is their focus on multi-region deployments. Ever wondered why facebook.com is fast no matter where you are? Fly provides app-level tooling to make this superpower available to everyone.

It's especially important if you're making heavy use of Web Sockets.

Everyone wants to be the new Heroku, but that should be table stakes. Fly is innovative in the same way Heroku was when it launched.

View on HN

> Ever wondered why facebook.com is fast no matter where you are? They provide app-level tooling to make this superpower available to everyone.

They're doing that in the app? GeoDNS has been around for quite some time: https://en.wikipedia.org/wiki/GeoDNS or more thoroughly explained: https://jameshfisher.com/2017/02/08/how-does-geodns-work/

Fly's multi-region capability is BGP Anycast-based, which is vastly superior (and much more complex to deploy, outside of Fly) to DNS-based solutions like GeoDNS.

One example of app-level tooling is the fly-replay header, which permits your app to automatically replay requests in different regions. This works really well alongside the FLY-REGION environment variable that is available to each node. https://fly.io/docs/reference/fly-replay/

Another example of app-level tooling is the availability of NATS Jetstream, a key/value store that is less feature-rich than Redis, but supports multi-region active/active replication. This is a big deal, as Redis doesn't offer it at the free tier, and many others (KeyDB) who advertise it seem to have trouble delivering it when there's more than two regions in play.

Would have been a good comment if you dropped the first line.

So you disagree that it's superior? Please explain why.

The comment has been deleted to remove the unnecessary comment: you're seeing the improved version.

GeoDNS is a technology that allows you to point web users to a nearby server. That's great, but you still need to coordinate each server. For instance, if you have distributed app servers and a single database server, you still have long distance communication/slowness whenever you need to run database queries.

One solution to this problem that Fly provides app-level support for is to allow you to have a fast local read-only copy of your database on/near each server, so that only inserts/updates need to run remotely. Your regional copies basically fail whenever there's an update, and Fly's platform re-runs the request on the leading webserver (which replicates the update to the regional database servers).

How well does it work? Never used it. But it would save you the trouble of having to notice the problem, come up with a solution and then implement it.

Reply on news.ycombinator.com