What, exactly, is the potential for edge computing? It seems to me that we’re seeing more of a need for the “what-is-the-potential” or “what’s-the-justification” sort of pieces every week. Most of that, I think, is generated because there’s an endless appetite for exciting things, and less so for true things. The problem is that excitement doesn’t translate directly into technology opportunities. Is there any opportunity for edge computing?
The popular themes on edge computing make points like “the edge will be much bigger than (or will replace) the cloud” and “business applications need very low latency to be effective.” We even have “the edge is eating the Internet.” None of these points are valid, but for the first two, we could make similar statements that would be true, so maybe the best way to open this is to contrast the stuff that’s not real with that which is.
The size of the edge opportunity is a good place to start an edge discussion. Edge computing is the subset of cloud computing that deals with a need for exceptionally short control loops, largely because of real-time, IoT-like, applications. There are many such applications today, but they are realized using “edge” facilities on the users’ premises. There is IMHO no reason to believe that these current edge applications would move to a public edge computing model, any more than there is to believe that everything is moving to the cloud. I don’t know any serious application architect who believes otherwise.
So how much of an opportunity is there? Today, it’s in the noise level. However, I’ve been saying for a decade that there is a class of new application, a new model of applications, that I’ve called “contextual services”, and this new class could generate significant incremental revenue in both the business and consumer space. If that new class of application were to be deployed optimally in both spaces, it could justify the deployment of about a hundred thousand new edge data centers. The great majority of them would be “micropools” of resources, though, comprising a couple racks of servers. In terms of real edge hosting revenue, the potential of these pools would be roughly three-quarters of what I believe the total revenue potential for cloud computing would be.
If close to the user is a justification for the edge, because latency is a barrier to an application, then with the user is better than any other place you could put edge resources. Today, industrial, warehouse, and process control edge applications run (according to enterprises) an average of 450 feet from what they’re controlling. Ten miles of latency is what you might expect, optimistically, for the distance to a reasonably efficient public edge pool, and that’s almost one hundred twenty times as far.
Couldn’t you run today’s cloud applications at the edge, though? Isn’t that a reason for edge computing to displace cloud computing? Yes you could, but no it isn’t. The problem is that edge computing economies of scale are limited by the relatively small population that are close enough to an edge point to justify using it. Micropool, remember? Public cloud computing offers better operations and capital economies than you could enjoy at the edge.
But what about the benefit of low latency to those cloud applications? Human reaction time is around 300 ms, which is 6 times the round-trip delay associated with transcontinental fiber transport of information. So let me get this straight. You want to deploy thousands of edge data centers to reduce transport delay that’s already a sixth of human reaction time? At the least, it would be cheaper to improve the connection from the users’ access network to the cloud.
That raises the second point, which is that business applications only work with low latency. Well, we’ve built a multi-trillion-dollar online economy on much higher latency. Transactional applications work at a global scale today without edge computing. We can take orders, support content delivery, and manage businesses with applications that haul data all the way back to a corporate data center from anywhere in the world. How much latency do you suppose that involves?
So, you might be thinking, that’s it for edge computing. Not so. As I said, you could modify the statements I opened with to create new ones that could well be true.
“The edge will be bigger than the cloud”, for example, could become “The potential growth in edge computing revenue is bigger than the potential growth in cloud computing revenue”. That’s true. “Business applications require very low latency to be effective” becomes “New applications that would transform business productivity require very low latency to be effective”. That’s also true, and the combination of those truths is what either justifies the edge or proves an impossible barrier for it to scale.
Why is low latency important for an application? The answer is that the application has to be synchronized with real-world activity, both in terms of sensing it and in terms of controlling it. There is no other meaningful application for low latency. Why can’t that be achieved with local processing? Answer: Because available local process points cannot do the job. When would that be true? Answer: When users are highly distributed and users are mobile.
What I’ve called “contextual services” are information services targeted to users moving around in the real world, wanting computing/information support for their activities there, delivered automatically in response to a service knowledge of what the users are trying to do. The only credible conduit for the delivery of a contextual service is a smartphone (perhaps married to a smart watch), which clearly can’t host a lot of application logic.
Contextual services require an “agent” process that runs in the edge/cloud and collects stuff for delivery, as well as interpreting contextual information either received from the user’s phone or is inferred from user searches, calls, texts, location, and so forth. To be relevant, it has to be able to absorb context from the user (directly or indirectly) and deliver insights that are real-time relevant.
So isn’t this a business application that demands low latency? Yes, but it’s not a current application, or even a justification for an application that could be considered validated by demonstrated opportunity and supported by available technology. Contextual services are created from an ecosystem, no element of which is currently in place. To say that they validate the edge makes too many presumptions, even for someone like me whose modeling has predicted that the market would be justified by the mission. We need to see more of the contextual services model before we can start using it to justify edge deployment, or claim it could rival the cloud.
I object to the kinds of statements I’ve opened with, because not only are they not currently true at all, but also because what’s needed to make them sort-of-true is a long way from happening. And, sadly, the statements could hurt the evolution of the real opportunity by promoting the idea that a mountain of real work doesn’t lie ahead, when it does. It will stay a mountain if we never get started because we think we’ve already climbed it.