3 months with Chef

Over the past month, I have been using opscode's Chef to setup a linux server and a few Windows servers.  I'll be posting more about my adventures as I learn.  The feedback below is of the context of someone new to Chef, and the accuracy will probably be off in some areas.

The cookbook DSL, another wheel

I really dislike the DSL.  It is a reusable orchestration between providers, and an interface with state data.  An extremely common pattern that has been implemented so many times, from workflows to service buses, to object oriented patterns.

Why reinvent the wheel?

Best practices need not apply

Open/closed, single responsibility, re-usability, and testability are all basic qualities every application should have.  Cookbooks have none of these.  Found a great cookbook that sets up an app, but you need to change just one thing?  Fork it, and either hope they take your pull request, or maintain a fork for life.  This is why we have moved to OOP and away from procedures.

The mysterious compile and converge

When Chef runs a cookbook, it first "compiles" the DSL, then converges the results.  I like to think of it as instantiate and execute, mostly because that is what it is actually doing.  It goes through your ruby code and instantiates your provider calls using your logic.  It then populates a list with all the objects.  Once all the cookbooks are gone through, it executes the actions of the objects in the list.

Be very aware of what, in your cookbook, is run when.  If/else blocks are compile time, only_if are converge time.

Another package manager, with more dependency hell

Chef is very similar to a gem or nuget server, and a cookbook to a gem or nuget package.  When a chef-client is being executed, it starts pulling down cookbooks based on the metadata chain.  Cookbooks depend on others, and you have to restrict the dependency chain by version, or a future version in the chain might break you.  If someone in your chain later adds a dependency, you'll want to update your chain to be safe.  Berkshelf, and the Berkshelf API helps a lot, and should be used.

Mulling a better design

Why not remove cookbooks, and the cookbook management and just use a OODP with gems?  It would simplify everything, minimize documentation and the learning curve, and increase extensibility.

Windows, a second class citizen

Some of this is Chef, some of this is Windows.  In Linux, I find it to be pretty easy to write decent cookbooks.

It's Windows

Doing things on Windows command line is difficult compared to Linux.  The utilities and documentation is sparse.  Do you use Powershell, WMI, the registry, or ruby?  Is there even a way to do it via command line?

No, it's Chef

You gotta use all these extra "things" because the providers are not really built out yet.  Want to use the Service provider to set the "logon as" context?  Sorry!

Is it worth it?

After all my complaining above, I absolutely think that Chef is worth the time and money.  The value you get out of having your infrastructure as code is so important, all these gripes are just that.  It is a fast moving niche, and one you should start learning and add to your resume.