zetcd

It's been a few years since I've checked in with distributed lock services. Why would someone adopt ZooKeeper after etcd gained maturity? I recall seeing benchmarks more than 5 years ago where a naive proxy like zetcd[0] out-performs ZooKeeper itself in many ways and offers more consistent latencies. etcd has gotten lots of battle-testing being Kubernetes' datastore, but I can also see how that has shaped its design in a way that might not fit other projects. I think there are plenty of other projects (e.g. FoundationDB, Kafka) that also replaced their usage of ZooKeeper as their systems matured. I guess I'm confused why anyone has been picking up new installations of ZooKeeper. [0]: https://github.com/etcd-io/zetcd

In context of Kafka, hopefully KIP-500 [1] will get implemented sometime soon. If you're feeling lucky, you can also use zetcd [2] to connect ZK apps to etcd. I've been able to actually run Kafka with it as a toy project a little while ago. [1] https://cwiki.apache.org/confluence/display/KAFKA/KIP-500%3A... [2] https://github.com/etcd-io/zetcd

A few reasons we didn't use ZK at the time (some of these are out of date). Zookeeper had: - No TLS security story - An abandoned RPC/serialization system that was hard to use in other languages - A consensus algorithm that differed from systems described in literature - A large RAM footprint Awhile ago some etcd engineers made an experiment in fact to try and run ZK client protocol on etcd with a proxy: https://github.com/etcd-io/zetcd https://coreos.com/blog/introducing-zetcd Today, etcd performs much better than ZK and I believe it is much more widely deployed with a wider set of engaged users. https://coreos.com/blog/performance-of-etcd.html