If event-handling and process hosting are the way of the near future, then (as I suggested last week) we would likely shift a lot of hosting and software development off traditional server platforms. There are technical considerations here, of course (and I noted the key ones last week), but the primary issue is financial.
Event processing depends on two dimensions of event characteristics. One is how often the event happens, and the second is how “valuable” in a commercial sense the event is. Obviously both these characteristics are graded and not polar, but it’s helpful to think of the extremes, which in this case would mean event frequencies ranging from infrequent to very often, and event values ranging from negligible to significant. The four combinations present great opportunities on one extreme, and nothing but cost and risk on the other.
Let’s start by looking at something we can dismiss quickly. Low-value events that rarely happen probably don’t justify any event processing at all. “An airplane flew across the face of the moon, relative to an observer in Iceland” might be one. If you want to get IoT funding for that one, good luck!
Now let’s search for some relevant insight, starting with the most extreme on the negative side, very frequent events of little value. A good example would be “cars passing an intersection”. OK, you probably can think of things that could be done with this information, but if you think about a place like New York City and the number of cars that pass each of the intersections in the course of a single busy hour, and you have a formula for minimal ROI.
Where we have this situation, the goal is to prevent the “event” from ever getting out of local processing in discrete event form. This would mean two things; that you want to use a cheap local technology to collect the events, and that you want to “summarize” the events in some way to reduce their frequency. Cars per minute? In a busy intersection that would probably reduce the events by several orders of magnitude.
Logically, the way to do this would be to have “agents” associated with groups of event sources. The agents would use some cheap technology to collect events, and then a second cheap technology to summarize them in some way. The agents would generate summary events (“Car Count for Intersection 5th and 42nd, 10:40 AM”). If we needed only summaries based on time, you could do something like this with a custom chip, at a very low cost.
Something else would consume these summary events, of course, and since there are fewer such events and they’d not likely require very short response times, you could place these other processes deeper in the network. In addition, it’s likely that the summary processes would be doing some kind of analytics, changing the nature of the process from strictly event-handling to something more “transactional”. Keep that in mind!
At the other extreme? That’s easy too—think of system failure or critical condition alerts. There’s water in a tunnel, there’s smoke in a warehouse. These happen rarely (hopefully) but when they do they could represent human lives and millions of dollars. Not only that, each of these events (largely because of their value) could logically be seen as having a wide scope of interest and potential to trigger a lot of other processes. Fire in a warehouse? You might have to dispatch engines, but also activate an emergency plan for traffic lights, extending far outside the area of the fire or the path of the engines, to insure emergency vehicles associated with other incidents could still move.
This event type might well create what could be called a “tree” or “cascade”, the opposite of the aggregation that happened in our car-and-intersection example. We’d want to provide a multicast mechanism, or publish-and-subscribe, to distribute this kind of event. Each of the secondary recipients (after our primary processing) would then handle the event in a way appropriate to their interests.
The examples of dispatching engines or implementing an emergency light plan show that these events might well need fast response times, but there are other cascaded processes that could be more tolerant of delay. I think it’s likely that many processes will require edge hosting, while others could tolerate deeper hosting. All, however, are likely to be local in scope, since an emergency condition can’t be handled easily at a distance. This high-value, limited-frequency stuff is thus a primary edge driver.
Now the in-between. High-value events that happen more frequently would likely be traditional commercial transactions. Think ATMs, mobile purchases, bank tellers, store register systems, automatic toll collection, and so forth. Another class of high-value events would be contextual events associated with a social or location service, including and perhaps especially advertising.
Commercial transactions, huh? That’s a theme common to the high-value-low-frequency stuff we covered earlier. I think we can safely say that event-handling in general will have two distinct pieces—a front-end part where we’re either summarizing or cascading events and applying limited response processing to highly time-sensitive conditions, and a longer-cycle transactional back-end.
The cloud computing players like Amazon, Google, and Microsoft all see this combination-structure for event software, and all in fact show it clearly in some applications. The front-end parts of the processes are “serverless” meaning that they’re designed to be spawned at need where needed, rather than assigned to a specific place. That requirement, and the requirement that they be spawned quickly to be responsive, means that you have to avoid complicated new connection structures, access to distant resources, etc.
All of this shows that the heavy lifting on edge computing would have to be handled by the relatively valuable and infrequent events, and secondarily by perhaps expanding the traditional notion of “commercial” transactions to include social/location/advertising services. It’s much harder to deploy and connect edge resources based on aggregations of low-value high-frequency stuff because you’d probably have to find a lot of applications and users to justify the deployment, and it’s hard to see how that happens without anything deployed.
It also shows that the cloud computing players like the three I already named have an advantage over the telcos and cablecos, even though the latter two have more edge-located real estate to leverage. The software structure of event-handling is well-known to those cloud guys. Google, at least, has explicitly evolved its own network to be efficient at process linking. Amazon, of course, is addressing its own limited edge asset position through Greengrass, which lets users host event processes outside of (forward of) the cloud entirely. Knowing what to do, not just where to do it, could be the deciding factor in the cloud.
Operators in their part have a tendency to see software the way they see devices. If you look at SDN or (in particular) NFV design, you see the kind of monolithic boxes lined with APIs that are the exact opposite of the design for optimum event-handling systems. Arguably a big reason for this is that operators tend to think of software elements that replace boxes—virtual functions replace physical functions. But if the future is things like IoT, then it’s about events not data flows, and that’s where the operators need to do some thinking outside the box.