I'm still not entirely convinced that serving apps closer to users solves more problems than it creates, but I am always impressed by the fly.io blog posts. The writing style makes them a joy to read.
Most pieces of technology create as many problems as they're meant to solve. The cost-benefit is always around whether or not the solved problems are worth the cost of the new problems. If latency is such a problem that you'd want to deploy servers and caches as close as possible to a user, you'd probably gladly pay for the reduction of that latency at the cost of the new class(es) of problem.
It was an interesting decision to make a SaaS out of this solution, though, as I think 99% of problems are not solved by having machines closer to their users.
My favourite kind of technology is technology that either takes something that was impossible and makes it possible, or that takes something that was too hard to do and reduces the difficulty to the point that you chose to do it when previously you would have chosen not to.
Fly.io fits that latter category perfectly. Global distribution was generally Too Hard to consider for my projects. Now it isn't.
Right, and with fly.io it is easier to move our chunky, chocked full of latency code closer to the user than remove the internal latency. It is kind of an Amdahl's Law of planet scale serving. I get 100ms for free and I don't have to touch my code.
Not only latency but possibly also the cost / availability of massive egress. This is why e.g. YouTube has local caches around the world. Other heavily-hit caches with heavy content may make sense, too; I can't easily imagine a case beside serving video, though.
It is also about pure network capacity.... if all of the traffic on the internet has to traverse the entire path to a central data center, there wouldn't be enough backbone capacity
Steam and other game distribution systems also have an extensive network of edge caches around the world, and Linux distros have had local mirrors since forever.
It’s also pretty common for people running large LAN parties to run a local Steam cache so that when everyone in the building decides to download a game on the list of tournaments it’s coming over the local network rather than downloading hundreds of copies from the Internet.
That's an interesting point. However, I wonder if there are extra costs to serve a request from Australia to the US (there are definitely extra costs but I wonder if either the user or server pay them). If these costs are exposed to either of the ends, then it might be cost effective to create something that serve requests from local caches.
I don't know about now, but many years ago, it was common for some Australians to have different prices or caps to AU vs non-AU destinations, and for some European customers to pay more for trans-atlantic traffic. I've never seen destination specific charging in the US.
My guess is the cost differences are still there, but the increases in capicity and decreases in all costs combined with the difficulty of users to control traffic at that level mean that you would really only see this if you're buying a lot of transit. If you're just a residential customer, it might be more likely to impact you as your ISP may have more congestion on oceanic routes rather than an explicit charge.
I do occassionally see hosting operators that will optionally charge more for access to some routes that are better but too costly to include in a bundled rate.
Most of the big operators have peering agreements in place, but that doesn't mean every participant has infinite bandwidth. Google Global Cache and Netflix Open Appliance go a long way to reducing costs by avoiding interconnect where possible.
> Most pieces of technology create as many problems as they're meant to solve. The cost-benefit is always around whether or not the solved problems are worth the cost of the new problems.
It was an interesting decision to make a SaaS out of this solution, though, as I think 99% of problems are not solved by having machines closer to their users.