> Apple/Google surely know how to run a data centre, and there doesn't seem to be much that couldn't be hosted just as well by them as by each telco
Because Apple/Google can only run so many data centers. And these DCs are all too high-latency / "out of the way" of the connection path between the user's device and the devices it wants to talk to, to make "diverting" the connection path to one of these DCs worth it.
Besides that, though — doing such "diversions" would massively increase cost, because it would turn a one-backbone-path (or sometimes even zero-backbone-path) route into a two-backbone-path route.
Instead of,
userA → ispA → userB
and/or,
userA → ispA → backbonePath → ispB → userB
you'd instead have:
userA → ispA → backbonePathA → Apple/Google → backbonePathB → ispB → userB
Apple/Google would have to
pay for the bandwidth to connect the two users to
their own network — where, in the case of a user running e.g. a BitTorrent seed-box, this is an unbounded downside risk! (Remember that by the design of such an "offload" system, it
does not charge the customer for network traffic that transits through it — only for compute. Just like Cloudflare doesn't charge for basic proxying, only for Cloudflare Worker compute time. This will
only ever make financial sense if your edge compute is "in" the existing connection path — i.e. hosted in the same DC as one of the path's existing hops.)
Now put yourself in Netflix's shoes. You don't want to deal with residential ISPs; they're usually large conglomerates that have more bargaining power than a random commercial colo facility in a city would have. But you do anyway. Why? Because, by doing so, you get a connection to the ISP's customers that is:
- extremely low latency
- extremely low bandwidth cost (because there's no need to traverse a backbone for any hop — the CDN's data can stay on the un-congested "residential streets" of the ISP, without ever needing to get on the "highway" where it would have to fan in and wait on an "on-ramp")
- never-degraded QoS — because their traffic on the residential ISP's network is just delivered with a default priority class (like everything else on that network, other than maybe the residential ISP's own OTT VoIP-based POTS service); whereas, when traversing any backbone, other providers who were willing to pay more per byte (because they had far fewer bytes to send and valued them more — which is basically every provider compared to a movie streaming service) get higher priority classes, narrowing the virtual pipe [= re-allocating to fewer circuits on circuit-TDMI backbone routers] and so degrading service for the CDNs whenever other higher-priority-rate traffic wants to flow.
The argument for Apple/Google putting their edge compute offload into residential ISP DCs would be exactly the same. It takes a network path that the customer was already establishing anyway, and adds a place for a "user-programmable virtual router" to live in that network path — without lengthening the path, making QoS worse, or any of that.
---
But let's go at this another way: if the cost/benefit worked out in favor of Apple/Google doing this in their own DCs... then why wouldn't they have already offered this years ago?
Apple might not be a B2B cloud provider that has hypervisor clusters ready for customer use — but Google certainly is. Why isn't "Android Offload Services, powered by Google Cloud Run on ARM" a thing?
What I said above (doing so creating a network "diversion", doubling backbone connections, wrecking QoS, etc) still applies.
But I think there's another obvious reason: if Apple/Google ran the DCs themselves, then this is something that would require that you pay Apple/Google a subscription fee for. Without a subscription fee, it'd just be a money pit — one a short-sighted CFO would either never green-light, or cancel after a single quarter.
And yet, a subscription model can't be the model used to support the very first instance of such a service at its inception, either. "Workload offload" is something with (currently) zero customer education behind it — i.e. it's something that customers would have absolutely no understanding of the value of, and so would never want to pay for, let alone sign up for a subscription they might not already be paying just to receive, until they see the value of it demonstrated in at least some other market, somewhere else.
These two properties create a seeming catch-22: given their corporate structures, Apple/Google can't subsidize it themselves; and given lack of user education, they can't immediately charge for it, either. So what do they do?
Well, if Apple/Google can talk someone else into hosting their compute racks, in such a way that the CapEx of deployment is Apple's/Google's, but the initial few years of OpEx and revenue for the effort winds up on that other party's balance sheets — then things could work. It wouldn't make money, but it also wouldn't (look like it's) costing Apple/Google any ongoing money — so they'd be able to keep the project going for its first few years, until user education played out and people started demanding it.
What properties would this "someone else" doing the hosting need to have?
Well, they'd need to be a near-commodity business, always in desperate need of "differentiators" to swing customers — i.e. new things that are nearly nothing for them to set up and run, but which they can then bundle into some subscription service they're charging customers for, such that having this feature makes their $60/mo plan look just ever-so-slightly more compelling than their competitors' $60/mo plans.
And they need to have a willingness to eat any short-to-medium-term OpEx costs associated with doing so, looking toward the long-term profits of such systems. They need a long demonstrated pattern of doing exactly this, over and over.
Ideally, they'd be paying virtually no "real" OpEx — as they'd already have some under-populated DCs laying around, with bulk-purchased power commitments and bandwidth provided as some kind of internal sweetheart deal.
Even more ideally, they'd have lobbyists who would get them massive government "technology evolution" subsidies for doing anything like this, that would more than pay the OpEx costs.
Know any companies like that? Because I sure do!
---
That being said, I would imagine that the math would work out slightly differently for different residential-ISP customer-base compositions.
It might be impossible to launch "workload offload" as a feature in the Bay Area or other tech-hubs at first, as those would be unprofitable if given away for free, due to the number of novelty-seeking nerds who'd actually make use of (apps that make use of) the service from day 1. The ISPs would likely get quite irritated if Apple/Google were coming into their DC to constantly rack more and more of these servers — even if the literal OpEx works out, they'd have to staff up their DC ops just to handle the increased hardware churn rate!
As such, I'd expect an ISP's workload-offload offering, to be something rolled out first in big cities that aren't tech hubs, and "proven out" there, mostly by users using the feature entirely unaware that they're doing so (because it's the app on your phone that decides to launch a workload, not you-the-user!)
Viral user education about the benefits of such services would filter out from such cities, to the rest of the world, where demand for them would build over the course of maybe... two years? — for ISPs to then start actually billing (and usage-based billing, with flat-rate billing only on premium data plans!) for the service.