PowerShell DSC for DevOps and ALM v1.0 released
I’m excited to add to the fanfare that the first set of ALM Ranger Guidance for PowerShell DSC has been released (full details can be found on Willy’s blog here: https://blogs.msdn.com/b/willy-peter_schaub/archive/2014/10/16/powershell-desired-state-configuration-for-devops-and-alm-practitioners-v1.aspx). I have been a part of other Ranger projects before but this one was different for a number of reasons and I wanted to talk about it and how it applies to DevOps in general.
In virtually all Ranger projects, experts from Microsoft, Microsoft Most Valuable Professionals and various other experts in the industry are brought in to help with a project (it is truly remarkable as we all work on these projects in our spare time). We engage with the product team(s) as needed when we need technical guidance and someone from the product team is almost always chosen as the Product Owner. This was different. Desired State Configuration (DSC) is relatively new. The guidance out there is still in development. Many blog posts, books and articles have been written about it but a lot of the details and plumbing were either missing or incomplete. While PowerShell is ubiquitous when it comes to managing Windows Servers and even Azure, its application with DSC is very new.
But Rangers aren’t shy – a bunch of us with PowerShell experience, ALM and Release Management and Operations experience committed to work on the project even though we knew relatively little about DSC. However, we’re a committed bunch when we put our minds to it – I’m proud to be a part of a group who’s vocabulary does not include the word “quit”. We all had to learn a lot and fast. The Product Team, lead by Keith Bankston as our PO spent time educating us, pointing us to all of the material available and really helping us over every bump we ran into – and we ran into a lot of them. We spent several weeks ramping up on the technology and then we started asking questions.
One thing I can’t emphasize enough is that while DSC isn’t particularly hard – that’s one of the beauties of it – the process has to be understood and in many ways that is way, way harder than the technology which we all picked up relatively easily. But from a process perspective we started asking questions and we came up with some really good answers so that you, the consumer of DSC, don’t have to think about quite as much as we did.
Is DSC absolute?
When we think of the word “State” in computer science we think of an absolute. Here is how it is defined by Wikipedia:
“…the state of a digital logic circuit or computer program is a technical term for all of the stored information, at a given instant in time, to which the circuit or program has access.”
There’s no room for fudging here. However, that’s not quite how “State” is defined when it comes to DSC because there are two instances of use in DSC.
Instance 1: A resource reserved for a single use exclusively
In this scenario, the individual configuring the system is the only individual needing a resource to be in a given state. An example of this is a server that is dedicated to support only a single application.
Instance 2: A shared resource
In this scenario one or more individuals may need the system configured for their own use but they are doing it on the same system. An example of this is a web server hosting two different applications.
The Ranger guidance talks about minimum and absolute configurations. But the question of minimum configuration led to a question that I asked during the development of the guidance – what happens when there are two different configuration files which target a single server? The answer: this situation is not possible. A single target machine can only pull its configuration (or have a configuration pushed to it) by a single machine. On the source machine, only a single configuration can apply to a target machine. This leads to the second important item.
Version control your configuration scripts
We mention this quite prominently in the guidance. However, the paragraph above describes a scenario where multiple people are accessing the same configuration file and possibly making changes to the same configuration settings. My first thought was, “well, how do you stop someone from changing your configuration?” Keith had the best answer that I’ve ever heard: “The people making changes to the configuration have to talk with each other!” Well, how often does that happen? It’s going to have to happen – and even better, the configuration is also a very easy way to communicate with the operations team.
Take advantage of DSC as means to communicate with other people using a server and the operations team. And maybe the operations team is the group that owns the configuration and helps facilitate communication with all teams using a given server.
I hope you enjoy the guidance and I’m happy to have been a part of this team – it was great, great people, great technology and a great environment.