We hear a lot about the edge and edge computing, but we hear a lot about many things that don’t all turn out as we expect. How important will edge computing be? What do we even mean by “edge computing”? You get all sorts of answers to these questions. Gartner says that by 2025, 75% of all data processed would be processed at the edge. That sure sounds like a profound shift, if it’s anywhere close to accurate. Of course, we need to look at all those questions to see whether it is.
As I’ve noted many times, we already have edge computing, and we have a lot of it. These days, manufacturing, utilities, transportation, and retail all rely on what many would call “edge” computing, which as I’ve also noted is really just a subset of “distributed computing”. Generally speaking, companies adopt edge/distributed computing for one or both of two reasons. First, that the application requires a very low-latency connection to some real-world activity, one that can’t easily be offered through a WAN connection. Second, the application demands very high reliability, and so local resources with suitable backups are better than resources strung out along a complex chain of connections.
The fact that we know what justifies the edge, and that we already have it, certainly suggests that we could assess the amount of edge computing that we have, or are likely to have given the evolution of the current drivers. If we presume those current drivers are the only drivers, then what we could say about edge computing is that it’s probably little more than a niche opportunity, incrementally speaking. We could do more in verticals like transportation and government (military included, obviously) but in most cases the application targets would likely be ones that augmented local-edge technology of the type we already have, with a kind of deeper edge-aggregator layer.
Everything that qualifies as edge traffic, I think, is related to generated “events” that are both created in the real world and that invoke a real-world response. IoT surely fits that, but you could also say that retail point-of-sale applications that involve scanning barcodes on goods to record purchases would fit the bill. The industry is divided on whether the latter is really “edge computing” or a form of distributed computing, because the local events will eventually generate retail transactions on an almost 1:1 basis. Could the 75% number include that data? If it does, then it is possible that “edge data” could make up 75% of all data, as we eliminate manual sales in favor of scanned and self-checkout mechanisms. But we do this sort of thing now, and so this source of events, even if it raised “edge data handling” to that magic 75%, wouldn’t really change the market much, if at all.
What could change that could only be a new set of applications that first validated one or both the requirements for edge hosting, and second were broadly targeted enough to create a major market in themselves. It’s difficult to see how these conditions could both be true for an unrelated set of applications, so I think we have to assume they’d only come about through a paradigm shift. Given the edge hosting requirements, I think we can assume that they have to be real-time, real-world, applications.
A real-time, real-world, application is one that generates events based on real-world conditions, meaning that it uses sensors to detect conditions or condition changes. It then feeds back responses to “effectors” that do something in the real world, anything from moving objects to changing conditions. In short, they’d have to be related to IoT.
The fact is that IoT is certainly the source of the current latency-sensitive applications, and some would classify the retail point-of-sale stuff as IoT too. In order for IoT to create a mass of edge opportunity, you’d have to see a transformation in what companies did with it. One possible, though perhaps limited, example is that of smart buildings, another the smart city. The point is that more edge activity is created by more IoT sensor/effector interaction.
I said, in a recent article in Network World, that edge computing was a subset of distributed computing, and I believe that’s true. What characterizes it, in programming/architectural terms, is related to distributed computing taken to a higher level. The edge applications, I think, are not only distributed but distributable, meaning that they can be instantiated somewhere at random. That implies two things. First, it’s likely that edge computing is based on middleware that you could say is analogous to the concept of WebAssembly. WebAssembly code is run in a browser and is based on a specific set of APIs that give it access, through the browser, to the outside world. That set is effectively middleware. Second, it’s likely that edge computing is built from functions or microservices, meaning that the elements are stateless and their outputs are a function of their inputs. You pass an edge element something and it operates on it. That means that you can pass that something to any instance of the element and you get the same result, which is what distributability means.
If we assume, as I would, that edge computing is about function hosting, then function placement is the next step to address. Functions run on demand, which means that you have to expect that the events they process are routed to the place where you expect the function to run, either because it’s already loaded and waiting, or because it will be loaded when the event arrives. Since latency is an issue, my assumption is that the primary model would be the pre-positioned, in-waiting, function. That means that unless the event requires only one function for processing, a default “eventflow” is plotted out, analogous to the workflow path of transactions, but involving a more sophisticated calculation of optimal positioning, not only for each individual function but for the entire chain. Each location would have to be picked based on the impact of the location selected on the overall eventflow, and on any turnaround responses that had to be generated.
Note that function hosting and serverless, often combined in cloud computing discussions, are actually somewhat separate things. A function could be deployed in a fixed location. A function could be deployed on demand, either to handle sparse events or to provide scalability, and everything in between. I think you need to presume that functions would be used because they give you the choice of on-demand scaling, but latency control requirements could well mean that the eventflow overall cannot survive too many on-demand function-loading delays. That has to be considered when structuring the application overall.
The presumption we have to make regarding edge applications comes in two basic elements, the eventflow and the workflow. Taking the last one first, we have to assume that eventflows will at least sometime trigger a transaction, which means that the “edge” piece of the application will yield to standard processing rules. When and if that happens for a particular event is determined inline by the flow itself, and it may well depend on a contextual series, which means that there has to be a point somewhere where state/event handling guides the process decisions.
But the eventflow is also potentially complex. It seems unlikely to me, based on my own experiences, that very many event functions would not return something, meaning that the processing of an event is really about generating an effector command in response. I think we could assume that while we might divide the processing into multiple functions, they’d likely be collected to be local to each other to the point needed to complete the effector response. That means the eventflow might have one or more state/event handlers incorporated within it, deciding whether to return a response, wait for an additional event, or perhaps pass an event along, or spawn a transaction.
The key here is that while you almost surely need to think about a multi-layered and distributed edge if you want to get off the local on-premises edge model, you can’t have too many layers and hops or you’ll accumulate latency. The idea has to be to use lower layers, including whatever is on-premises, to funnel off the interactions that are seriously dependent on low latency, and jump out and up in layers only when you have a better delay budget. I think we have to assume that eventflows stay on-premises or in the first off-premises layer, because jumping across provider boundaries is almost surely going to take more time, and threading the eventflow across different providers makes it difficult to plan out accumulated latency to optimize hosting locations.
The biggest problem with all of this is that the factors you’d need to consider to actually structure how eventflow and workflow processing would work are at least somewhat specific to the applications. Enterprises so far are using local-edge hosting and that means there really is no eventflow other than to and from the sensors/effectors. What might arise if we moved the edge off premises, or created another edge layer, is something we still need to explore.
