A Recipe You’ll Never Forget
Last week, I attended Opscode’s public Chef training held here in San Francisco.
As a release engineer, most of my career has been spent wrestling with configuration management. And while I’d dabbled a bit with Chef, I hadn’t really “put on the apron” to graduate from sous-chef yet.
So I decided it was time to get out the cookbooks and do that.
In the recent Ship Show episode on training, we debated whether or not training is valuable at all. Sascha asserted that you can often obtain the same benefit by picking a real-world problem to solve, holing yourself up in a room with a book on the subject (or the Internet), and just working on that it until you’ve solved it.
I think that can be a way to do training, but I remain unconvinced that it’s particularly efficient, especially for a team. And, in the absence of a domain expert, I think it’s quite possible to miss some of the valuable ah-ha moments that illustrate concepts that are really necessary to be successful with the tool. (Or avoid hating it, because you wasted two hours on some slightly-misunderstood concept.)
Case in point: as part of the training, you configure a web server on an EC2 instance. Seems simple enough, right? Well, on the second day of training, we changed the configuration somewhat, did our Chef runs, and… nothing changed. The instructor sat with us, faux-befuddled for a few minutes, dropping a hint here and there, until the classes had precisely that “ah-ha” moment: with configuration management tools like this, you assert the state of the world, and Chef will assure that state is met. But, that doesn’t mean Chef will unroll your previous configurations, uninstall packages, or revert configurations.
Once you think about it, it makes total sense that Chef wouldn’t be responsible for this. And the exercise illustrated (in a visceral way) the new way in which you need to think about writing your cookbooks and recipes. It reminded me of when we learned functional and logical programming languages in college: it takes that ah-ha moment to really wrap your mind around how the tool and language works, how it’s different from what you know, and where you’ll need to be careful as you work more with it. And once you have that moment, it sticks with you in ways that will be incredibly useful when you’re debugging later. In my case, it prompted me to think about all the ways I might structure the exercises we did in class differently if I were using them in a production environment (which prompted some great discussions with the instructors!)
If you’re in the boat of “wanting the DevOps,” but not sure where to start, public Chef training is a great option.
You’ll get a hands-on experience with one of the major tools in the space, which will serve as a great foundation for further exploration and learning. Plus, it’ll introduce you to how you need to start thinking about your infrastructure—as code!—to really be successful, both with the tool, and the cultural transformation that is the actual benefit of “DevOps.”
If you’re not yet convinced, Opscode has a great Learn Chef site, and their training material for the Fundamentals class (the one I took) are available for anyone to take a look at.
When you’re ready to take the plunge, check out the schedule of upcoming classes!
(Oh, and in case you missed it: Ship Show listeners can get a discount on Chef training! Check out the show notes for details!)
Glad to hear you enjoyed it, Paul. So have we convinced you to give up RCS yet?
Not quite… I’m using git-rcs to ease the transition…