Edge computing is another of those topics on the verge (if not over it) of being over-hyped. Part of the reason is that we don’t really have a solid definition or taxonomy for the space, and part because we haven’t really looked at the business case. I’ve been trying for a year to get some good inputs into this, and I just finished a run through my enterprise contacts to ask for their contribution. As usual, I’ve then pushed the results into my buyer-decision model, and this blog is about the results.
Let’s start with taxonomy. “Edge” computing broadly means putting a smart agent close to the point of action, which users define as being the point where information that requires attention originates, and to which the responses are returned. In somewhat-technical terms, then, it’s at the near end of the control loop. In this definition, “close” could mean right alongside or at the point of action, on premises, or back further in the network.
What we should do is consider “cloud” computing to be a collection of distributed hosting resources that are allocated as a pool, not dedicated to an application. Edge computing is then a subset of cloud computing, where the resources are hosted at the “network edge”, meaning the closest accessible point to the user demarcation. “Local” computing is a distribution of the edge computing resources to the other side of the access connection, meaning on the customer’s premises.
Both users and third parties (like network operators or cloud providers) can build clouds, and thus deploy “edge computing”. The distinction between an operator/provider cloud or edge and a user cloud or edge is the scope of applications that can draw on the pool of resources. Since a local computing resource is unlikely to be available to anyone other than the owner of the place it’s deployed, that distinction is more meaningful when you get to network-edge hosting.
All edge computing has a disadvantage. Distributing computing, in this age of super-microprocessors, is likely going to reduce the utilization of a given computer by reducing the applications suitable for hosting there, and multiple distributed systems are more expensive to support than the same computing power would be if it were centralized. This tends to reduce economic efficiency overall, so there has to be some compensating benefit that would drive edge deployment.
Generally, users see the benefit of edge computing to be reduction in latency, which means the time between when a signal requiring attention is originated and the response is received to be acted upon. You hear a lot about latency these days because it’s also cited as a benefit for 5G, so it’s worth having a look at what might be latency-sensitive applications to assess their characteristics and credibility.
The one we hear about the most is autonomous vehicles, and in my view this one is the most problematic. The systemic self-drive application is obviously something that enterprises themselves wouldn’t deploy resources to support, but enterprises do have autonomous vehicle missions in-house. In fact, the in-house missions are more credible as edge computing drivers than the systemic ones.
The problem with general self-drive cars as an edge computing driver is that every indication says that the self-drive vehicles would make onboard decisions rather than cede control to an external process. Even minimal process latency could derail self-drive applications (in a hundred milliseconds, a speeding vehicle would move almost ten feet), and were there to be a network or processing outage (or a DDoS attack) you could end up with deaths and injuries. Central control of “cars” is out.
What could be “in” is control of material-movement systems whose major challenge is avoiding each other. You can interleave forklifts rather nicely if you control them all, and that to me sets the requirement for realistic edge support of autonomous vehicles. If your vehicles are moving about in an area where other such present the only regular risk of collision, you have a great autonomous vehicle application.
Where are they? Users say that companies who operate warehouses of any sort, do large-scale material transfer between vehicles, send vehicles to pick up things in a holding yard, and so forth, are all credible applications. That means manufacturing, retail, and transportation fit the bill. In my survey (164 users), 22 said they could see some applications of edge-controlled autonomous vehicles.
But where’s the edge? In nearly all cases (all but 4 in my sample), the users said the requirements were “local” meaning in-building or within several buildings in a campus, and would be covered by local networking (WiFi). None of the “local edge” candidates thought they’d want to host the control point on someone else’s systems; they saw themselves with an “appliance” that did the job. Thus, they didn’t see this edge application as requiring 5G or public cloud hosting at all. Those who did were envisioning large-scale facilities that were more like junk yards than like buildings, and where material was likely left out in the weather. All four of the companies who saw the larger-scale edge mission were transportation companies; rail, ship, trucking, and air.
Another edge mission you hear a lot about is in the medical area. I recently read a piece talking about how low latency could be critical in handling a patient who was “coding”, meaning sinking into a possibly dangerous state. The problem, of course, is that this sort of problem is already detected locally by the devices hooked to the patient. Ceding it to something more centralized, even something on the same floor of the hospital, risks a significant problem if that facility fails or is disconnected, and for little gain given that the expensive part of the monitoring is part of the patient’s attached sensor web.
Some healthcare-related users in my study group did believe that where a patient’s condition was monitored by multiple devices for multiple classes of reading, some intelligence to correlate the conditions being measured and making a broader determination of whether things are going well or starting to slip, might be helpful. However, again, they didn’t see this as requiring edge computing support from others, instead focusing on using specialized “hardened” local devices on each floor. They also believed the communication could be handled by WiFi, and would not require 5G.
Outside these two focus areas, enterprises didn’t offer me any examples of a latency-critical application. My own work with enterprises (focused on transportation, medical, and banking/investment) doesn’t show anything different, either. Thus, while none of this suggests that there is no mission for edge computing, it does suggest that enterprises don’t see a clear mission. That, in turn, suggests that for the moment at least, edge opportunity is either hype or it’s dependent on systemic changes in services. The mass market, the consumer, is the only credible driver of the edge.
The reason that’s not a good thing for edge-aspiring vendors is that systemic changes in services means exploiting IoT and contextualization drivers, and both those areas almost mandate participation by network operators. Operators, of course, are legendary for studying something to death, and then coming up with a solution that wouldn’t have worked even if it had been delivered in a timely way.
What runs at the edge are higher-level services. They’re digestions and correlations of information collected over an area, fit into a form where personalization-sensitive features can apply them to improve information relevance. There are navigational services that would promote the value and safety of autonomous vehicles, and these services’ value would increase as the timeliness of their information increased. To make their data both broadly useful and timely, you’d want to host the services close to where their data was collected, and then publish them at low latency to the prospective users. This same model would be optimal for contextual or personalization services, and I’ve blogged about the nature of contextual services before.
A service-driven approach to IoT and contextualization would be a powerful driver of edge computing because of its dual collection/publication makeup. You have to collect sensor data, correlate it, and publish it fast enough to be useful. Services, of course, also lower the cost of the on-board or in-hand technology needed to assimilate IoT or contextual/personal information fields, so there’s an offsetting benefit to any hosting cost. In short, these services are the key to edge computing.
Our biggest problem in edge computing is that we implicitly devalue the only application set that could actually make it relevant. We talk about “IoT” as a sensor game, envisioning perhaps an autonomous vehicle making a zillion lightning inquires to sensors in its path and deciding what to do. Forget it; the cost of that would be enormous and most of the vehicular safety features have to be on-board so they aren’t as likely to be exposed to failure or attack. It also begs the question of why someone would deploy (and pay for) those sensors. Sheer human goodness?
Like so many other technical innovations, edge computing is all too often applied but not justified. We don’t doubt that there a lot of things you can do with edge computing, and there’s no shortage of tales regarding what they are and how wonderful they’d be. That’s not our problem, though, because we don’t have edge computing to apply. What we need is something that justifies its deployment, and like other technical marvels, we’re coming up a bit short on examples. The one we find that’s truly credible is just too complicated for many to be willing to wait for or bet on.
So to summarize, there are some enterprise applications for edge computing in certain verticals, but it’s doubtful whether these applications could drive significant edge computing deployment. Certainly, generalized prospecting for edge opportunity among enterprises would be a very unfulfilling experience for the sales personnel involved. There are great opportunities for edge computing as a part of cloud computing infrastructure, where applications that digest and present insight from sensor data are added to traditional hosting. It’s then a question of how we can get those applications promoted, because nobody is going to build out edge computing in the hope it’s eventually justified.