Yeah, that's a good reference, thanks for starting the thread. @phunt I see a lot of systems trying to implement the API of others in the same space hoping that they can make the migration easier. I feel that it isn't so much about us being a de facto standard, but more about the widespread use. Another point is that some applications have decided that they like etcd/Consul better, and they still need to have that pesky zookeeper because of some other dependency, e.g., Kafka.
@jordan I'm really interested in your observation about the Consul herding. Could you elaborate on the herding argument? Perhaps we should write a post about it... -Flavio > On 20 May 2017, at 18:44, Jordan Zimmerman <[email protected]> wrote: > > I think they're trying to displace ZK for places that use things like Kafka > too. They can make the argument that you can install Hashicorp everything and > get rid of having to manage anything else. That said, both etcd and consul > are more k/v stores than they are distributed coordinators. I was playing > around with Consul this past week and it's locking recipes are far inferior > to ZooKeeper, for example (it suffers serious herding when contending for a > new lock holder). > > -Jordan > >> On May 20, 2017, at 6:40 PM, Patrick Hunt <[email protected]> wrote: >> >> I saw that a few days ago, seems like it could be a real boon for folks >> running in K8s (for example). The long term stability of our APIs really >> reduce the pain of implementing something like this. Does Hashicorp have >> something like this yet? >> >> If I knew ten years ago that we would become the standard I would have >> pushed harder to fix some of the rough(er) edges. ;-) >> >> Patrick >> >> On Fri, May 19, 2017 at 10:34 PM, Jordan Zimmerman < >> [email protected]> wrote: >> >>> "The zetcd proxy sits in front of an etcd cluster and serves an emulated >>> ZooKeeper client port, letting unmodified ZooKeeper applications run on top >>> of etcd." >>> >>> https://coreos.com/blog/introducing-zetcd >
