[bradgessler]

Fly is great.

They’ve got Chris McCord there, who has already improved their Elixir deployment story. I tweeted a few weeks ago about improving the default Rails deployment experience to not require DB provisioning and configuration of env vars like SECRET_BASE_KEY and they said it would likely ship within the next 3 months.

My hot take is they’re setting themselves up to ride the server-side rendered HTML renaissance we are experiencing with LiveView and Hotwire. It will become much more important to deploy applications geographically closer to customers to lower latency, which Fly makes sane for the rest of us.

[atonse]

We're betting the same, and Fly.io doesn't know it yet, but part of our solution will eventually be made possible (much easier) thanks to their architecture. :)

But we aren't yet ready for that piece.

[cultofmetatron]

oh shiet. that explains so much when it comes to their elixir support.

Fly.io was still very beta when My startup was launching. if we were creating out deployment now, fly.io would be top of my list.

[keewee7]

What are the physical security implications of using Fly.io and other edge computing services?

Is some shady ISP colocation as safe as highly secured AWS and Azure data centers?

[kasey_junk]

Fly isn’t really edge in the sense that they are colocating with lots of ISPs like Netflix might for video at the edge.

Fly is edge in the sense they have hosts in N regions and manage the anycast for you so traffic seamlessly routes to those regions. They don’t publish which data centers they operate in only the regions (https://fly.io/docs/reference/regions/) but most of those regions line up with equinix data centers which are all physically secured professional facilities.

It’s a great question though and one they should have a document about.

[tptacek]

We should do better documenting security across the board, but I keep getting drawn into i.e. months-long DNS optimization problems. This'll get done this year, though.

[gingerlime]

What kind of Rails apps run without a DB? or how can you scale your app with a DB across 10+ regions?

Would love to understand better how to deploy Rails with fly and still benefit from multi-region/failover/scaling

p.s. horrible nitpick, but I think it’s SECRET_KEY_BASE :)

[mrkurt]

Read heavy Rails apps work great multi region: https://fly.io/blog/run-ordinary-rails-apps-globally/

We have a Gem to make it almost transparent: https://github.com/superfly/fly-ruby

[gingerlime]

It's an interesting idea to assume GETs will do no writes, as opposed to POST/PUT/DELETE and route them via middleware, but as an app developer, you need to be very mindful of any updates I suppose... replication delay can also create some weird scenarios I imagine...

[mrkurt]

That's all solved. We catch readonly errors from Postgres and issue the replay. Preemptively sending a POST to the primary region is an optimization, it works fine without doing that!

Replication lag is handled too in the Ruby library we pin requests to the for a few seconds. In our Elixir library, we actually monitor the read replica directly and reroute writes until it's caught up.

[gingerlime]

I understand roughly what the gem does, but you still need to be aware of it with your app. For example, if every request updates some activity stat, or the last page the user was on (which happens with some apps), you instantly lose pretty much all the benefits, right?

What about redis / sidekiq btw? :)

[mrkurt]

Ah I see what you're saying! You're basically describing our experience trying to run Discourse. Weirdly, naive, less complicated Rails apps work better multi-region on Fly than mature grownup Rails apps.

We use sidekiq + Fly in a single region with the primary database, and then write to the Redis from other regions asynchronously. It's a good time in Ruby world, I think Ruby 3 will simplify a lot of the weird background work people do.

Ruby 3 will definitely help us solve the problem of gets that do writes for stats or history, since those things can be done async. You can do a little of it now just by spawning a thread and writing the the writable Postgres in the background.

[mrkurt]

shhh!