Once you get to a certain number of servers (virtual, physical, or cloud), you need some manner of centrally managing the machines. Something that will let you install packages and configure them all in some standard way, so you don’t have repeat these steps a hundred times yourself. In my experience, the pay off was less during the initial setup phase (because you’re generally only setting up 1 or 2 machines at a time) and more in the “we need to change something that affects all the machine” phase. Regardless of what phase, Puppet does a great job of helping you out. The last company I worked for did not have much in the way of central management so I started to learn Puppet and deployed it.
I’ve started to take some of my more generic puppet scripts and have been publishing them to my Puppet repo on GitHub. In fact, I’m publishing the entire thing as a semi-functional Puppet setup — not just individual files. As I state in the README, the scripts are, by design, a bit simplistic. I found a lot of Puppet scripts out on the internet that were amazingly full featured. Those “complete” scripts are very useful if you want to plug in some new feature to your existing Puppet and not need to think about it. The main problem I had with these scripts was that their feature rich nature made them very complex.
If you’re learning how to program, you don’t jump directly to making Microsoft Word. You start with “Hello, World” and move up from there. I took this same approach with Puppet. Using base.pp as an example: it has tasks broken down into very simple commands. There are much shorter/faster/efficient ways of doing what I do, but they tend to make the learning curve more difficult. Even with the simplicity, the scripts work. I don’t advise using them directly out of the box (DISCLAIMER:if you do and blow up a server — it’s not my fault) though. Learn with them, steal bits that are useful (Licensed Public Domain/CC0) and Puppet away!
Once I got over the initial learning phase of Puppet, I found that it really is a fantastic tool. I’m not sure when I’ll have a chance to run as many servers as I did previously, but when I do — I hope there is a puppet setup. Add the scripts to Git and you’ve got yourself a running history of how the servers are setup now, how they were setup before and WHY things changed (at least if you use commit messages properly).