currently, I am making myself acquainted with Puppet.
So far I have only started with a very small setup of a puppetmasterd and one single puppetd client on another host.
I have been reading a nice book on Puppet Pulling Strings with Puppet
by James Turnbull, whom I remembered as quite a good author from his earlier work "Pro Nagios 2.0" (also published by Apress; n.b. I am no sales rep. of them and don't get any payments for "advertising" their publications here).
The Puppet book I discovered in a local bookstore for a mere 11 Euros.
Though Puppet is still work in progress and the book a little over a year old
I preferred it over the also good Puppet trac doc
because I find it in general more pleasing to read longer passages from a hardcopy than from screen.
The book is well structured and introduces the most vital elements of setting up and configuring Puppet as well as the "Puppet Language" which is a bit close to the Ruby programming language.
That is because Puppet is written in Ruby, unfortunately to me since I am not yet into it (but can build on my (OO) Perl background).
Puppet requiring Ruby has another little drawback for my environment where I intend to use Puppet because I also have to cater for quite a few commercial Unix systems (like HP-UX, AIX, Solaris) where up until now unfortunately Ruby isn't so common and many of these "distros" lack development tools (their vendors usually charge immense extra license fees for e.g. ANSI C compilers), and they also lack prepackaged binaries for their OSes.
However, if you have to manage mainly Linux/*BSD systems (especially any RedHat-based ones) Puppet seems to be a perfect choice.
Because the setup of a Puppet system to my impression resembles a bit of some OO programming work (e.g. class definitions and the Puppet syntax) it can be a little daunting to admins with little or no coding experience at first.
And I can imagine that it will require a bit of fiddling to get a good configuration management for a big site to work smoothly.
But once you have it running I can also imagine that it not only eases config management for large sites with many hosts but that as a "by-product" of your Puppet configuration
you get a pretty good mapping and "documentation" of involved processes
(similar to as often shell scripts also act as part of a documentation of mundane, repetitive processes exercised by sysadmins).
And not to forget, your configuration changes get more reproducible and accountable.
As you asked, another "tool" that serves a similar purpose is e.g. cfengine
Interestingly, the initiator/creator of Puppet is said to have come from the cfengine project and to have started Puppet because he wasn't satisfied with some of the drawbacks of cfengine.