Chef vs DSC implementation

This topic was probably discussed before but I can not find a good reference material what Chef adds to pure DSC implementation based on WMF5? With addition of partial configuration in conjuction with PULL setup, DSC is viable standalone solution and not platform anymore like it was marked originally by Jeffrey Snover. So it’s a valid question Chef vs DSC implementation or combination of both.
Wondering if somebody already works with Chef, what does it add to pure DSC implementation. I really prefer not to learn Ruby and go back to running EXEs on servers but I can see how DSC lacks behind in fine tune orchestration.

Here are two good articles that were written in the past to address this topic:

I am sure someone may be able to chime in on the newer functionality in DSC, above is a good starting point though.


The platform vs. tool argument still rings pretty true. DSC is really great for implementing configurations in your environment with readable code that you can use for documentation and audit purposes.

But in a large environment where you need reporting on a large scale, and management of a library of configurations, Chef is definitely the place to be.

My favorite Chef feature that DSC still doesn’t support are notifies / subscribes. This allows you to do things like restart a service after changing a config file, something that is quite annoying to do in DSC alone. (Generally require a custom resource, or Script).

From my feeble mind, it comes down to this: do you want to make all the tools or are you willing to buy them?

DSC can absolutely do it’s job without Chef or Puppet. But DSC is a framework and is missing LOTS of things that something like Chef will provide. Some of it is easy to code yourself with custom resources, other parts much trickier. But all of it takes real time to code and hammer out. Lets look at the big stuff:

  1. Password management. Secure password repos are standard fare in Chef/Puppet. Nothing of the sort exists in DSC, so you have to download someone’s code or come up with your own model as well as how you plan to inject that into the mof build process.

  2. Code delivery. How is your stuff getting from your Git to your build servers? Chef has integration for this delivery. DSC doesn’t. Going to need to grab Jenkins or some other freeware and configure it yourself. How is your build and testing happening? Again: DSC isn’t giving you any build process here … go get some PSake.

  3. LCM Agent Management. I had many a heart to heart over the last PSSummit with Microsoft on this. It’s absolutely terrible in DSC natively, from certificate rotation to the fact that changing any settings on any client LCM must be done locally on the node. Y can set the mode to disabled, let Chef/puppet install their own agent … and this issue is now solved.

At the end of the day, a release pipeline model is really what you’re building when you drink the DevOps Kool-Aid. Take a read on more details of it in the below link, but even if you skim, look at the depth of the pipeline and realize DSC only helps with a tiny part of that … Chef and Puppet both bundle a lot of tools to make building this out a much faster process and leave less up to you.

So yeah: DSC is a framework, Chef is a tool.

Well the reason I’d rather use DSC then Chef is due to the familiar Powershell authoring environment and with pull configuration and onegen in WMF5 it’s provides end to end solution for automation for configuration tasks. My requires are purely configuration/deployment of OS and not content.
DSC,partial config, HTTP pull method delivery kind of provides me entire solution and not just platform for managing servers (trying to move away from GPO).
On the other hand I went through Chef online training and saw their console etc I think the best solution will be author internal resources in DSC, deploy them to pull server but perform configuration of DSC through Chef client instead, since it’ll provide the best of both worlds I would assume. I don’t need to learn Ruby and still use Chef with DSC as backend.
Will that work?

There are some pipeline CI\CD based powershell frameworks freely available on github so suggest you look for some and see if it suits your needs.

Since my env consists of both Windows and linux/unix its safe to assume well be using some configuration managers like chef, puppet, ansible etc but am still going to rely on dsc for the windows part. But then neither of them have source control integration or build integration like Jenkins unless you write your own custom code, which then forces you to learn ruby or whatever language the configuration server understands.

I just hate the fact I need 7-8 products to build a full pipeline to fulfill devops, same as Donovan Brown noted in one of his blog posts, when I have almost everything I need in one platform - Team Foundation Server.

If Microsoft took the Build engine and ReleaseManagent and made them freely available as OSS there would be the missing link as it gives all the necessary parts needed: Source control integration, build service with unit testing, deployment services (using DSC) with staging and workflow and reports, logs and application insight to close the loop (probably will require more work).

Until then, up to us to build the tools and connect all the dots.

My 0.5$ on the matter :wink:

I completely agree with your grievances. Thankfully Jenkins isn’t that complex, I was able to get it up and running much faster than I feared, but I confess I assumed if I went the “paid route” I would get a tool set to do exactly what you’re describing and not have to have this “collection of things” I run today that was a by-product of my frugal nature and desire to learn. Doesn’t Chef test kitchen basically provide the test framework? I thought Chef did, in fact, plug those holes in.

AWS Beanstalk has it down … is there really no on-premise/hybrid equivalent?

Agree 100% with this. I think DSC is great tool for configuration and I use it with Chef. Chef has attributes, and Ohai which I really like.