Published on 27 January 2016 by

James Pogran is a software engineer on our Windows Engineering team. He recently published the Learning PowerShell DSC book which was born out of his two-year struggle to make DSC work in a software delivery pipeline with very little documentation or support to guide him. Now all of you get to benefit from his learnings. If you’re struggling with DSC and want some step-by-step instructions to get started, I highly recommend checking out James’ new book. A free preview of the book is available here.

Tell me a little bit about your background.

I’ve been doing systems administration for over 10 years. I started working for Fort Meade in Maryland doing help desk and server side administration on Windows NT and Windows 98. After that, I moved up to New York to work for IPsoft as a member of the system administration team, and then developed their Windows monitoring and automation platform. They didn’t have any presence for Windows and couldn’t run commands on Windows, so I wrote an agent that allowed them to execute automation to remediate problems and monitor server health. I joined Puppet Labs last June as a software engineer on the Windows engineering team.

Why did you write this book?

At the time I wrote this book, there was nothing out there that provided step-by-step instructions on how to use DSC. I found lots of blog posts, online chats, and snippets, but nothing that gave you end-to-end instructions for how to use this technology. Before DSC, Windows didn’t have configuration management tooling so the mentality wasn’t there. DSC is a big mental shift for most admins. There wasn’t anything to walk you through that, to help you understand the concepts behind treating a system as something that should be repeatedly configured. That was a big Eureka moment for me. The book is a direct result of the last two years of trying to make DSC work in a software delivery pipeline.

Who should read this book?

Sysadmins and developers, anyone who’s practicing DevOps and configuration management for Windows. It’s very much a 101, entry level book. I explain why you should care about configuration management, why a repeatable build and deployment process helps, and then walk you through deploying and using DSC.

What are some of the challenges you faced while learning DSC?

One of my challenges with learning DSC at the time was that there was no documentation. Microsoft was trying to get the product out and into users hands as fast as they could, but that meant not documenting most of it. I’d try to do automate some part of my task and find little guidance on how to approach it using DSC. I knew how to do things in PowerShell, but the shift in thinking with configuration management meant I had to approach the problem differently. The experiential knowledge just wasn’t out there to find. There were no best practices to how to do things, so I tried to present the lessons I learned in the book for others to use. These will probably evolve over time as more people start using DSC in production. It’s obvious that MSFT is still working out the kinks in the product, and one of the areas of friction is handling configuration data.

In the last chapter of the book, I show examples of how to work with an existing app and add more configuration points. I wanted to show a common, real world scenario and then add curve balls to it so readers can use the example in their own environments. The example starts with one app, shows you how to automate an instance of a Windows service application, then adds on a website (how to handle dependencies, paths, properties, etc.).

What were some of the things you learned as you wrote this book?

Writing books is hard! It’s one thing to write a blog post or a small article, but it’s entirely different to write in great detail about complicated interdependent topics at great length. You start to explain a concept only to realize you have to unpack another concept first in order for the reader to understand. For example, to answer the question, “Why would you want to use PowerShell DSC” you have to first explain configuration management and DevOps in order to show the value of this approach, then explain how DSC fits into that. You have to create a baseline with the reader so they know where you’re coming from.

What are you most excited about seeing as DSC matures?

Even before I came to Puppet, I was excited that DSC was going to interoperate with other tools. At my previous job, I built systems that worked in between Linux and Windows. Very few tools work well for both environments without compromising utility or power. It was great to see Microsoft, out of the gate, working with third party vendors like Puppet. They didn’t have that initially, and only as of the second release could they really integrate with other vendors. There is a lot of flexibility and power that comes with being able to choose which tools you use — not being locked into one vendor or software is very important in today’s landscape.

Tell us about the integration between Puppet and DSC.

I’m part of the team that built the PowerShell DSC module. The Puppet DSC module directly executes DSC resources using familiar Puppet syntax. You don’t even have to do extra work to use Puppet and DSC, you can take an existing DSC configuration file and convert it to Puppet syntax with a few simple find and replace commands. We provide a wrapper for the DSC Resource declarations, which allows you to use the same properties and parameters as the DSC Resource, resulting in less code for you to write. We demoed the module at PuppetConf 2015, and have made a bunch of improvements to it so that it is now fully supported.

What’s the value of using Puppet and DSC together?

DSC has a breadth of resources, over 200 in fact. If you find something in your environment that Puppet doesn’t cover, you can call out to DSC without reinventing the wheel and adding more work for yourself. There may be some things that a Puppet resource doesn’t support, but a DSC does support. For example, the DSC user resource does a few things that the Puppet resource doesn’t do yet. However, DSC also doesn’t have any of the management tools that Puppet Enterprise offers, like reporting and a management console. These are big wins to have, as you can’t check the status of a server at any one time with DSC—you have to call the API yourself.

James Pogran is a senior software engineer at Puppet Labs and author of Learning PowerShell DSC.

Learn more

Share via:

Add new comment

The content of this field is kept private and will not be shown publicly.

Restricted HTML

  • Allowed HTML tags: <a href hreflang> <em> <strong> <cite> <blockquote cite> <code> <ul type> <ol start type> <li> <dl> <dt> <dd> <h2 id> <h3 id> <h4 id> <h5 id> <h6 id>
  • Lines and paragraphs break automatically.
  • Web page addresses and email addresses turn into links automatically.