[Hawkular-dev] Titan's future at Datastax and Hawkular Inventory

[Lukas Krejci]

Hi all,

today, Jirka and me attended the webinar organized by Datastax where they 
outlined their plans for Titan - our candidate graph database to use for 
inventory storage.

The outcome is IMHO both good and bad.

Datastax is committed to push Titan to 1.0 and port it to Tinkerpop3 API 
(which is due "imminently" and the port is well under way - 
https://github.com/thinkaurelius/titan/tree/titan09). They are also committed 
to be further involved in the design of the Tinkerpop3 API (i.e. the 
equivalent of JDBC for graph databases).

Once Titan 1.0 is out they plan to "let the community take over" and don't 
plan any further work on it.

After that, they're shifting focus on DSE Graph - a proprietary graph database 
that will be integrated into DSE - their proprietary offering expanding on 
Cassandra's capabilities. This is not going to be open source but will support 
the Tinkerpop3 API as its primary interface.

So there are 2 outcomes for us from this IMHO.

First, if we are to stick with a graph database as the storage platform (which 
I think makes sense), we should adopt Tinkerpop. We currently support 
Tinkerpop2 which is radically different from Tinkerpop3 but the contact 
surface between us and their API is quite small (at least at the moment) and 
in an area that actually didn't change that much (the Gremlin graph traversal 
DSL).

Second, given the unique advantage of the shared storage for metrics and 
inventory, we should stick with Titan (perf benchmarks still pending) for now 
and see how it will evolve post 1.0. If it dies slowly and we hit issues that 
we would not be able to solve ourselves, we can choose another database 
implementing Tinkerpop3. At the moment the only other choice is Neo4j, but 
given the involvement of many graphdb companies in the design of the 
Tinkerpop3 API
(http://www.tinkerpop.com/docs/3.0.0.M7/#tinkerpop-contributors), I am quite 
confident that there are going to be more choices in due time.

As a side note, our inventory API is not tied to the Tinkerpop API in any way. 
It's just that the graph API naturally fits for implementing the inventory API 
and in fact, the impl is quite compact. But should we, due to some cataclysmic 
findings, choose to abandon tinkerpop API altogether, then only a fraction of 
the inventory codebase would be affected - the REST API, UI and all the other 
future integration code would be unaffected by that departure.
 
WDYT?

Lukas