On the history of STORM by Nathan Marz

Nathan Marz, the guy that is behind the Storm Apache incubator project.
Storm has definitely became the most common stream processing platform.  This year I am scheduled to teach a course about business intelligence, and my view of business intelligence includes the real-time business intelligence.  The students will practice Storm. 

Recently Nathan Marz wrote in his Blog about the history of Storm and lessons learned. 
I think it is worth reading... 

StreamEPS from SGT - an open source event processing from Ghana

I was recently approached by a company that resides in Accra, Ghana called SoftGene Technologies,  which  has developed an open source event processing product called StreamEPS.   Looking closely at the description of the supported functionality, one can realize that this is an implementation that follows the EPIA book.  I'll write in a separate posting about the impact of the book in terms of follow-up works, it is quite interesting...

Softgene technologies describe itself as "Research-lead private company".  I like the definition, since I believe that much of the useful software is research lead. 

This also completes the continent coverage of people working in development event processing software.  

While there are quite a lot of software developed in Europe and North America.  There is now event processing software developed in Asia (Sri Lanka, Japan and Israel - that I know of), Australia, and Brazil.

If there are event processing related software developed in additional countries -- let me know and I'll survey in this Blog.

Siddhi - an open source event processing engine from Sri Lanka

According to Wikipedia, Siddhi is translated into: perfection, accomplishment or unusual skill.   In the picture we can see the eight primary Siddhis.    Siddhi is also a name of an open source event processing engine, recently advertised.    From the basic description it is aimed to support event processing as stand alone applications, and experiment with optimization algorithm for the run-time engine.    Siddhi came from University of Moratuwa in Sri Lanka, a university who claims an ambition mission: "to be the most globally recognized knowledge enterprise in Asia".   I like ambitious goals, and probably making open sources like this  can contribute to the recognition, of course, if this will get traction.  


I know of event processing open source and products coming from the USA, UK, Germany, Austria,  Sweden, Israel, Australia,  and I probably miss some (will be happy to update this list)   So now Sri Lanka to the list,   We are starting to see more activities in Asia in recent years, and hope to see more. 

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.