Bitlancer developer Jesse Cotton is a long-time denizen of “Planet Puppet,” but has worked on some Chef projects as well. Recently Jesse took the lead on a Chef engagement for the first time and really dug into its capabilities. Here are Jesse’s thoughts on what that process has been like.

Overall impressions Chef is overall a solid configuration management tool with a strong community that deserves its place as one of the most popular options out there.

Biggest challenges The folks who develop Chef have not kept up with the evolving needs of its fast-paced user community. So different people advocate different “best practices”-when really there is no one “right answer.” As a result, there is a good bit of conflicting information and documentation online around implementing Chef.

Tips on getting started with Chef As I mentioned, there is a fair amount of confusion within the Chef community on how to deal with some of Chef’s inherent weaknesses. The Environment cookbook pattern versus Chef’s new policyfiles feature (still in preproduction) is an example of the fast-moving Chef community taking matters into its own hands before the implementers got around to offering a solution.

Because of these sometimes conflicting recommendations around critical issues, it makes sense to setup a Chef environment and experiment with it before choosing a path. Implement various suggestions and see how things play out. When you run into questions or problems, refer to the documentation and online community information.

I also found it useful to sketch out at a high level how I wanted to set things up, and how I planned to address key issues like Environments, before I started doing a lot of coding. Otherwise you’re likely to stumble upon issues and end up backtracking and choosing a different approach.

As an experienced Puppet developer, I see a lot that’s similar between Puppet and Chef. Getting your hands dirty by setting up a Chef environment and deploying a web server or whatever just to see what’s involved will help you get a sense of what’s familiar and what’s new for you.

Chef versus Puppet Its simplified domain specific language (DSL), plus the ability to mix Ruby code straight into your cookbooks, makes Chef more natural to pick up than Puppet if you come from a development background. It results in more elegant and readable code than you’re likely to end up with using Puppet. Also I like the Chef toolsets: knife, berkshelf, berkflow and chefdk.

Extending Chef (that is, implementing custom resources) is much easier and more straightforward than when using Puppet’s types/providers framework, which I really dislike. It’s nice to just write Ruby code to setup the configuration for a new technology, for instance-for me as a developer, at least.

On the minus side, handling configuration data in Chef is very painful compared with Puppet. You can use attributes within a cookbook, or you can use data bags, which amounts to a very simple configuration database. Either way you end up adding logic to your cookbook to detect and implement configuration conditions, while the Puppet framework mostly handles that for you. Chef needs a hierarchical database capability similar to what Heira brings to Puppet.

Another thing I dislike about Chef is its “cute” cooking-centric jargon. Test kitchens, cookbooks… It would be easier to learn Chef if it had more functionally oriented naming conventions. But once you’ve learned Chef that’s less of an issue.

Key takeaways Whether your team ends up implementing Chef or Puppet, either way you’re doing a good thing in terms of enabling the consistent deployment of servers and applications in the cloud. If your team has a strong development skill set, I recommend Chef over Puppet because of its configurability. If you’re hoping to leverage operational skills for configuration management, Puppet might be a better choice given its easier learning curve.