Chef from South Park (source)

AWS OpsWorks and Chef

I recently tried learning Chef 12 so that I could do custom deployments on AWS OpsWorks. I did not have a great experience with it, so I’m going try some other deployment technologies, like Otto and Terraform. But, before I move on, I’ll share some of my thoughts about the 20 hours I spent learning Chef.

Well, Chef is cute. All of the applications in the Chef ecosystem have cooking-related names. There’s Knife, Kitchen, Foodcritic, cookbooks, recipes, etc. Anyway, Chef is cute. You get the point.

But, once you get past the cuteness, Chef is a mess. Cookbooks, and the recipes inside them, are tough to write, and tougher to debug, because Chef abstracts away the complexities of installation and configuration in such a way that I have no idea what it’s doing. This is partly because I don’t know Ruby, the language used for writing recipes. But I suspect this is mostly because Chef is a massive, complicated system with its own idiosyncrasies, and it seems like you have to know a lot about how it works before you can make it useful. Now I’m all for abstraction, but Chef is unintuitive, and the abstractions strike me as artificial. What problems were the Chef developers trying to solve? It’s hard for me to tell from my recent attempt at using it.

Now OpsWorks is just Amazon Web Service’s way of using Chef to manage deployments. It seems fine overall, and if you are already an expert at Chef, it’s definitely worth using, but if you’re building new infrastructure, I would stay away from it. Chef and OpsWorks strike me as legacy systems, and thus should be avoided.

Anyway, those are my impressions of Chef and OpsWorks. I say stay far away from them if you can.