3 comments

[ 0.58 ms ] story [ 20.5 ms ] thread
I particularly like the custom event triggers in this and how it's only trying to be a simple clustered gossip layer that other services can be built on-top of. That's my primary complaint with etcd is that it's both attempting to be a clustered gossip layer and a built in memory database (not necessarily bad, I'm sure it's a natural part of maintaining state anyways but I feel like the in memory db part could be split off). Please correct me if I'm conflating these two, I've only had a cursory glance at both (ie, I haven't actually used either).
You're conflating their target functions. etcd is all about configuration distribution. Serf seems more like its about member discovery. So you might have a service you run in multiple clusters. Each cluster has a different configuration (etcd), and each instance in a cluster needs to know about the others in the same cluster because they talk to each other (Serf). You could make etcd handle all this, but it probably wouldn't do it as well (Serf has heart beats and recognizes dead nodes, etcd won't do that except for etcd nodes themselves).
Based on looking at the docs it seems serf and etcd are both trying to solve service discovery but are attacking it using slightly different approaches. Which is pretty cool!

Serf looks to be eventually consistent and event driven. So you can figure out who is up and send events to members. This gives you a lot of utility for the use cases of propagating information to DNS, load balancers, etc.

But, you couldn't use serf for something like master election or locks and would need etcd or Zookeeper for that. Serf and etcd aren't mutually exclusive systems in any sense just solving different problems in different ways.

They have a nice write-up on the page here: http://www.serfdom.io/intro/vs-zookeeper.html