Category Archives: CEP

What Exactly is Complex Event Processing Today?

Posted on September 18, 2011 by | Leave a comment

As much as I disagree with much of what Curt Monash writes, he did actually ask a good question recently in his post, “Renaming CEP… or not”

Without getting into a rehash of the hash over there, let’s look at things a bit differently.  Let’s talk about what CEP is not.

I left trading to join a firm called NEON.  I was an early investor in this company, my mentor had started the firm, and to me it looked like the cat’s meow.  It was a great time, a lot of people made a ton of money, and I was introduced into the world of software via Enterprise Application Integration (EAI).  Using EAI, one could centralize the business logic associated with plugging different systems into each other, convert the format of one system into another, and pass messages around seamlessly between these applications.  There weren’t a lot of competitors at that time, we were arguable #1 in the space, and the technology became MQ Series Integrator (think Websphere, like I said, we made a lot of money.)

Well, CEP isn’t EAI because there’s no concept of format libraries – sure CEP engines use input/output adapters but sure does every program ever written (I’m waiting for the first salesperson to licence the keyboard/screen adapter set – available in different languages soon!).  We’re going to come back to EAI in a moment.

Throughout my career, the teams I’ve worked with have used a variety of 4th generation languages.  Stuff like Powerbuilder, SQL Windows, Paradox, etc.  Each of those environments had some common elements, screen designers, a domain specific language designed to make bizapp dev faster, and abstractions for common data stores.  Often times, our groups wrote servers that integrated with these front ends via RPC, a streaming connection, or databases.

CEP isn’t a 4th generation bizapp dev environment – there’s no facility for building gui’s.  Although some of the CEP platforms out there do have DSL’s, some also use SQL derivations.  I’ve used the SQL derivations (I’ve worked at two of those co’s) and guess what?  The people in those firms hated using the language themselves.  ”Yes, you could do a covariance matrix with <insert proprietary get-me-sued-for-naming-it-here> but I could do it faster and easier in a different language.

I’ve also used many databases.  But you don’t use CEP to store data – you only process the data in flight.

So, CEP isn’t EAI, it’s not a database, and it’s not an application development environment.  Where, then, did CEP come from?  Let’s look at a couple.

The work out of Berkeley and the work out of Brown, Brandeis and MIT focused on event stream processing.  Here’s a blurb about Berkeley’s Telegraph:

Telegraph is an adaptive data-flow system, which allows individuals and institutions to access, combine, analyze, and otherwise benefit from this data wherever it resides.  As a data-flow system, Telegraph can tap into pooled data stored on the network, and harness streams of live data coming out of networked sensors, software, and smart devices.  In order to operate robustly in this volatile, inter-networked world, Telegraph is adaptive – it uses new data-flow technologies to route unpredictable and bursty data-flows through computing resources on a network, resulting in manageable streams of useful information.

And here’s one about Aurora (Brown, Brandeis, & MIT):

Aurora addresses three broad application types in a single, unique framework:

  1. Real-time monitoring applications continuously monitor the present state of the world and are, thus, interested in the most current data as it arrives from the environment. In these applications, there is little or no need (or time) to store such data.
  2. Archival applications are typically interested in the past. They are primarily concerned with processing large amounts of finite data stored in a time-series repository.
  3. Spanning applications involve both the present and past states of the world, requiring combining and comparing incoming live data and stored historical data. These applications are the most demanding as there is a need to balance real-time requirements with efficient processing of large amounts of disk-resident data.

Hmm.  I’ve worked with both of those packages – no mention of Complex Event Processing in there at all.  So where did that phrase even come from?  Well, that’s the title of David Luckham’s book, “The Power of the Event” in which the good professor describes not so much an implementation, but a set of processes designed to help us all run our businesses and missions more effectively.  In the book though, David references a language that deals with streaming data.  Oh oh….

Around 2005-2006, a couple of firms were struggling trying to describe what Event Stream Processing was and why it was important and more importantly, why you should be spending money on it.  I was the CTO of one of those firms.  We competed mostly against Streambase at the time.  Somewhere during that time frame, the phrase Complex Event Processing was adapted in an effort to differentiate.  At that time, Aleri wasn’t CEP – they were OLAP.  Streambase, formerly Grassy Brook, probably choose that name in homage to Stream Processing.  Kaskad is Swedish for waterfall, or where a bunch of rivers and/or streams collide.  I don’t think Apama ever used the phrase ESP, they were focused on trading from the start.  Starting to get the picture?

So, if CEP isn’t EAI, and it’s not a 4th generation bizapp tool, what is it?  I’ve probably kicked this dead horse enough, but one more time and it’s not going to notice.  CEP needs 4 things to be called CEP (or ESP…):

  1. Domain Specific Language
  2. Continuous Query
  3. Time or Length Windows
  4. Temporal Pattern Matching

These 4 things, in my opinion, don’t make up a separate space, let alone a market.  What they describe is Event Stream Processing.  What they describe are features found in larger, more complete event processing environments from IBM, SAP, TIBCO, and Progress.  And TIBCO, for example, just added the missing features described above to their Business Events Platform, and had instant CEP (sarcasm mine).  Those offerings look a lot like the traditional EAI platforms – or where all of this began roughly 20 years ago.

So, I don’t think what a couple of vendors sell as Complex Event Processing is really CEP at all.  If you want an idea of what CEP is really all about, read David’s book to get started.  Then take a look at Tim Bass’s blog thecepblog.com.

For now, let’s just drop the phrase CEP (because it’s mostly just Stream Processing) because it means so little to so many and fails to impart any meaningful message to the people who actually write checks for this stuff.

Thanks for reading!

→ Leave a comment

Posted in CEP

Building a Back Testing Platform for Algorithmic Trading

Posted on January 16, 2011 by | Leave a comment

On this continuing series, I am examining thoughts and specific implementation details around building a back-testing platform for algo trading.  Eventually, we’ll see where complex event processing plays and how to implement it.

Appendix to Part One – The Data Format

Rather than looking at various database solutions first and then trying to define the problem in terms of those solutions, let’s first examine what market data looks like.  In its most simple form, market data looks like this (there’s usually a little more, but this is fine for our purposes):

  • Date: The date of the market data,
  • Time: When did the quote occur during the date,
  • Sequence #: Most quote or trade streams include a sequence #,
  • Symbol: What security is this data for?
  • Best Bid: The best bid (we’re going to concern ourselves with BBO data for this series, it’s easier),
  • Best Bid Size: How much does someone want to buy at the Best Bid,
  • Best Offer: The best offer,
  • Best Offer Size: How much does someone want to sell at the Best Offer.

Consider this chart:

Market Data


If we break down data, we can successively see how data might be arranged on disk for subsequent reading.  We want to read the data very quickly.  If we were using a standard relational database, it’s easy to see that we might be replicating some unnecessary data during the reads.  And we if use a typical columnar database, we can see that there are chunks that could be read together increasing throughput.

For example, for any given millisecond (Time) in a quote feed, there may be more than one symbol with a quote.  In fact, that’s quite common.  So replicating the time stamp is superfluous.  So if we had a table for a date’s worth of data, then we’d have a Time column that was replicated throughout the table.  No reason to do that.

Looking again at the data, we can see that, for a given time, there might be multiple quotes available for multiple symbols.  We’d like to read those in order as a little group.  By organizing the data on disk as a flattened multi-dimensional map of maps, we would:

  1. Start with a given day (our table),
  2. Start with a time (our row),
  3. Read each quote in sequence # order (our column)
  4. Process (do something)
  5. Increment the time, and go to #2 above until we run out of data (lather, rise, repeat)
  6. Put the $ in the bank

If we could write this data structure to disk as we get it from the quote feed, and had fast enough disk, we could keep up with the feed.  If we needed to create some indexes on the data, we could easily do that as well.  We’d simply create another table that would hold an inverted list of time and sequence #’s by symbol.  If we want to process a day’s worth of data, we’re all set.  If we want to process a symbol, or group of symbols, we’re all set.

So, to summarize, we need a hybrid approach.  In some places, we want rows of data – storing columns of data via a unique key.  In our case, that’s the Time column above for a given day.  The row above is Time, the column (or Super Column) is the Quote for a Symbol.  The Super Column’s key is the Sequence #.  Can anyone guess which database might fit nicely for this use case?

In my next post, I’ll describe a formalized data structure and it’s implementation.  I might even include a little code for all you #NoSQL guys and gals out there.

Thanks for reading!

→ Leave a comment

Posted in Algo Trading, Capital Markets, CEP, NoSQL

Tagged

Building a Back Testing Platform for Algorithmic Trading

Posted on January 14, 2011 by | 3 Comments

In this series, I’m going to outline in general, how to build a back-testing platform for the creation, tweaking, and subsequent execution of algorithms used in electronic trading.

Part One – The Data

I recently made some comments on Vertica’s blog in regards to what I considered to be a fairly bold claim.  They said that Vertica was the only real column store.  But even if they are, so what? In my comments, I alluded to my belief that we optimize problems to solutions – we try to fix stuff using what we’ve got in our toolbox without having to run to Home Depot.

The real test is when the rubber hits the road – how do you actually solve a problem in a new way that’s motivating.  And by motivating I mean the solution addresses the issues, enables new capabilities, and is economically attractive.

So rather than tell you that DarkStar and our approach to processing both real-time and historical data (there’s a difference?) is the Real Enchilada, I thought I would illustrate a real world use case.

Let’s say you want to store a bunch of market data.  And I mean a bunch.  You want to store every piece of market data for the whole US Equities market.

And you’d like to have this data so that you can run analytics on it.  Or maybe even back-test strategies for buying and selling stocks.  So let’s assume that you’ve got some java code lying around to do that.

For our example, we are interested in seeing whether or not using volume average weighted price strategies actually work.   In our example, we will pretend that we are buying a lot of stock, and the theory we want test is whether or not buying that stock during the day when it’s lower than it’s weighted average price will give us a better average price during the day than just going with the flow (often referred to as volume participation).

We are all familiar with how relational databases work, and anyone who’s been in capital markets for a while knows how futile it would be to use something like Oracle for this due to cost, hardware and just how difficult it is to get the data into the database in the first place,

Oh that’s right, I forgot to tell you, we are going to have to load this data first.

I am not going to go into the relevant benefits of a column store here either, you can check out many other websites for that.

Instead, let’s look at some issues.  First, I would rather load the data directly into the database as it happens.  Staging the data separately is costly and error prone. In addition, what happens when you decide to load that data and encounter a problem that can’t be fixed in time for the next market day?  What if you actually run out of space or compute to get caught up?  Well then you can’t back test the next day to further refine your algorithms.  Algo’s should be tweaked every day.  New algo’s need to be developed to remain competitive.  So here, a database error costs real money.

So I need a fast data store.

As I am loading the data, what happens if one of my disks goes boom? Or one of my machines go boom? Well, now I have a problem.  If I fail over to another datacenter, how do i reconcile? What a nightmare!

So I need a data store that we can take a sledgehammer to and it will keep running.

Hey, if I have this big historical data store, I still need to query it while it is being updated.  Ideally, I would like to also be running analysis and back testing during the day.  Scheduling jobs to run at night is so very ’90′s.

So my data store has to facilitate both interactive query and batch analysis.

But wait, doing all of this means that I am going to have to figure out how to use the same code for back-testing that i use to generate orders during market hours.  It’s either that or use some visual, script based or different harnesses for my java or C++ code.  Yet another nightmare.

So, I would Iike to run the same code against my historical data store that I also use to generate orders during the day.

There’s a bunch of other stuff too, management, instrumentation, removing old data that I don’t need for back-testing, all the stuff we associate with normal day to day big data operations. We need to know what’s going on during the day so that we can be proactive.  There’s gold in that data!

And one last thing, it would be really cool if most of this technology wasn’t proprietary.  I mean let’s face it, firms that talk more about their investors on their websites than their clients can’t possibly have my best interests at heart.

This is a tall list.  Let’s knock it down, one by one.

Here is a diagram for your consideration.

The diagram isn’t very technical, and that’s on purpose – I’m outlining an algorithm, or methodology that may or may not solve our problem.

In the diagram, I’ve depicted the database as a cluster of machines.  Instead of using one big machine backed by a SAN, I’m going to use a number of machines.  Each of those machines is going to connect to the Market Data source and get data.

As we receive the data, we’re going to take a peek at it, and determine where in the cluster that data needs to live and while we’re doing that, we’re going to right it to disk.  A background process will make sure that the data ends up on the node we want it on.  More of why that’s so incredibly important in Part Two – Analyzing the Data in this series.

Also, I’m going to ask the cluster to replicate everything we’re writing to it – we’re going to end up writing the data a total of 2 times in this example.  I might usually suggest 3, but we’ve got two data centers running the same solution, so I’ll actually have 4 copies of the data.

Why write the data to three nodes in the cluster?  First, if a node goes down, I still want to be able to write data.  If the node that goes down is the primary node, I’m going to remember that and when that node comes back up, I’m going to write all the data to it as part of its “Welcome Back to the Cluster Party!”  And second, if I’m reading data from the cluster (remember, we’ve got algo’s running and users querying this data), I want my data.  If a node goes down, your users don’t really care – they just want their data.  By replicating the data across multiple nodes, I achieve high availability without having to fail-over to another instance or data center.

Ok, we’ve got the Sledge Hammer test handled, which is cool, but everything I’ve described above sounds like it’s going to take a lot of time and that the system is going to very slow.

Not true.  Each node in the cluster above is subscribing to market data.  So if one machine can ingest X messages per second, then a cluster of 10 machines should be able to ingest 10 * X messages per second, right?  Let see what that means in a real world example:

On May 20, 2010, there were about 1.1 billion BBO messages as published via SuperFeed (NYSE’s market data platform), those quotes represent the best bid, bid size, offer, and offer size for each stock at any given time.  In terms of messages per second, that’s about 50,000.  In terms of size per second, that’s about 4,500k per second.  Hmmm, chunky!

These are intimidating numbers.  But if we divide the problem up a bit, and use 10 nodes in a cluster, each node only needs to ingest about 450k per second across 5,000 messages.  All of a sudden, we’re dealing with something quite reasonable.

So, now we’ve got a cluster that can load the entire market real time and it’s redundant.  What about analyzing the data?  That’s in Part Two – Analyzing the Data which I’ll post next week.

→ 3 Comments

Posted in Algo Trading, CEP

What's Wrong With Complex Event Processing?

Posted on November 20, 2010 by | 6 Comments

I spend a significant amount of my time keeping up with advances in processing high velocity big data.  Over the last year, I’ve watched the NoSQL camp grow a lot.  And now, some folks are even forecasting a market approaching $2 Billion USD by 2015. The last time I saw that kind of trajectory for a new software category was for Complex Event Processing.  So without casting any undue aspersion on the NoSQL camp, let’s talk about why CEP has so dramatically failed to generate the returns venture capital firms were so sure they were going to achieve.

WHAT IS EVENT PROCESSING?

Event Processing, or Event Driven Architectures, means nothing more than processing an event one event at a time; preferably sometime shortly after they occur.  The opposite of this is Batch Processing, which means batching events, or messages, or what most of the world would call a row, of data and processing them together.  In batches.  Sounds simple enough, right?  All of you reading this blog post have used an Event Driven Architecture.  In fact, you’re using one now – it’s in your browser.  Can you imagine what the user experience would be if your browser ‘batched’ up all of your mouse clicks and submitted them every 30 seconds?  Event Driven Architectures promise the same type of agility and increased user experience for line of business and consumer applications that you’re experiecing right now.  In fact, it’s probably hard to think about using the web in batch mode – it just doesn’t make sense.

WHAT IS COMPLEX EVENT PROCESSING?

For the most part, a marketing phrase.  That’s right – and again, for the most part, it’s completely meaningless.  As an early and continuing contributor to this particular area of technology, I remember when StreamBase, Apama, myself, and others called this field Event Stream Processing.  Then one of those firms marketing departments decided to differentiate.  I’ll leave the specific firm to your intuition.   So, what is Event Stream Processing?  That’s much easier to answer.  Event Stream Processing is Event Processing with four additional key components:

1. Continuous Query

Rather than having to poll a server for an event, using ESP , the user of the system issues a query and is subsequently informed with events, aggregations, or patterns that satisfy the specifics of the query.  This happens continuously, until you stop the query.

2. Windows (Time and/or Length)

Using ESP, the user can ask, as an example, for an average value of some key over either a time or length window.  Something like, ‘Give me the average amount of time people have spent on the homepage in the last 10 minutes.’  This query would provide an updated average either continuously, or perhaps at regular intervals.

3. Pattern Matching

With Pattern Matching, I’m able to define a series of events that fit a pattern, and then be notifified when that pattern is observed.  Usually within some Time or Length Window.  So, I might ask, “How many users are going from the “Home Page” to the “About Company Page” and then clicking on “My Profile” during a rolling 10 minute window”.”

4. A Language

Tying all of the above together in a neat little language is a cool idea – it makes using these features easier. At least, that’s the theory.  And this is one place where CEP has gone wrong and is not the general computing revolution that myself and others have hoped for.  I’ll expound upon this after a brief distraction in the next 2 paragraphs.  Please bear with me.

WHERE IS COMPLEX EVENT PROCESSING USED?

Even Mark Palmer, who is usually extremely bullish about CEP and probably sprinkles it on his breakfast cereal, has recently admitted the CEP is only hot in Capital Markets.  While I might disagree a bit with Mark, which is nothing new, I think we can all agree that CEP, at the $200M total market size is far less than we had all hoped for.  Frankly, it reminds me of the FIX engine vendor battles – I was an early provider there too – and we all ended up fighting over an ever shrinking market place.

WHAT IS THAT MARKET ANYWAY?

The current vendor set of CEP tends to focus on Capital Markets.  But not really.  It focuses on an even smaller slice of Capital Markets called High Frequency Trading.   Seems more people know more about High Frequency Trading today than CEP. The important thing here is the what all the smart analysts are calling the “CEP Market” really isn’t the “CEP Market” at all.  It’s the HFT software market.  And again, looking at the impressively long list of clients that Mr. Palmer has cited in his recent blog post, many of those firms aren’t actually using CEP for HFT, but an even smaller subset of functionality.  That’s why the market is so small – if any VC firm thought the total addressable market for this technology was going to be $200M in 2010, no CEP startup would have received funding.  And when HFT finds the Next Big Thing, the CEP market, as defined today, will evaporate.  And along with it, any CEP vendor who has concentrated solely upon that market.

SO WHAT HAPPENED?

The idea was that we were ushering in a New Way To Compute Things.  Like all technologists who spend way too much time thinking about this stuff, we thought everyone would immediately see how smart we were, run out and buy one of the CEP based products, and join is in revolutionizing how data is turned into information and used by business folk to make money and pay our salaries.  The only problem is, we forgot 2 things; 1) who would be using our software to do this work, and 2) who would subsequently be using the applications developed by 1.

DEVELOPERS – A FINICKY BREED

I used to be a Real Developer – I wrote in C++.  Then Sun decided that the Internet was the Computer and we all started to learn Java.  Java is cool – Java makes it easy for anyone to write bad code whereas C++ really took some effort to mess things up.  More and more people started using Java for everything; servers, clients, web stuff, etc.  And now, I’m not sure what people use anymore – perhaps coders are using NoJava for all of their no shiny NoSQL apps.  I still use Java.  And I’m loathe to learn another language.  See #4 above in ‘What’s CEP?”  I don’t want to learn another language.  And I certainly don’t want to move all of my work; servers, clients, webapps, etc. to a new and unproven language.  And no matter which vendor you don’t choose for your CEP application because you write it all yourself anyway, none of their languages can claim to be broadly or generally adopted.  Proof?  Try to buy a book on one of them.  There are umpteen books out on NoSQL in less time than it took some CEP vendors to go out of business.  CEP vendors have failed to appeal to core IT departments.  Period.  And core IT departments are the folks who have to assemble all the crap they buy from vendors into something that business users get to complain about when it doesn’t work.

BUSINESS USERS – “SHOW ME SOMETHING!”

Business users want to see information.  They want to see information presented crisply; ready for decision making.  And today, more than ever, they want to see it on their web browser, iPad, iPhone, Droid, Apple TV, disconnected lap top, on flat panels on the front of their refrigerator in the kitchen and on the heads up display in their car while commuting to work.  In short, they want information any time they want information so that they can function in what has become, and will continue to become, an ever faster and more connected world.  Even Progress Apama, who I think is doing really well, uses Flash based instrumentation.  No iPad for you!  There is no CEP environment that let’s the IT folks build a complete application for the business user.  So the business user never ‘SEE’S” CEP.  So they’re not impressed.  They don’t get it.  And they don’t provide budget for stuff they don’t get.

AND IN CONCLUSION

CEP has failed to achieve the multi-billion dollar market forecasts that we all went out and raised money based upon because most vendors have failed to provide the education and tools necessary to create the complete user experience.  Most of the CEP vendors don’t even have their own visualization products – they partner with other vendors to provide things like Tree Maps or Dash Boards.  How they expect to revolutionize the world by outsourcing their interaction with the Business User is beyond me.

THE LESSON?

If the NoSQL camp would like to come anywhere close to realizing the crack smoking analysts’ estimates of a $2B market, they should 1) make the technology readily accessible to the IT department (which they’re doing) and 2) make sure that the business users knows why it’s making a difference.  If they can reach out and touch the business user, or consumer, all the better.

AND THANKS FOR READING

→ 6 Comments

Posted in CEP, Opinion

Complex Event Processing in the Cloud

Posted on February 10, 2010 by | Leave a comment

I’ve spent the last couple of days, after absorbing the Sybase acquisition of Aleri’s assets, looking at the various CEP players websites for evidence of cloud (grid name du jour) deployment.

I haven’t found anything worth mentioning.  That’s not to say that I might have missed something.  But my guess is that with all the economic woes lately, that the CEP vendors have either chosen to ignore or just simply aren’t aware that the rest of the world is actually solving real problems with cloud deployments.

Which is interesting.

It’s interesting because one of the pioneers in CEP & database space, Mike Stonebreaker (love that name), has gone on to work in stealth mode (it says stealth on their web site anyway) over at VoltDB. VoltDB is based upon work done on HStore and would appear, on the surface anyway, to incorporate all of the things we’d expect in an OTP environment without all the traditional definitions of an OTP environment.  The database is dead, long live the database.

This is even more interesting.

It’s even more interesting because this approach would seem to indicate a combined database, CEP, lots of cheap hardware type-o-solution.  Kind of sounds like a cloud, doesn’t it?  (this is an extreme simplification, but for our purposes here doesn’t really matter)

So if Stonebreaker is already working on this, why haven’t any of the other CEP or column store vendors announced any intentions in this area?

Perhaps it’s because that the current incarnation of CEP products don’t lend themselves well to grid deployments.  None of the current crop of products include a message bus or cache, something that’s necessary for grid deployment.  And because this crucial component is missing, chances are that the products were never really architected for the “I don’t care where a message is coming from and I don’t care where it’s going” kind of world.  The kind of world we are increasingly living in.  The kind of world that readily lends itself to cloud computing.

Or maybe it’s because the current set of offerings doesn’t include any meaningful management or monitoring solutions.  Solutions that abstract the physical deployment in order of operational or business areas and allow the business to be monitored proactively.

Or maybe it’s because there’s no easy way to push new CEP based services out to the cloud in a non-invasive way – without actually having to stop services.

Or maybe it’s some other reason or reasons that I’m not aware of.

Or maybe I’m wrong and there’s lots of grid/cloud based CEP deployments out there and they’re not telling anyone what they’re up to.

→ Leave a comment

Posted in CEP, Cloud, Opinion

CEP in the Cloud

Posted on February 10, 2010 by | 14 Comments

I’ve spent the last couple of days, after absorbing the Sybase acquisition of Aleri’s assets, looking at the various CEP players websites for evidence of cloud (grid name du jour) deployment.

I haven’t found anything worth mentioning.  That’s not to say that I might have missed something.  But my guess is that with all the economic woes lately, that the CEP vendors have either chosen to ignore or just simply aren’t aware that the rest of the world is actually solving real problems with cloud deployments.

Which is interesting.

It’s interesting because one of the pioneers in CEP & database space, Mike Stonebreaker (love that name), has gone on to work in stealth mode (it says stealth on their web site anyway) over at VoltDB. VoltDB is based upon work done on HStore and would appear, on the surface anyway, to incorporate all of the things we’d expect in an OTP environment without all the traditional definitions of an OTP environment.  The database is dead, long live the database.

This is even more interesting.

It’s even more interesting because this approach would seem to indicate a combined database, CEP, lots of cheap hardware type-o-solution.  Kind of sounds like a cloud, doesn’t it?  (this is an extreme simplification, but for our purposes here doesn’t really matter)

So if Stonebreaker is already working on this, why haven’t any of the other CEP or column store vendors announced any intentions in this area?

Perhaps it’s because that the current incarnation of CEP products don’t lend themselves well to grid deployments.  None of the current crop of products include a message bus or cache, something that’s necessary for grid deployment.  And because this crucial component is missing, chances are that the products were never really architected for the “I don’t care where a message is coming from and I don’t care where it’s going” kind of world.  The kind of world we are increasingly living in.  The kind of world that readily lends itself to cloud computing.

Or maybe it’s because the current set of offerings doesn’t include any meaningful management or monitoring solutions.  Solutions that abstract the physical deployment in order of operational or business areas and allow the business to be monitored proactively.

Or maybe it’s because there’s no easy way to push new CEP based services out to the cloud in a non-invasive way – without actually having to stop services.

Or maybe it’s some other reason or reasons that I’m not aware of.

Or maybe I’m wrong and there’s lots of grid/cloud based CEP deployments out there and they’re not telling anyone what they’re up to.

→ 14 Comments

Posted in CEP, Cloud