What is etcd?
Don't write about something without defining what it is for those not familiar with it (or you, or your service(s)).
Etcd – The Road to 1.0
21–27 of 27 posts
Re: Etcd – The Road to 1.0
#22Whats the communities opinion on Serf? How does it measure up against Etcd?
While similar, Serf and Etcd solve a different problem. Etcd is strong consistent (all nodes will see the same data, however a partition may cause the system to not accept writes) while Serf is eventually consistent (all nodes are not guaranteed to see the same data, however the system will always accept writes)
So somethings like a distributed lock is impossible to implement with Serf.
Re: Etcd – The Road to 1.0
#23What is etcd? Don't write about something without defining what it is for those not familiar with it (or you, or your service(s)).
Config data accessible via HTTP instead of files.
Although its not limited to config data necessarily.
I suggest reading http://sysadvent.blogspot.com/2013/12/day-20-distributed-con...
Re: Etcd – The Road to 1.0
#24Earlier quoted context omitted.
Probably the fact that you get a single binary (unlike interpreted languages), and that it isn't a mix of Go and C meaning I worries about c libraries.
Just to note, zookeeper is written in Java.
Yes, I'm aware. I was just answering the question, not to compare it to anything else.
Still, Java still requires another dependency..the JVM. Go binaries require...well nothing.
Re: Etcd – The Road to 1.0
#25Is there any benefit to using coreOS when you don't need a million machines? How much work is it to start with, for example, if you have no idea what your scaling needs will be in the future?
"Recoverable system upgrades" - https://coreos.com/blog/recoverable-system-upgrades/
Run from root partition A and only update on partition B, essentially via chroot. Downtime required for updates is the cost of a reboot. If, however, upon an error during boot, reboot into other partition which will be your last known good config.
Seems simple and straight-forward but is difficult for unmodified Debian-based distributions, so they've addressed this as a key feature of CoreOS.
Re: Etcd – The Road to 1.0
#26Earlier quoted context omitted.
No offense, I just don't get it: Why is 1) a feature for you? Everything else on the list kinda makes sense (I understand that this describes something I'd call a feature), but 'written from scratch' or 'in Go'? Can you explain what excites you about that?
I listed what I like. "Excites" is your word. I guess what I meant by "from scratch" is that they aren't burdened by legacy code, and aren't limited to using the Paxos algorithm. If you look at Deis, for example, it basically outsources a lot of node management to Chef Server, which in my view creates a great deal of technical debt on day one.
You read negative connotations into 'excites'. That wasn't intended.
I was just curious, since 'from scratch' can just as well mean 'untested' although I certainly agree that it sometimes is the Right Thing. The reference to Go was another thing that threw me off, since I rarely (admittedly .. sometimes) judge software projects by the language it is written in.
Thank you for the answer and some more references.
Re: Etcd – The Road to 1.0
#27Whats the communities opinion on Serf? How does it measure up against Etcd?
While similar, Serf and Etcd solve a different problem. Etcd is strong consistent (all nodes will see the same data, however a partition may cause the system to not accept writes) while Serf is eventually consistent (all nodes are not guaranteed to see the same data, however the system will always accept writes) So somethings like a distributed lock is impossible to implement with Serf.
Very interesting, wasn't aware that ETCD is strongly consistent. This makes alot of sense in terms of Brewster's theorem. Thanks for clarifying!