[Ygor]

Etcd looks more and more promising as its usage and development activity increases. Anyone using it internally as a standalone part in the system (e.g. not just for k8s or coreos)?

Using e.g. gRPC shows great promise, but systems like ZooKeeper still play nicer in more traditional Java shops, or do they? How hard is it to use etcd from the JVM?

[jzelinskie]

There's a project called zetcd[0] that acts as a translation proxy in front of etcd to let you use the ZooKeeper API. I don't know if it's production ready, but I do know it works and is a pretty cool idea.

[0]: https://github.com/chzchzchz/zetcd

[ideal0227]

It should not be hard. For v2 API, there are several Java bindings (https://github.com/jurmous/etcd4j).

For the gRPC API, it is easy to generate a Java gRPC client based on the defined service. We have plans to make that experience better.

[bogomipz]

Etcd looks more promising?

Zookeeper has been around now for over 5 years with an extremely large install base.

Kafka, Hadoop, Solr, Mesos and Hbase projects that leverage Zookeeper distributed coordination.

Zookeeper has already delivered.

[harlowja]

I would tend to agree, knowing what zookeeper has been doing and actually using zookeeper (and etcd) I can say that the API and the primitives offered by zookeeper are IMHO better (although this multi-version concurrency control model is interesting) and more mature.

It feels like etcd is 'still discovering itself' for lack of better words.

Btw: https://issues.apache.org/jira/browse/ZOOKEEPER-2169 (this is the equivalent of TTLs for zookeeper).

[cbsmith]

Seems pretty easy to use etcd from a JVM, particularly now that it is gRPC based.

[ashwinaj]

I'm not sure if I can disclose our product details, but we're using etcd2 as a consensus algorithm for a data storage cluster.