short thoughts‎ > ‎

Why Chef configuration management? Why not puppet?

posted May 29, 2011, 4:07 AM by Steve Craig   [ updated May 29, 2011, 10:46 AM ]
Why Chef? (or, why not puppet, cfengine, BMC bladelogic, HP opsware, MS SCCM ... or anything else on the list @ http://bit.ly/cfmanage)

My easy answers to this important question cause pain in numerous other ways:
1. Windows
2. cashflow

"Cashflow" rules out cadillac solutions such as BMC bladelogic and HP opsware, and "windows" rules out most of the open source solutions on the list.  Why not SCCM, then... especially seeing as how I have a valid MSDN account?  Again, the two main reasons hit here: anticipated future licensing costs and the need for a solution that works with both the (overwhelmingly Windows) client-facing hosting environment as well as more traditional open-sourced infrastructure products for internal tools (nagios, request tracker, cacti, subversion, git, apache) running on *insert favorite flavor of* linux.

So the chef install proceeded with all due haste; I'd rather pay the "capital cost" in time to automate now because each Site Support minute spent performing click-click-click inside an RDP session increases costs now in the present and ensures the costs will remain into the future, as well.

There was one major issue, however:  I had no knowledge of Ruby.  Therefore, the numerous blog posts stating "a main advantage of Chef is that it is pure Ruby (rather than puppet, which uses its own language)" swirled in my mind and coalesced into a double-edged sword.  In the end, I realized there would be a learning curve to any new tool, and this seemed like an excellent opportunity to gain focused, small-scale exposure to Ruby that could easily lead to more in-depth uses and projects.

Although it seems like a paradox at first glance, I figure the risk of "time-sink" purported by the major requirement of learning a new language will most likely be mitigated with time and use.  If I struggle and am inefficient with Chef it will most likely be due to other, more basic factors than any barriers thrown up by my lack of knowledge - or inability to learn - of Ruby.

The final piece of the puzzle was the enthusiasm and activity on twitter, github and the opscode Chef confluence wiki itself surrounding #chef and #devops ...  Not to mention the larger community and social network surrounding #ruby and #agile.  Imagine my surprise to learn a tweep I've been following (for years, primarily for other updates) @lusis is active inside this #devops hashtag!

So in the end the main markers were:

- free (beer)
- free (open-source)
- flexibility (full scripting language support)
- OS-compatibility for my specific project (no vendor lock-in)
- active social network streams #devops #chef

Coming up ... I've got buy in from the rest of the #smashrun team to begin sharing some of the Chef recipes I've whipped up to begin automating Windows sysadmin tasks for http://smashrun.com  Please stay tuned, or proceed to setup your basic Chef environment!

Comments