On Fog Computing

Cisco that advocated the term "Internet of Everything" is now advocating the term "Fog Computing". these terms are related.    According to Cisco the cloud computing model is being replaced by the fog model.   
While in cloud computing all computation is done in a remote computing center, in fog computing the computation is distributed between local processing ("at the edge of the network") and remote processing. The relationship to the sensor world is straightforward.   A site might have multiple sensors. Some of the processing can be processed locally, and some need to be processed in a remote place, furthermore, this may be dynamic and tuned in real-time.   The picture above shows the before (cloud model) and after (fog model).   The example is energy system.  There may be processing done in a processor located in a single house which takes into considerations all sensors installed in the house.  There are other types of processing that related to data from multiple houses and need to be processed in a place where all data is available.  

Note that nothing is really new (besides the names).  Cloud computing is a new name for an old computing model that was once called "service bureau".  In the past the "cloud" was a single mainframe, and the edge where collection of dumb terminals.  Now the cloud is a grid, and the edge has processing power, but the principle is the same.    Fog is also an old principle of distributing the work reminding of N-tier middleware. 

I guess that the fog model is indeed more appropriate for IoT scenario than cloud model, in some of the projects that we are now planning within the Institute of Technological Empowerment,  are indeed fog based.  The sensors are going to be communicating with a local processor (which may be as simple as a tablet) with some processing done on the local processor, and some on the cloud.  This brings us back to the idea of event processing on mobile.   

After cloud and fog, we are waiting also for some - wind, rain, and sleet.... 

StreamInsight as a cloud service

The idea of using event processing in "software as a service" mode is not new;  thanks to Marco's Blog,  I came across an article describing the StreamInsights cloud service.  The rationale behind it is that it should be used in cases that it is more cost-effective to customer relative to purchasing expensive hardware needed for processing large volumes of events.    This is part of the general trend to use the cloud for various purposes.  I assume that this will be one of the main ways that event processing will be consumed in the future. 

On event processing as a service

While working on the Website of the EPIA book, we asked the language owners to provide downloadable version of the product implementing their language. I was asked by some of the language owners if instead they can provide instead a possibility to provide their software as a service and let the readers run it on their servers. My answer was positive, and we'll see couple of such examples (one already there, one is coming up).

The book's website is just a resource for readers who wish to study languages, but this brought me to a thought about event processing as a service in general.

Some of the reasons for doing it is to gain the benefits of cloud computing in terms of scalability,

I've recently came across some material about activeinsights which seems to be a new Israeli company developing open source "event stream processing" in the cloud (well - I have some terminology comments to them, but this is not the main point) that advocate the use of event processing in the cloud to cope with scalability issues. Using SAAS model for event processing can give rise to some interesting cost models, that are either related to the input (amount of input event processed) or the output (amount of situations detected by the event processing service, with some cost per situation, or amount of aggregated/transformed derived events) which ties the cost directly to the benefit. One of the barriers of using event processing as a service is lack of standards especially for interoperability, which does not enable just to connect and run, but requires substantial investment in writing adapters in a proprietary way. I assume that we'll see more of that, when the cost/benefit model will be clarified.

There are more interactions between cloud computing and event processing, such as the use of event processing as part of the cloud infrastructure, but this deserves a separate discussion.