Configuration management is one of those things where you reap most of the benefit just by doing it, not by doing it with a particular tool.
That said, I prefer Puppet because its abstractions make more sense to me, and are pretty easily extended using Ruby.
Puppet is also trivial to bootstrap (at least on Debian). Unlike other Ruby stacks, I can install it using the package manager and be up and running in no time. With Chef you have to maintain additional services like CouchDB and RabbitMQ.
The real reason not to use ad hoc scripts or a tool you wrote yourself is that things like cfengine, Chef, and Puppet are maintained and used by communities -- your successor(s) will thank you.
> With Chef you have to maintain additional services like CouchDB and RabbitMQ.
And care about a lot of dependencies. Installing chef-server on a fresh ubuntu quantal:
0 upgraded, 444 newly installed, 0 to remove and 58 not upgraded.
Need to get 280 MB of archives.
After this operation, 775 MB of additional disk space will be used.
Of course a lot of that is due to how ubuntu packages java, but still... that's quite a lot of software to care about.
With Chef 11 Server, the CouchDB component is removed for PostgreSQL. RabbitMQ is still there. Opscode provides a single package with everything above libc required to run the server.
A large part of that was an unfortunate side-affect of gecode (a library Chef used for dependency resolution in Chef 10) not having a -nox package, thus pulling in libqt4-dev, which then spirals out of control. The chef-server cookbook used the gecode cookbook which automated installing from source without qt to avoid this if one desired.
> With Chef you have to maintain additional services like CouchDB and RabbitMQ.
You can avoid those dependencies by using Chef Solo instead of Chef Server. In my opinion chef-solo is also a much easier way to learn Chef, so you can get the main concepts down before tackling chef-server.
But yes, Chef's dependencies are staggering. I once tried using an AWS micro instance for a Chef server, and it kept crashing because the system didn't have enough resources.
That said, I prefer Puppet because its abstractions make more sense to me, and are pretty easily extended using Ruby.
Puppet is also trivial to bootstrap (at least on Debian). Unlike other Ruby stacks, I can install it using the package manager and be up and running in no time. With Chef you have to maintain additional services like CouchDB and RabbitMQ.
The real reason not to use ad hoc scripts or a tool you wrote yourself is that things like cfengine, Chef, and Puppet are maintained and used by communities -- your successor(s) will thank you.