[shroompasta]

I'm having trouble understanding the purpose of these edge services.

Granted, I've only handled small - medium sized infrastructures, and never really experienced the issues at scale, but if I were to get to that point, wouldn't it be easier to just hire a Infrastructure Engineer who could deal with the replication / sharding, not to mention having that engineer also deal with site reliability and dev ops?

If a user wants to hit my service, and then that service has to hit fly.io's postgres, isn't that an increase in latency? sure I could probably have it pretty darn close, but 20-100ms is still 20-100ms. I could manage my own (or hire someone), and have the db live in the same container (if i have a big enough box), or have it within the same data center.

And if it is the case that I do need to replicate across data centers, at that point, I should have the financial capabilities to hire an infra engineer.

Can anyone enlighten me why I would ever need this?

[anurag]

Hiring a (good) DevOps or infrastructure engineer is harder and more expensive than you might think.

That said, you can go very far with stateless apps at the edge with regional read replicas and a single write instance that's half way across the globe.

[mrkurt]

A user hitting your service would hopefully be hitting your service on Fly.io and that would be talking to a database on Fly.io. :)

You can replicate across datacenters on Fly.io for free. No infra engineer required. And very little code change required: https://fly.io/blog/run-ordinary-rails-apps-globally/