Here’s my simple advice about Chef I wish I would have heard a year ago:

All the stories about the unicorns, rainbows, and fairies that are doing absolutely amazing things with configuration automation are extremely inspirational. Read about them. Learn about them. Enjoy their talks. Enjoy their hipster vibe. Tell yourself that you are going to be cool like that one day.

And then forget everything they are talking about. Because what they are doing is likely too advanced for what you’re trying to do, because you’re not five years or more into your infrastructure automation initiative.

Do this instead:

Create these four nodes in your Data Center, behind firewalls, with no outside connectivity whatsoever:

1. A Chef Server
2. A Chef Client with the ChefDK installed on it
3. A Chef Analytics Server
4. An Artifacts Server (like SFTP server)

Does your security team not allow connectivity between Production and UAT (User Acceptance Testing)? Awesome! Build two environments! Does your security team segment audited environments from non-audited environments? Awesome! Build the above four servers in every segmented environment you have.

You heard that right. Now isn’t the time to get into pissing matches about your new devops vision of greatness that will totally transform…everything! No, now is the time to automate the things. Set up your servers and make it happen.

If this becomes political, then you are doing it wrong.

But Michael, how am I going to maintain all those environments? Well, thankfully you have the joy and pleasure of (1) probably having a bad system in place which is why you are looking at Chef, and (2) Policyfiles. So get over your perfectionism and implement this easy workflow for change management:

1. Use a policyfile for every node in your infrastructure
2. Save changes to policyfiles into Git where each team has their policyfiles in their own git repository separate from their cookbooks
3. Use your CI to automatically generate your policyfile.lock.json files and check them into Git.
4. Use your CI to package each policy into a file with the chef export command. This has all cookbooks, policy, everything.
5. Get your updated policy archives to your Data Center. You should be good at this. You do this already.
6. Activate your archives on the Chef Server for the appropriate policy group with the chef push-archive command

It’s as easy as that. Have one or a hundred Chef servers and you have those six steps above. You can save the absolutely mind-blowing automation of step #5 and the simplification of everything later. That’s not the most important thing.

Here’s what’s most important: an application team deploys an upgrade with zero outages and zero problems. Then they brag to their leadership about it because it never went this smoothly when they did it the old way.

Notice nobody cared about a stupid security argument about what ports are open between environments (there are none in the above proposal) or trying to be like Etsy or Netflix. People saw the zero outage and zero problems and people said to themselves, “Holy Shit This Is Real”.

Multiply the Holy Shit This Is Real moments.

That’s what you’re trying to accomplish. Not a dream state. Not what a book said. You’re fundamentally transforming your organization’s ability to react to change, and that capability will be an absolute game changer.

So get out of the politics, get out of the arguments, document and implement the simple strategy above, and watch perceptions of what is possible rapidly change.