I’ve been getting a lot of email, and there have been some posts on this blog, regarding CEP based services in the cloud. So as we go down this road, I thought it would behoove us to examine what a cloud is and isn’t and what a grid is and isn’t.
I found this introductory article from IBM. It’s a good start. I’ll be looking for some more articles – if you’ve got anything you’d like to add to this conversation, please feel free to contact me or add your comments below.
Personally, my experience with grid comes from Capital Markets and calculating prices & greeks for derivatives. I think that some of the people reading this blog might be mistaking what I’m talking about when I say, “Current CEP products don’t seem to be a good fit in the cloud.” I think that those people with Capital Market’s experience think grid when I say cloud, and think about distributing mathematical problems across the grid. Some problems fit grid, and some don’t. But cloud, as I define it, and as defined in the link above, isn’t grid.
For example, I’m not going to deploy a high-throughput, low-latency algorithmic trading solution in the cloud. But that is something I might do internally on a grid. I might use the grid in this case to compute values used as inputs, or base information, into algo’s that generate trading signals. I wouldn’t be deploying that in the cloud – which by IBM’s definition above involves the internet.
However, I might deploy the ability to do some data mining using all equity market data for a day, a week, a month or longer as SaaS in the cloud. But I wouldn’t deploy that on a grid.
Is that cloudy enough for you?