I am a co-founder of a small SaaS company. We recently decided to make the investment of upgrading our infrastructure setup process from "Hey David go do that" to being 100% chef-based.<p>I managed the process, and consider it a success. However, here are some points I would make:<p>1. It took a long time. Let's be generous and say it took 2-3 man-months of time to set up 4-5 different projects and roles. This was probably 10-20x what it would've taken to set up the servers directly. Why? Learning curve with chef for both our programmer and sysadmin. Figuring out how to make config changes automatable and idempotent.<p>2. The scale you get from chef is bigger than managing production infrastructure. We now use chef for not only production deployment, but also dev. Once paired with Vagrant, we are able to get new devs up with a complete stack in about 10m of keyboard time. If we need to upgrade to some new version of something, only one person has to deal with the sysadmin; everyone else can just update their box.<p>3. I think it will save money in the long-term. A good sysadmin is $100/hr+. Unfortunately you have to pay that rate whether they're doing architecture, security review, or just editing text files. With chef, a non-sysadmin resource can generate recipes with just architectural advice and review from a sysadmin. This is much more efficient, especially for small shops where a sysadmin is an expensive and not immediately available resource.
I agree with the author that Chef is an incredibly powerful tool and that it has numerous benefits over plain old bash. However, I'm reluctant to actually use it because of its dependencies. Chef relies on CouchDB, RabbitMQ, and Solr, and all of those have non-trivial dependencies as well. Then, with a stack like that, I worry about the overheard involved.<p>FWIW, Puppet's dependencies are much simpler. I don't know much about Chef vs Puppet, but I can say that from an installation and dependency maintenance POV, Puppet wins.
I have three fundamental issues with Chef;<p>1. The node object ends up being two large, which leads to memory issues when a search returns more that 200 nodes (800MB of memory).<p>2. Chef discourages declarative configuration.<p>3. Chef lacks a remote trigger mechanism.<p>Issue one starts to kill you once you have a large number of nodes. Dedicating a quater of the available memory to configuration management seem like a poor financial choice. We've come up with work arounds at my company(generate files centrally, and distribute with chef remote_file syntax), but I still feel they are hacky.<p>Issue two is more serious. Reindexing on chef only occurs after a node has submitted its node object back to the chef server. This results in incomplete searches until a node successfully completes a run. If you wish to remove a node from a particular role or attribute from a host, you may have a hard time doing so until the next chef run completes.<p>Problem three is really a result of the expense of running chef. If the memory and CPU costs were lower, there wouldn't be any real issues running Chef more frequently. Some changes I need to go out immediately, some don't matter. I end up back in the world of the SSH loop too often with Chef.
I think this post should be titled Why Configuration Management?, with a subtext of using Chef as an example. The main points the author is making are true of CFEngine, Puppet, Chef, and other config management software. The question of Why Chef? can be answered very simply: because the author likes it. Which is a perfectly valid way to choose your tool chain, assuming the technical requirements are met.
Two reasons I'm wary of Chef wrt Puppet<p>1) the declarative vs imperative aspect<p>2) Chef's heavy dependencies<p>As a Ruby developer, I like Chef's Ruby DSL; but I somehow feel that its imperative DSL will lead to something similar to Bash Hell. I'd like to read more about the declarative properties of Puppet vs the imperative way of Chef, and why one should prefer one over the other.<p>Secondly, like some commenters before mention, Chef's dependencies seem quite excessive.
I've been working with juju <a href="https://juju.ubuntu.com/" rel="nofollow">https://juju.ubuntu.com/</a> (a new Ubuntu server tool) and been very happy with it. It does not directly compete with puppet/chef for enforcing a server configuration however. Juju operates at the higher level of "services" that can be deployed to a cloud, to hardware, or to local LXC containers! It's basically like "apt-get" except for servers. The dev team hangs out at #juju on freenode irc