4 ms·

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

by Ygor 10y ago

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?

ideal0227 10y ago
It should not be hard. For v2 API, there are several Java bindings (https://github.com/jurmous/etcd4j 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.
jzelinskie 10y ago
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 https://github.com/chzchzchz/zetcd
cbsmith 10y ago
Seems pretty easy to use etcd from a JVM, particularly now that it is gRPC based.
bogomipz 10y ago
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 10y ago
  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 https://issues.apache.org/jira/browse/ZOOKEEPER-2169 (this is the equivalent of TTLs for zookeeper).
ashwinaj 10y ago
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.

by Ygor 10y ago

ideal0227 10y ago

It should not be hard. For v2 API, there are several Java bindings (https://github.com/jurmous/etcd4j 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.

jzelinskie 10y ago

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 https://github.com/chzchzchz/zetcd

cbsmith 10y ago

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

bogomipz 10y ago

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 10y ago
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 https://issues.apache.org/jira/browse/ZOOKEEPER-2169 (this is the equivalent of TTLs for zookeeper).

ashwinaj 10y ago

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.