I get asked quite frequently “Can I do $SomeTask with (DSC|Chef)”.  My answer is almost always a qualified “yes”.

Two Motivations

• If I roll up my sleeves and dive into it, can I create automation for $SomeTask with (DSC|Chef)?The first question is pretty close to what was asked.  The intent of this asker is to determine if there are hidden “gotchas” in automating a task with one of the configuration management platforms or if $TargetSoftware allows $SomeTask to be done in an automated fashion.

• Is there an existing resource/cookbook/snake oil vial that does $SomeTask with (DSC|Chef)?

In this case, the asker really wants to know if either in-box or some third party has done the work to automate that process that the asker can pick up and use. (There is nothing wrong with looking for existing resources - it’s pretty smart actually.)

Both questions are valid.  The problem I see with these two questions is very often the asker doesn’t necessarily know which of these sub-questions they really intend.  This is due to a major lack of familiarity with what configuration management platforms actually do.  There is a perception that Chef, DSC, and other configuration management tools offer some enhanced capabilities outside normal automation techniques.

There is No Magic

DSC, Chef, and other configuration management platforms don’t provide any mystical capabilities or imbue systems with otherworldly powers to automate the unautomateable.  

I’m probably going to step in a big pile of manure here, but I’ll say it.  As systems administrators in the Microsoft space, we have been coddled far to long into thinking that Microsoft (and other major vendors) can deliver the administrative workflow that fits all our our organizations.  

Don’t get me wrong, there are sysadmins in the Microsoft space doing amazingly innovative things.  The time, however, has come for us to stop looking to Microsoft (and other major vendors) as the source of all solutions and workflow.  We need to expand our gaze and look around the industry.  Things are changing quickly.  Demands on IT are increasing.  Business requires more responsiveness from internal IT departments.  The risk of failure has more dire consequences with each failure putting you further and further behind, since your competitors are also picking up their cadence.

To its credit, Microsoft has realized this and we are seeing an unprecedented openness in the integration story around Windows Server, Azure, and the development tooling.  Jeffrey Snover, in his Monad Manifesto, laid forth a roadmap to make Windows Server automateable, putting the management power and flexibility in the hands of the customer - not the product teams.

Now it is our time, as the customer, to take ownership of our automation needs.  No one knows the needs of your organization better than you (and your team).  You need the agility to define management workflows for your organization and not have to wait 1 to 3 years for the next version to ship (then another 4 or 5 years for your organization to roll out said upgrade).  

Let’s stand up and get our hands around what our configuration management platforms can do for us.  And then, let’s get to building our automation workflows!

Resources, Providers, and Other Primitives

For the most part, configuration management systems end up calling command lines or system APIs via whatever language they are implemented in.  In order for a configuration management system to actually manage a component, it has to be manageable to begin with.

Back to the Original Question

This means, the answer to our initial question - “Can I do $SomeTask with (DSC|Chef)?” - is “yes” as long as there is a command line application that can do $SomeTask or if there is an API that your configuration management platform extensibility language can talk to.

If we dig into the deeper question - “Can I implement something that (DSC|Chef) can run to do $SomeTask?” - is totally dependent on $TargetSoftware that supports $SomeTask we are trying to automate.  It is 

Likewise, the question “Is there something out there that does $SomeTask for (DSC|Chef)?” - becomes very easy to answer.  If the supplier of $TargetSoftware doesn’t supply DSC Resources or Chef Cookbooks (or other CM tool packages) and there is not a community version that meets those needs, then the answer is “No”.

So What Good is a Configuration Management Platform Then?  Wouldn’t a Provisioning Script Be Easier?

In both cases, neither DSC nor Chef (nor other configuration management platforms) are what make tasks automateable.  They provide a framework for running those actions in an idempotent fashion, where the configuration management agent tests to make sure things are where they should be, and if not can repair the state of the system.  This is where configuration management tooling starts to separate itself from provisioning scripts, which don’t necessarily adhere to this pattern.

Configuration management tooling also provides an ecosystem of tools and resources for distributing configuration data, testing configurations, managing versions of configuration documents, and provide reporting and analytics.