Definition: Puppet -- a configuration management and IT automation tool that lets administrators easily automate a variety of tasks, including software installation, service management, system & software configuration, etc.
Question: Why are we starting to use puppet and related automation tools at work -- what goal does it serve?
Answer: To use Goldratt's Theory of Constraints that "... a chain is no stronger than its weakest link", we started with a serious problem: our company's delivery of software and its associated configuration from development to operations was not sustainable and was slowing down the delivery of valuable features to our paying customers. Puppet strengthens one link in that chain, namely an error-prone installation and configuration process. In one example -- the project I'm currently working on -- the Installation Guide when printed double-sided was over 3/4" thick and makes a serious THUD when tossed on the table. If you take a standard rate of about 1-2 serious typo's per page, there would be somewhere around 600-1200 opportunities to misconfigure the system simply through basic human error, not even counting documentation going rapidly out of date.
A key driver for me personally is that manual configuration and installation, frankly, sucks. It sucks time away from other interesting projects, drives down morale by introducing errors, and seems to constantly raise the level of finger-pointing ("your software sucks! It's always falling apart!" leading to "you messed it up when you installed it!" leading to "well, what version is even running there?" ... ad infinitum).
By moving to Puppet for managing the installation and configuration of our software at Vaisala, in combination with other technologies (Virtualization, repository-based packaging, continuous integration, monitoring, logging, and notification), we move to "INFRASTRUCTURE AS CODE."
Question: So, why Puppet and not just some shell scripts? Why not some other tool?
Answer: One answer would be "momentum," especially given the attendee and presentation count at Puppetconf -- that there is a huge growth in users of the system, across many industries from education, web operations, even space and fundamental physics research at CERN. There's a list of the commercial customers at PuppetLabs. There's a burgeoning community developing cross-OS, reusable modules and libraries at PuppetForge. By using puppet's Declarative language syntax, one can operate at a much higher level than a linear, step-wise shell script -- also a difference between Puppet and one of the biggest competitors in the configuration management space, Chef.
Puppet also has a level of maturity not yet achieved by some of the other tools: that the tool has been around in some form for more than 8 years, and actively used in the operations space for more than 5. Puppet 2.7 and up have a very friendly license (Apache-2.0) that makes it easy to use for both internal operations and for delivery to customers.
Finally, there's the question of scale: while not a huge problem for our company's current deployment, we have some applications that will scale to hundreds of servers, multiple database back-ends, and multiple load-balanced front-ends. At that scale, it will be impossible for our operations team to manage that number by hand without causing major headaches. At CERN, the operations team is planning to use puppet to manage 100,000 to 300,000 (!!!) virtual machines on tens of thousands of hosts. The puppetmaster/agent facility or "agentless" puppet scales to that level in a supportable fashion.
Question: What did you learn in your 2 days at PuppetConf?
Answer: Wow, not sure if I can summarize that in a single blog post, but let me touch on some major highlights based on the order of presentations I attended.
Wrap-up: If you use or develop/deploy systems on Puppet, this was definitely the place to be. The sessions on where and how Puppet is used proved to be the most valuable. The phrase “There’s more than one way to do it” -- familiar to any Perl developers -- definitely came up in conversations throughout the conference. Every person at the conference would agree that this tool allows them to handle much much more and at a higher quality level than they have deployed before. For any web company that has to scale with a minimum staff, you need to think about automation and the repeatability of your systems if you are going to proceed beyond the hand-editing of systems and configurations.