Hey I recently developed a service devoted to nothing but storing configuration files! It seems like I'm kind of in the same space (barely), I'd appreciate some feedback:
ZooKeeper vs. Doozer vs. Etcd
51–60 of 91 posts
Re: ZooKeeper vs. Doozer vs. Etcd
#52The story of Doozer is a classic example of how not to steward an open source project. It was released by two Heroku engineers who promptly completely abandoned it. By completely I mean did not respond to any communication whatsoever for a year or so, despite a very active community that had sprung up around the project in terms of users and forks. I don't begrudge them their lives (or whatever drew them away), but t…
Not officially a Heroku project AFAIK, but Induction is essentially the same story: https://github.com/Induction/Induction
Open source polyglot database viewer built by Heroku guys, released with a lot of hype, and then radio silence.
Re: ZooKeeper vs. Doozer vs. Etcd
#53Earlier quoted context omitted.
Even though Zookeeper is "mature" it is definitely a beast to fine tune and wade through. Zookeeper definitely does not bring along a ton of dependencies. If you're deploying it as documented it should be running on its own dedicated machines. I don't see why dependencies are a problem there especially with Chef/Puppet nowadays.
Exactly. A "devops" company shouldn't really be complaining about dependencies anyways, they're a fact of life. I admit my experience with ZK has been 50% administering it with Cloudera Manager, which basically abstracts away all the nastiness. I'm curious about specific issues people have had though; I've used ZK with Hadoop and Kafka without any major issues.
Especially when the standard way to deploy it is likely to unarchive a tar and use the JARs needed directly from the project's lib folder rather than a system-wide/package-manager installed JAR.
Re: ZooKeeper vs. Doozer vs. Etcd
#54I chose Zookeeper to achieve this same goal a while ago (before I heard of etcd). I have been pleasantly surprised at how useful having a coordination service is in my infrastructure in addition to a configuration management service. Because of this, even though etcd looks like it serves distributed configuration management better (aka simpler), I'm happy with my choice of Zookeeper.
Two examples of how a coordination service has been useful:
* cluster wide throttles to help protect overwhelmable backends
* redundancy in maintenance cronjobs that really only want to be run once per cluster per time period
(edited for formatting)
Re: ZooKeeper vs. Doozer vs. Etcd
#55DIY is the pink elephant in the room.
Every company in the world that isn't specifically a software-oriented tech company uses some form of DIY model. Actually, strike that, even they use a DIY model. These tools are the proof!
Look at the origins for every modern open source management framework or tool, and it was just a DIY tool that some startup-turned-huge-company developed out of their own needs, then cleaned up a lot and released to the world. Your needs may not match those of the company who developed the tool, so it may not work for you. But I guarantee you that no tool will work for every situation.
Pick the tool that best fits your needs and then fork it and maintain it internally. You'll be doing it anyway. (Unless you don't hire software developers, in which case you'll want to pay for a real product with a support contract) Once you've done that, stop writing naval-gazing blog posts about your infrastructure that won't apply to 99% of us.
Re: ZooKeeper vs. Doozer vs. Etcd
#56This article is really bad. The arguments against ZK are completely subjective. The pros for Doozer are "it works" which is hardly an evaluation. The features in the pros for etcd are all present in ZK.
Re: ZooKeeper vs. Doozer vs. Etcd
#57Earlier quoted context omitted.
I'm also in the club of people building one of these things (mine is on top of LevelDB and written in ANSI C with a lock-free design). My most recent blog post is on getting the thing to bootstrap: http://www.bringhurst.org/2013/09/09/consensus-quorum-bootst...
Ours is on top of LevelDB too but "lock free" in Haskell using the STM.
Is this open source?
Re: ZooKeeper vs. Doozer vs. Etcd
#58`and is pretty fragmented (150 forks…)'; I don't think they understand how GitHub works... (forks here does not equal `forks' of a project in the traditional sense)
Re: ZooKeeper vs. Doozer vs. Etcd
#59`and is pretty fragmented (150 forks…)'; I don't think they understand how GitHub works... (forks here does not equal `forks' of a project in the traditional sense)
But in this case I think they're correct. If the project is abandoned and forks don't ever get merged back in, development is fragmented and you end up having to pick and choose commits from various forks.
Re: ZooKeeper vs. Doozer vs. Etcd
#60I kind of can't believe they used the Apache Foundation as a negative bullet point for Zookeeper. Come on, just say you felt like writing your own thing.
They're not the only ones that have gotten a negative impression of the Apache Foundation. Other than the web server, the Apache Foundation seems to largely be a burial ground for open sourced corporate Java projects.
It may very well be they don't deserve that, but if so they really need to improve their pr.