Maybe you believe in edge computing, or in IoT or AI, or maybe carrier cloud, or all of the above. The main thing is you believe the future requirements for applications and hosting will be different, and so the data centers and servers of the future will be different. The obvious question is what these differences will be, and how might they impact vendors and even software.
In any given economy, the traditional business applications tend to grow in their need for processing power and information movement capability at a rate proportional to GDP growth. Transaction volumes relate directly to the business exchanges associated with commerce, which map pretty well to overall economic growth. Furthermore, these transactional exchanges are little different from those of the past, so the future of IT would be simple evolutionary growth if we assumed that future data processing was purely transactional.
What IoT and AI represent are a non-transactional paradigm first and foremost, and these are actually only individual drivers of the broader paradigm of event-based computing. What event-based computing does is get IT processes closely coupled to the real world, via things like sensors (IoT) or a form of analytics (AI). The idea is that if computer systems could respond to real-world conditions they could provide direct support for a lot more than business transactions. Worker productivity might be enhanced significantly, we could introduce automation to things like driving, and we could contextualize user/worker requests to provide insight without so much work predefining search criteria or asking questions.
Transactions of the kind we’ve had for decades are “pre-contextualized” and “pre-packaged”. The originator of the transaction has decided, and has framed that decision in the form of a well-understood sequence like look-update-check. Future computing seeks to involve IT earlier in that sequence, which means that the things that the worker used to make the decision that launched a transaction are instead used by software to help, or do, the heavy lifting.
What, then, can we say about the event-based future, in terms of requirements? I think there are ## specific differences that will evolve, if IT and platforms are really going to change.
The first is that the future will be more network-intensive than the present. If you think of an application like opening a gate, the process of making that happen if the driver of a truck asks it to be done, versus if software analyzes the contextual relationship between truck and gate and makes the decision, is a shift in network involvement. The former is a simple transaction, and the latter is the gathering of information on truck position, gate position, relative speed, authorization/expectation, and a bunch of other things.
The key phrase here is “network-intensive”, which doesn’t necessarily mean traffic-intensive. Events typically don’t carry a lot of data, and so a large volume of events doesn’t necessarily mean a lot of traffic. In fact, M2M exchanges that don’t have to worry about human readability may actually have less data associated with them than a similar “human” exchange. It also doesn’t necessarily mean “low-latency”, but it does mean that there is a latency budget associated with a series of events, based on the human tolerance for delay and the impact of total delay on the system that’s being controlled.
The speed of light in fiber means that a signal would move 127 miles in a millisecond and cross the continent in about 20 milliseconds. In that same 20 milliseconds, a person walking would cover about an inch. A vehicle at 60 mph would travel about 21 inches, and a jet at 600 mph would move almost 18 feet. The importance of network latency is obviously dependent on what you’re expecting to be happening during the delay. However, network latency is almost surely not the major factor in the latency budget for an application, and that raises our next impact point.
In order to manage latency budgets, future applications will have to be designed for event anticipation and hierarchical event processing. Getting a record from a large shared RDBMS might well take 20 milliseconds or more in itself. Paging in memory could take that long too, and according to users who’ve shared their functional/lambda testing results, spinning up a serverless app in the cloud would take much longer than that. The point is that there’s no point to thinking about the latency difference between a server 10 miles from the point of activity and one a thousand miles away, when the application itself will spend much longer than that processing the event.
Event anticipation is the process of getting ready for an event, having the compute resources available and waiting, and having the necessary data in place instead of having to go get it. In order to do event anticipation, you need to have some understanding of the flow of the system you’re processing events for, and that means a mechanism for hierarchical process modeling.
Say you have an event-driven system to open a gate. If you visualize this as a transactional system, the driver pulls up to a keypad and enters a code that then authorizes the gate to open. Lots of wasted time, so suppose you put an RFID tag in the truck and had it read at that same kiosk where the code entry was done? The problem is that the driver still has to slow down or the gate wouldn’t open fast enough. The right approach would be to have the ID read perhaps down the road a hundred yards, at a point where the facility was being entered and not at the gate point. The authorization to open the gate (or the denial) could then be pre-staged to the gate point, and if entry was authorized the gate would open.
You can also use hierarchical modeling to do complex event processing (CEP) behind a primary event handler. You get Sensor A input, and while you’re doing the immediate processing needed for that you also send it along to a CEP element, that decides that the next event will probably be from Sensors C or D. The necessary information for those events can then be pre-positioned and the resources prepared. All this does more for latency than running the processes close to the events versus far away.
This doesn’t mean you don’t need edge computing, at least in some situations. The problem that edge computing solves isn’t event latency but event volume, which is our third point. Haul events from the geography of a telephone exchange to a central-office data center, and you have a population in the tens of thousands. Haul it from a metro area and you have a thousand times that population, which means a thousand times (or more) the number of events. Can you process that level of event density with enough efficiency to maintain your event budget?
Edge computing has another benefit, which is to allow for a difference in architecture between “edge” and “core” data centers. Toward the edge, things are biased toward event-episodic things, and toward the core toward more traditional database and analytical things, with an emphasis on process latency control. You might want to employ AI in a different context in each place and in between. You’re very network-centric at the edge, more database-centric in the core. You’re doing almost embedded-systems applications at the edge and traditional data center work inward.
The primary issue with event processing that crosses everything else is that you need more memory on these systems. You can’t afford to do a lot of paging or you create latency issues, especially if you have limited I/O speeds on the systems. The deeper you go, the more memory you need because there will always be more processes going when there are more users, and more users are inevitable with deeper data center positioning.
With the memory issue comes efficient task management. One of the problems with cloud/serverless today is the latencies that develop from the scheduling and loading of the functions/lambdas. If event processing is to reach its full potential, then we need to be able to run things on demand. I think the problems here arise from the fact that the media latched onto the “serverless” model as being the important one rather than the “functional” model and as a result, cloud providers are reluctant to do anything (like scheduling persistence) that would undermine that vision.
Obviously, all of this is complex, not even considering the question of how any major change in network or IT paradigm gets funded. Event-based services are difficult to conceptualize lacking any model infrastructure in place on which they can deploy. That infrastructure is difficult to deploy lacking any confidence in a profitable mission, and lacking any real sense of the architecture of these futuristic IT systems.
Perhaps the focus on “edge computing” or “AI” or “IoT” or even “5G” is a trivialization of the real issues, driven by the simple fact that the real issues are too complex for our current buyer/seller/media symbiosis to deal with. It’s the mission that ultimately sets the requirements for the technology, not the other way around.