Is Fog/Edge Computing Coming Into It’s Own?

We seem to be entering the fog again, at least in computing, and in a PR sense.  Just this week we’ve had a half-dozen media stories on fog and edge computing, but none of them really look at the issue fully.  There are, for certain, a lot of drivers for moving compute functionality to the edge, but is this nothing more than cloud computing with metro data centers?  Applications, and the benefits they generate, are the real drivers of technology change.  What specific drivers will control the fog/edge, and what do they demand?

Putting compute resources close to the points of user interaction, data collection, and process control has the benefit of improving response time or shortening the control loop from condition to action.  Almost everyone in the cloud space knows that.  Where we are still seeing a debate, at least in the implicit media sense, is over the specific application model.

Cloud applications for enterprises today tend to use the cloud as an elastic front-end, absorbing the web and mobile interface issues and prepping transactions from many different sources (often in different forms) for funneling into traditional online transaction processing (OLTP) applications.  The problem with this application model as a driver to fog/edge computing is that “response time” for the user will still depend on the back-end OLTP applications.  Sure, you can perhaps paint a form a bit faster with front-end components close to the user, but the dialog the user is looking for isn’t accelerated overall.

The fact that most OLTP applications won’t benefit from fog/edge means that most applications that involve direct human-system interactions won’t directly benefit either.  We have to look at M2M or IoT if we want to create fog/edge justification, but even there, it’s not necessarily easy.

Suppose I have an M2M application that accepts a sensor stimulus, sends a message to a system, and activates a process.  Is that just an OLTP application with the human removed?  The answer would depend on just what process I was activating, and that raises the big question with the vision of fog/edge computing.  For OLTP to benefit from fog/edge, we have to move the application itself to the edge.  Most businesses are years, even decades, from transferring all their core business applications into the cloud.  It may happen, but certainly not in the career lifetimes of people who bet their promotions on fog/edge success in the near term.

We know from industrial automation history that the average process control application isn’t a core business application in the traditional sense.  We already have M2M in factories, and we already depend on local processes to convert sensor data to action.  Is factory automation then the killer app for the fog/edge proponents?  No, because the events and the things being controlled are in a contained space and, in any event, are already being process-connected today.

Home automation doesn’t offer much more.  Home control isn’t a sub-second response problem, and increasingly people are putting more smarts in their homes, in the form of local controllers, to handle things like scheduling actions.  The home market is also very price-sensitive, which means that it would be easier to exploit fog/edge deployment with it than to drive that deployment in the first place.

If you believe in the media model for IoT, then in my view you are saying that fog/edge will never happen.  Self-drive cars, sensing a light turn yellow, come to a stop.  Yes, but do they do that because the car has polled the intersection sensor for light state and received a “Yellow” response, all of which would go through the network?  Every intersection would get hundreds of polls, and somebody would run a DDoS attack on the sensor and nobody would be able to move a car anywhere on the road.  We need to accept that IoT generates a whole new world of event-driven processes, and it’s those processes that would justify the fog/edge deployment.  Those processes and the events they handle also have very unique demands, and if we can’t meet the demands we can’t make fog/edge work.

Some events, generated by closed-loop process control systems and home automation, are much like transactions.  They are significant to a single process source, you emit them, process them, and do something as a result.  Most of the new-model events are not transactions.  They are significant to a wide and variable scope of processes, they may be directly emitted or emitted by a process as the result of another event, and you may do nothing other than pass them along.  We can’t frame event processing in the traditional way, and if you don’t believe that think of the cloud providers like Amazon, Google, and Microsoft who developed a new cloud model and even programming languages to accommodate event-driven systems.

Event-driven processes are the key to fog/edge, and to really address event-driven requirements we need to think of two “spaces”, an “event-space” and a “process-space”.  The event-space is a series of collectors and duplicators that distribute events.  It would have to be low-latency and so likely based at least in part on edge computing.  Events move in the event-space.  The process-space is a series of function points, places where you can host simple functions that intercept events (from the event-space) in specific ways.

The event-space isn’t just a pipeline or fabric for events, though.  The “collectors” and “duplicators” are all standard processes that are hosted there for the purpose of generating what would essentially be a series of event trees.  That’s because IoT events are events and not discrete polling responses.  A traffic light changes because it changes, not because all the cars ask for the current state.  In the real world, the sensor would feed a process, probably one of a number designated to be the source of traffic information for a given number of square blocks.  This process would then distribute secondary events.  For example, the process might poll the light to see what state it was in, and then generate “light-is-changing” events.  Those secondary events would also flow into the event-space.

Events that had to feed multiple chains of activity might then be fed into a duplicator, which you could think of as a kind of high-performance publish-and-subscribe or a multicast process.  This new stream of events might intersect with other duplicators or with processes, or both.  The meshing of events with processes is a complex ballet, not only because it will demand a kind of “function routing” that aims an event at the destination process, but because that process might not yet live anywhere in particular, so the process-space will have to instantiate it in what’s effectively the path of an event.  Which, of course, could be influenced by where the process could be put.

Event processing is serverless not because it simplifies cloud billing, but because you can’t have persistent processes managing transitory things.  You can’t have traditional middleware, or traditional programming languages, or much of anything else either.  The challenge of the cloud, and of fog/edge computing in particular, is coping with events, and that’s going to be the priority of the IT industry for many years to come.  The good news is that we’re starting to recognize just how different things have to be, and working to support the differences.  The bad news is that there’s still a lot to do.  When it’s done, we may find many applications beyond IoT changed forever.