How does Fly.io work? Isn't the database the performance botleneck?

Questions / Help
, ,
1

The consensus in the elixir community seems to be that Fly.io is the way to deploy Phoenix apps, and I have successfully done this myself, but I don’t understand how it works.

The docs state:

We want you to run your full stack close to users, whether it’s a simple web service or your database-backed opus with multiple supporting services.

But what if I have users all over the world? Does Fly.io constantly move my app around to be close to different users? What about the database – certainly it should be the single source of truth, so I don’t see how it can be moved easily.

What does Fly.io offer that is different from just picking a datacenter in some location that you think will be close to the majority of your users and just deploying your app there?

1 Like
2

I think Fly is doing great stuff, and I think they’re a great default for deployment. That said, I think there’s still a LOT of us deploying Phoenix in more traditional cloud environments, or in even more traditional servers. Fly is definitely not the majority of deployments, and I would be surprised if they were a plurality.

I am not a Fly expert, but my sense is that they help in two ways:

  1. LiveView in particular adds client → server round trips for rendering that often do not hit the database. These are helped by having the app closer to the client.
  2. Fly has global replicas for postgres, which basically let you have read replicas colocated near your apps near your users at the edge. This doesn’t help writes, but it definitely cuts down on latencies for reads.
5 Likes
3

Do add to that: Fly enables you to be closer to your users, but it doesn’t come for free, but as options you need to use.

  1. The first option is scaling your app server across multiple regions. That can be done on other hosts as well and while it is simple on fly I wouldn’t call that something you won’t or can’t see elsewhere.
  2. The second option is scaling your db across regions as read replicas, where you’d still stick to a single writeable instance. Fly uses the first point as the underlying infrastructure for their managed databases. On top there are a few well thought out conventions to let their hosted db setup be rather hands off for the db scaling side and also provide some comparatively simple means of making your app ready for such a setup as well. This again can probably be done elsewhere as well, though I haven’t seen all of those points be combined that well.
1 Like
4

Fly is definitely not the majority of deployments, and I would be surprised if they were a plurality.

What deployment solution would you guess accounts for the plurality of deployments?

1 Like
5

Look up Mark Ericksen’s talk at last year’s ElixirConf for more details. It’s some clever stuff.

3 Likes
6

From polls, conversations, and a lot of support I can confidently say elixir apps are deployed all over the place: GCP, AWS, Heroku, Render, Gigalixir, Hetzner, and Fly come up regularly (though Gifalixir and Heroku are declining).

2 Likes