Alas, I feel like the word "Ordinary" is doing a lot of heavy lifting in this title!<p>The upshot is, so long as your postgres + rails app isn't doing some kind of DB write with every request, and doesn't do much - or ideally anything - with Redis, and you want 200ms time-to-first-byte globally (or at least, in multiple locations across the world) then you can easily get better performance with Fly.io than most other solutions.<p>It's a really clever solution, and one day I'd love to work on a project that fulfils all of those constraints. Haven't found one yet though.
I think the thing is, for most people they won't need to do the global distribution that Fly.io is pioneering, what they want is a better cheaper Heroku. Fly.io is already exactly that too.<p>For the 1% of people who do need that global distribution, what Fly.io have built is incredible.<p>I currently host on Heroku and plan to switch to Fly.io once they have an equivalent to Heroku Postgres's WAL point in time restore.
We're building PolyScale.ai[1] that solves the global latency challenges for apps using caching. Clearly that is a different proposition/architecture to database read-replicas, but if the use case is a fit, it's a powerful solution to a hard problem. PolyScale plugs into your existing database and maintains your transactionality and consistency (we automatically invalidate globally). DML queries pass through to the origin db and reads (SELECT’s, SHOW’s) get cached locally at the edge.<p>We move the database data and query compute closer to the end user for consistent 1ms query execution times at scale. It intelligently manages the cache for every individual SQL query so no configuration is needed, unless of course you want to set manual TTL’s.<p>1. <a href="https://www.polyscale.ai/" rel="nofollow">https://www.polyscale.ai/</a>
I appreciate that they have made globally deploying a rails app, Postgresdb, cdn, network routing fast and easy. There is always lot of finicky configuration issues and it takes a lot of time to get this all set up right. Like lots of IaaS, they are making something hard easier. They are not, though, removing the need to build your app to this paradigm. The conventions and restrictions you need to follow to realize the benefits remain and are similar to what you’d have to do yourself. So they’ve cleaned up lots of application and deployment gunk, but the app engineering work remains. This is progress. Very nice.
Maybe I missed this in the link but I didn't see how one of the common problems in a distributed application is addressed:<p>* A POST request is redirected to the primary data source, the resource is created and the id is returned<p>* A GET request is immediately issued for that id but the resource that has not been replicated to the regional data source<p>* :boom:
Fly is compelling enough to use without all the global deployment options they offer[1] but it's assuring to know if you ever do need to deploy globally, they can support that better than most.<p>[1] - <a href="https://github.com/superfly/fly-ruby" rel="nofollow">https://github.com/superfly/fly-ruby</a>
I deployed a little side-project (<a href="https://thecitymapquiz.com" rel="nofollow">https://thecitymapquiz.com</a>) to fly.io yesterday. The deployment went really smooth, but friends testing it out complained their connection (websockets in Phoenix LiveView) dropped. It might be because its running on the cheapest VMs, I don't know yet.
That said, it was really satisfying seeing the application running in Seattle, Hong Kong, and Amsterdam within minutes after launch.
If this global replicated architecture is now a nice, polished, improving hosting product - how come so many well-funded global brands don't appear to benefit from an architecture like it?<p>Like Airbnb taking many seconds to load many parts of their app from the UK, or business apps like Xero which respond tens of times slower than a local app from 30 years ago.<p>Surely these are the sorts of companies which should be on top of global hosting, now that a hosting firm can box and sell it?
I wonder what the costs are to run something like this for a real world app. Fly.io charge outbound bandwidth fees. You've got instance / volume costs for all the regions for the DB and app servers. IP addresses are charged.<p>Can someone try it for a medium sized app and send through their monthly bill, that'd be great thanks :).
I'm really interested in fly.io after their Postgres post the other day, but I've not seen anywhere what their recommended solution is for ActiveStorage – is it still writing to S3 (or equivalent), or would it be somehow using their volumes? Are there any published examples (blog posts etc)?
Amazing what started with Heroku* has turned into.<p>*Started for me at least. Heroku was how I got started as a Rails developer, and it made it so easy to get a deployment available to interact with from anywhere.
Can anyone speak to using a rails app to reach global users using fastly's surrogate tags or cloudflare's cache tags (Enterprise only)?<p>After reading the OP, the tradeoffs seems more complex than a single origin in us-east and having CDNs cache HTML pages.<p>The most appealing advantage I see with running rails at all these regions is you can authenticate users really quickly and redirect them to a html page in a CDN.
I'm struggling to deploy a basic docker application, that works fine on my machine, it handles https traffic by its self, so the Fly.io docs say to exclude services.ports in fly.toml and TCP will be passed-on as-is, but unfortunately it seems to still be messing with my TCP traffic, maybe because it's on a non-standard port
I deployed my company website / blog with fly.io
It's a simple phoenix app w/o a DB, and it was trivially easy to set up. After having used K8S for Rails and Phoenix hosting before, their product is definitely something to keep in mind.