Wherever “the edge” is hosted, what gets hosted is software. If there is such a thing as “edge software” as a subset of “software” or “cloud software” then there has to be development, and development has to be based on some set of what’s popularly called “middleware”, a toolkit that facilitates development by providing a means of implementing important tasks likely to be a part of most applications. What are the factors that determine what this middleware toolkit contains, and do we have examples of any of it? Those are the questions we’ll address in this third in our edge computing series.
I proposed in earlier blogs in this series that edge computing was justified by the requirement for low latency in processing. I also proposed that the low-latency missions were almost surely event-driven, because the primary driver of latency sensitivity is the need to couple processes to real-world conditions that won’t wait for you to get around to them. We have event processing software models today, so let’s start by looking at them to see what works best.
Enterprises and even vendors today tend to associate event processing with public cloud functional/serverless computing, but those are public cloud features and rather than supporting edge computing’s latency requirements, they actually add to latency. A serverless element is loaded on demand, and the load latency usually exceeds the latency improvement that could be had by moving an application closer to the edge source. There are multiple cloud providers offering serverless, and multiple service options, but latencies can range from over 100 milliseconds to nearly a second when a function is “cold started”. In addition, serverless pricing favors applications with modest event generation rates, both because higher rates of event generation would suggest that the process elements should stay resident and because pricing models for serverless work only with fairly low event duty cycles.
Container hosting of event processing, which keeps the process elements loaded and ready, adds relatively little (perhaps 5-10 milliseconds) to overall latency. If event duty cycles are high enough, containers would also likely be cheaper than serverless, but the big advantage of containers here is that the linking of events to containerized processes doesn’t require cloud provider middleware, so it’s possible to use generalized event software in the cloud, on premises, or in hybrid form without paying for special cloud event processing or event routing tools.
Cloud providers do offer event processing, but you won’t find it in the list of products on their websites. Instead, they offer IoT support, which validates my view that IoT and some model of digital twinning is the key to the edge. However, the specific IoT linkage to event processing means that there isn’t a clear connection between event-oriented service activities of the type that 5G would generate, and public cloud middleware tools. It also suggests that, at least for now, cloud providers aren’t looking as much toward generalized edge computing as perhaps they could or should be. Or maybe they’re looking at it through the wrong lens.
There’s nothing generally wrong with having an IoT bias for your edge strategy, given that IoT is a very likely application driver. The specifics are the issue. IoT’s overwhelmingly about some sort of process or activity control today, and that particular mission is much more likely to stay on premises unless the event sources are highly distributed, which usually is not the case. Thus, we’re not building toward a new and larger set of edge applications. Another issue is that much of the IoT support offered by cloud providers has more to do with the mechanics of the IoT environment, registration of devices, and so forth, than with the deeper requirements of applications.
What would differentiate “generalized edge computing” from cloud computing or event processing? It would have to go back to the points of my first edge blog. Component/application portability and hybridization, dynamic distributability, and security are all things different for the edge than for the cloud. Once these elements were sorted out generally, there would also be specific things relating to the mission requirements of the primary drivers. For example, if we accepted my suggested digital twin approach, we could expect to see tools to establish and sustain the twin, and to use AI/ML to draw inferences from it and feed back those inferences in the form of real-world changes via “actuators”.
Concentrated event sources, like warehouses, factories, or hospitals, would be candidates for implementation using traditional tools and practices. Even event-processing tools like those for complex event processing, or CEP (including open source tools like Esper or Open CEP) or streaming tools (like Tibco Streaming or Fluvio), would serve many of these applications. However, if the concentration of event sources happens to concentrate multiple systems of event sources, or if the sources are distributed or mobile, then it’s likely essential to create a model of the real world that events from multiple sources update as needed. This model, as I’ve previously mentioned, is then the basis for both controlling things and drawing insights.
The “real world” is a distributed, interreactive, system. Most event processing software deals with a single stream of events, though some CEP software could be adapted to the mission if the real-world system wasn’t too complex. As the complexity builds and the pace of event generation expands, it becomes more complex to handle with any of the current software.
The scope of a digital twin, or of any real-world-related application that’s a candidate for edge hosting, is the scope of the real-world system that it represents and controls. To the extent that the application’s real world is distributed, it’s likely that the application will also have processing depth, meaning that an event flow might pass through multiple processes designed to deal with more stringent latency requirements near the edge and more forgiving requirements deeper. It’s also likely that the application will look like a series of interconnected application components arranged in a structure of some sort.
In distributed-event-source or mobile-event-source applications, the obvious problem is process coordination. If the event source is concentrated and static, conventional event-flow strategies will work fine, even if the process depth spreads components from edge to cloud to data center. Where there’s a distributed or mobile source, the latency requirements associated with each step through the process depth required map to different hosting places depending on the source of a specific event. Each process step is essentially an autonomous element that has to respond (perhaps) to the event and also coordinate (perhaps) with other steps in the process and even steps in the processing of other events.
Dare I point out that this isn’t far from the service model that the TMF’s NGOSS Contract described and that my ExperiaSphere project expanded upon? Each event might first intersect an edge process, which might be local to the source or edge-as-a-service-hosted, and there generate any time-critical response, then dive deeper in the form of either a repeat of the original event sent to a deeper process, or in the form of a newly generated event with a deeper destination. Applications would then be a series of state/event systems that defined their own process-to-state-event relationships in a table.
A good candidate for generalized tool for edge/event processing would be a framework to establish just that, and since there is a good deal of affinity between that and the telco service world, it is very likely that this tool would also be suitable for 5G and even other services. The real world is distributed and asynchronous, just like a network, and just like a network’s lifecycle management needs to be orchestrated holistically, so does any real-world, digitial-twin-based, application of the edge. Thus, the edge-orchestration tool would not only support 5G, but it could be the basis for other real edge applications.
If this is true (which I obviously think it is), then we’ve missed an important piece of both IoT and edge computing by failing to address the question of how we model real-world systems and orchestrate components and their lifecycles within that model. That offers some aspiring edge giant to step up and provide that missing piece, and by doing so perhaps gain a major market advantage.