The one unsurmountable obstacle I see in moving to core once again is the limiting effect of the speed of light.
Yeah, I was in a thread on the paid Fastly board recently where someone was claiming that remote surgery was an edge-compute application. Which, of course, it isn’t - it’s an end to end command application. Even so, when that person said a 10ms delay was the maximum tolerable and that remote surgery would be done 1000 miles or more away, well I had to point out that was impossible. The speed of light through the best fiber optic cable over 1000 miles would take 16ms - and that’s without repeaters, routers, copper to fiber conversion at the ends, etc.
I think we have to be careful about the edge compute hype. It’s not for remote surgery, and it’s probably not for autonomous vehicles, either. When you unlock your iPhone with your face, that computation is done at the edge - meaning the phone itself. This is the ultimate edge compute, and is done for privacy reasons. For navigation, there’s no reason why a CDN couldn’t provide traffic information to vehicles that then compute the best route locally. Mostly today that’s done on either central or edge servers, but privacy concerns may force companies to switch.
So, the question in my mind becomes - when is the best place to perform compute not central and not in the device itself? That would seem to be situations where the device is underpowered and either the central server is over-taxed or the latency is too long. This equation with parens:
**Underpowered End AND (Overtaxed Central OR High Central Latency) = Non-Endpoint Edge Compute**
So, do not take just latency or off-loading of central servers on their own. And don’t forget to factor in network reliability and privacy concerns.