What does HackerNews think of zetcd?

Serve the Apache Zookeeper API but back it with an etcd cluster

Language: Go

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