First, some brief tidbits....
Congrats to Terry Cunningham, the former CEO of Coral8. It looks like he is now a Senior VP over at i365, which is a Seagate company. I guess that Terry will be wearing a dual hat, as he is also the Chairman of Aleri. One wonders if Seagate will eventually go into the CEP business :-)
Also, good luck to Mark Tsimelzon. A few people at Coral8 have remarked that Mark is no longer with the combined entity. With Mark's track record, I am sure that he will be involved with something new and interesting.
It looks like Coraleri has chosen Coral8's CCL to be the SQL-based language of choice for developing Coraleri applications. This is the first piece that is falling into place, and for me, it's good news. Now, we have to wait to for the Splash integration to happen, and then the second piece of the puzzle will be solved.
The latest Coral8 5.6.1 has lived up to its claims of major performance enhancements. My CEP team reports that CPU usage is down significantly in our tests on our most complex queries.
With Coral8 making big strides in performance, the case to keep the Aleri CEP engine around is weakening. Don DeLoach is adamant that none of their customers will need to rewrite a single line of code, and that Aleri has even put it in writing. I know that Don believes this with all of his heart, but I am still a bit skeptical. But I am willing to cut them a big piece of slack, as long it does not affect what we are doing with Coral8. We are continuing on as if nothing happened, and I am trusting in Don and the Coraleri team to make the transition completely transparent to us.
Which brings me to my next topic ... Sybase RAP and Coral8.
For this topic, I am putting on the other hat that I wear, which is Chief Architect of Equities. One of the jobs of the Architect is to keep abreast of the current technologies that we use to see if any of them will approach an "end-of-life" situation. Chief Architects needs to make sure that the company does not invest in any technology that might be risky in any way.
Almost every large investment bank has one of every technology. I am not giving away any of our secret sauce when I say that we have a number of applications that use Sybase ASE for the database. So, when Sybase comes knocking on my door, asking me if I am interested in their new CEP product, what do I think?
First, I think it is a bit curious that Sybase did not publicly mention the use of Coral8 as their CEP engine. I can now understand why. I can speculate that Sybase knew of the pending acquisition of Coral8 by Aleri, and wanted to avoid some of the confusion that goes along with a merger like this. If I knew that a company's product was based on another vendor's product, and that other vendor had just gotten acquired by another company, I would need to be absolutely sure that all of the moving parts were going to have a long life, and that we would not be faced with an end-of-life situation. I could imagine more that a few sweaty brows at Sybase when Coral8 said that they were selling to Aleri. I am sure that Sybase did not want this consternation to leak out to their potential customers. So, better not to mention the association between Coral8 and Sybase RAP. If this was the primary reason for the silence, then I can certainly appreciate that.
But, as the Architect, I would also want to know what Sybase's plans are for the future of their Coral8 engine. Sybase bought the source code to Coral8. Does Sybase plan on getting continuous enhancements from Coral8 as the Coral8 engine and language evolves? Does Sybase plan a separate fork of the source code so that, eventually, the Coral8 engine and language and the Sybase RAP engine and language are two different things? Will Sybase RAP eventually incorporate Aleri's Splash language? These are things that are very important to us. We would need to see Sybase's roadmap as well as Coraleri's roadmap.
In a posting on Marco's blog, Era asks some very important questions:
Are there other details on the deal? Is this a one time source code tree fork? Will Sybase get new versions from Aleri? It would be interesting to hear if Sybase they will develop it itself further or if bugfixes, patches and new features will come from Aleri’s developers?
John Morrell from Coraleri responds with the very mysterious:
Sorry, we are not releasing more details on the terms of the deal. Those are business terms between Sybase and Aleri.
That's a bit scary. I can understand the financial terms not being released (although it would be interesting to see if Coraleri gets a piece of every Sybase RAP sale, as that would help with Coraleri's financials). But not giving transparency into Sybase's plans is not good news for Sybase, although it is a positive for Coraleri. I have no transparency into whether Sybase will be upgrading their engine based on the upcoming work of Coraleri, and that does not sit well with me.
Sybase RAP can be used without the CEP portion. However, I do not know what other parts of RAP are dependent on other third-party vendors, and whether these other parts are subject to any risk. And, it looks like it has some overlap with KDB+ and with Vhayu. (I wonder if there is a third-party comparison between the three.)
I will not be recommending Sybase RAP for consideration until some of these underlying questions are answered. The current situation just leaves too many questions unanswered. I would welcome a bit more transparency from Sybase.
©2009 Marc Adler - All Rights Reserved.
All opinions here are personal, and have no relation to my employer.
Subscribe to:
Post Comments (Atom)
9 comments:
About Splash - I used to want to see every vendor include a language like this. But now that I've used Esper a bit and seen what can be done with total Java API integration in the engine, I've completely changed my mind.
Now my vote goes to improved Java/C#/C++ and API integration over something like Splash. It will be very hard or impossible for them to develop a procedural language that can match one of these standard languages when combined with a good API.
SPLASH does have some advantages over languages like Java and C#. Mainly, it's designed to have predictable latency characteristics by not requiring full-blown garbage collection. As much as I understand and admire Java and C#, tuning garbage collection for completely predictable performance has been challenging in the past. Perhaps the state of virtual machines is better now; I'd be happy to hear otherwise.
Jon Riecke, Aleri
Not requiring GC is still a Very Good Thing for consistent performance.
There are ways to mitigate some GC in an interface like this but possibly not all (possibly all, research would be needed).
Here's why I say what I do: SPLASH will have relatively few utility methods or libraries. Most of what people will want to do in SPLASH will need to be written from scratch, with Aleri playing catchup to add library functions here and there. Given that the whole point of the tool is to save programmer time, this scenario sounds bad to me.
But I could be wrong.
I understand the point. Another way forward is to make the foreign function interface (to Java and C/C++ and possibly C#) richer, e.g., make it easy to access functions and objects in the external language. That way, you get predictable performance in SPLASH when you stay in SPLASH, and flexibility when you need it. Another benefit: it doesn't force casual users to go outside the system. And you can put the foreign functions in a module to be reused, so that casual users can use pieces that more sophisticated programmers build.
This is a good discussion.
Jon Riecke, Aleri
Jon,
I am not sure if this is something to be addressed by SPLASH, or whether it can be addressed by letting developers use C#-based UDFs in the Coral8 engine.... but, i would like to know how best to call out to a WCF-based service from a CCL query. As an example, I refer to the paper that was co-authored by Antonio Zurlo of Microsoft and Mike DiStefano of Coraleri in which they were able to call out to a WCF service from CCL in order to do grid-based operations.
I've talked to Mike about his paper, but not in enough detail to answer your good question. It'd be great to hear his thoughts on the subject; and I feel fortunate that I can walk a few feet into his office tomorrow and ask.
Thanks,
Jon Riecke, Aleri
Does anyone get the feeling that this has just become a debate about language syntax? Where is the debate on Coral8 vs Aleri engines, from a technical / database research standpoint? Is this just a debate about what kind of SQL-like syntax we want? Let me give an example. There is some debate here about whether or not SPLASH should be integrated into the Coral8 engine, with some people arguing that good Java/C#/C++ API could be a substitute for SPLASH. But what I want to know is, what are the technical implications of sticking a procedural language into CCL? This is like introducing procedural concepts into a functional language ...it's a pretty serious change and I'm concerned about the lack of any scientifically driven discussion on this. It seems like the marketing people are in the driver's seat and the only concern is how to satisfy
as many competing interests as possible. Part of the problem, I think, is that everyone is very secretive about the scientific foundation of CEP systems. Compare this to the case of relational databases (such as SQL Serve or Oracle), where the scientific foundations were established decades ago and everyone has a very good idea of what goes on inside a relational database engine (how data is stored, how it is queried, etc).
I have to wonder what you (Anonymous) mean by marketing people taking over. This conversation is on a blog by a user (Marc), started by a user (me), with contribution by a researcher (Jon).
I agree that it is not easy to compare the internal architectures of the various streaming SQL engines. There are plenty of research papers for how these languages might work, but little documentation on exactly how they do work, as their is for RDBMSs. So it is not possible to compare technical approaches in the same way as for RDBMSs.
But if you want to look at how adding a procedural language impacts these products, you can download them and try it. They all allow for some kind of procedural language to be embedded or linked in.
And if you want to have a detailed technical discussion, really you should just ask some good questions. Because these vendors have more CS PhD's per square foot than most companies and they will get very detailed, very quickly if you just ask good questions.
At Apama we offer an EPL that is foundationally imperative with declarative constructs to make it easy to declare your event stream patterns (i.e. listeners as we call them). Many of our customers prefer this approach for many reasons not the least of which is that its generally a faster time-to-market building apps. But we also offer java API language bindings. We host a JVM in our CEP engine to enable this. This was driven by customer demand. We've seen customers that love java (so we built the java bindings a few years ago) and customers that hate java (so we have a purposed EPL with all the requisite tooling).
Furthermore, some customers want GUI modeling tools, nice to have those too.
I don't think any one language solution is the be all, end all. To support a broad customer base you'll find all sorts of requirements. It's a bit schizophrenic really.
Luckily with the event paradigm all these approaches can play nicely together.
Louie Lovas, Apama
Post a Comment