Desired State Configuration Basics

Before delving into the details of the tooling modules, one should have a basic understanding of the components of DSC.  This post consists of definitions of several key terms:

  • Configuration – Executable code which produces zero or more MOF documents that can be later processed by the Local Configuration Manager (or an equivalent non-Windows agent) on a server.  A configuration is similar to a PowerShell function, but it has different common parameters and different automatic variables.  There are also keywords available that can’t be used outside of a configuration; these are Node and Import-DscResource.
  • ConfigurationData – As mentioned, configurations have different common parameters than normal PowerShell functions.  One of these parameters is -ConfigurationData.  It’s a means to pass a complex set of parameters to the configuration.This parameter accepts a special hashtable which must conform to certain minimum requirements:  it must contain a key named AllNodes, and the value assigned to the AllNodes key must be an array which contains only other hashtables.  The hashtables inside the AllNodes key must contain a property called NodeName.Aside from AllNodes, Microsoft has stated that any other keys in the ConfigurationData table which begin with the prefix PS should be considered taboo; if they extend the required parameters at some point, the new keys will begin with PS.
  • Resource – DSC resources contain the executable code necessary to implement the actions described by a MOF document.  For Windows endpoints, DSC resources are small PowerShell modules which expose three commands, at minimum, named Get-TargetResource, Set-TargetResource, and Test-TargetResource.  The parameters passed to these commands are populated by the values in the MOF document.DSC resources must also contain a corresponding schema.MOF file which describes the parameters accepted by these PowerShell commands, in the MOF language.
  • Local Configuration Manager (LCM) – This is the Desired State Configuration agent which runs on every endpoint.  It’s part of Windows Management Framework 4.0.  The LCM is responsible for reading the MOF documents which describe the desired configuration of the local computer, loading an executing the resources associated with that configuration, and interacting with the pull server and compliance server to do things like download new MOF documents and resource modules, and report status.
  • MOF document – MOF stands for Managed Object Format; it’s a standard format for plain text documents which are used to define classes and objects in CIM (Common Information Model.)  By having the MOF document layer, Microsoft has decoupled the PowerShell configuration language from the Local Configuration Manager.  This means that it’s possible to produce MOF documents from toolsets other than PowerShell, such as Chef.  It’s also possible to use PowerShell configurations to manage non-Windows devices, provided that an agent exists on the non-Windows platform which will read and process the MOF documents (such as OMI on Linux.)
  • Pull Server – An OData-based web service which serves up MOF documents and resource modules to endpoints.  Resource modules are hosted in the form of zip files.  Both resource module zip files and MOF documents also have a corresponding checksum file, which allows the client to make sure they have a complete download.
  • Compliance Server – Another OData-based web service which accepts status reports from endpoints, and stores that data in a database which can be reported on later.

This is very much a birds-eye view of the DSC technology, without going into any great detail.  However, these definitions are enough for us to discuss the roles filled by each of the DSC tooling modules.

DevOpsGuys Does DSC

Over the past few weeks, we’ve been working on incorporating Desired State Configuration into our continuous deployment pipeline.  We’ll be using this technology internally, eating the dog food, but we also want to be able to help our clients leverage this technology.

To get started, we decided to take advantage of the excellent work and experience of Steven Murawski.  During his time at Stack Exchange, Steven was one of the first and most visible adopters of DSC in a production environment.  Over time, he developed a set of PowerShell modules related to DSC, which have been published as open source over at

We’ve been working on some updates to this code internally, which we’ll be submitting back out to the community by way of a pull request very soon.  The main thing missing from the tooling modules right now is simply examples and documentation, but we’ve also identified a few places where the user experience could be improved.  In separate blog posts, we’ll talk about each of these DSC tooling modules:  what problems they solve, how they do it, and what changes or improvements we’ve made at DevOpsGuys.

B.F Skinner on #DevOps (circa 1985)

I came across this interview with one of the founding father’s of behavioural psychology, B. F Skinner, the other day and was immediately struck by the phrase below:

What’s needed is to give satisfaction back to people. It’s the difference, he said, between a craftsman who makes a complete chair and a person on an assembly line who makes only the legs. The craftsman’s work, Skinner said, is constantly reinforced by the process of seeing the chair take form, and finally of producing the finished chair. But the assembly-line worker sees only chair leg after chair leg — never the completed product.

Skinner is not advocating elimination of important modern advances, such as the assembly line. But he would like to see industrial engineers and psychologists continue to team up and produce better workplaces and better ways of working that will offer modern employees the psychological lift that the craftsman once felt.” B.F. Skinner interview

To me, this neatly encapsulates one of the central tenets of the DevOps movement – we want to “team up and produce better workplaces and better ways of working” that deliver simultaneously better value (faster) for our organisations AND  improve the morale and job satisfaction of Developers & Operations staff. 

We need to CARE about the “completed product” because we’re following the “First Way” of Devops and using systems thinking models to look beyond our silos and relentlessly focus on the big picture. 


“is your organisational culture ready for #DevOps?”

“What would you say are the primary indicators that your organisational culture is ready for DevOps?” was a question Sean Ferigan (@ferigan) posed at the recent Rackspace DevOps Breakfast Briefing.

This short (48s!) answer was filmed after the panel to try and give a (very) quick answer.

So basically you’re in fertile ground for DevOps if you’re seeing a “push/pull” model

  • “push” from below where technical staff are keen to try DevOps tools & technology (going to DevOpsDays, doing “skunk works” DevOps projects etc) and
  • “pull” from the Business to deliver business value via technology faster & faster (time-to-market acceleration)

I’d particularly say that if you’re seeing high levels of Shadow IT then you’ve got a great “pull” signal that you have to start doing things differently before you become irrelevant to your organisation.

@DevOpsGuys in the press, talkin’ #DevOps

Lots of great press coverage of DevOpsGuys this week courtesy of the Rackspace, #DevOps breakfast briefing. 5 separate articles so far!


Great to see some mainstream IT publications talking about DevOps! 


Is the S (Sharing) in CALMS Redundant?

@MLCarey321 asked a interesting question on Twitter the other day – is the S for Sharing in the CALMS model not redundant? If you have the right culture that emphasises collaboration & “no silos” surely “sharing” flows out of that? 


My view is that from a cultural perspective he’s probably right, a DevOps Culture definitely should encompass “sharing” as a core value so why do we need the extra S? 

CALMS Model of DevOps

I think that the extra S is there to emphasise that just having “sharing” as a core value isn’t enough – you need to actively put in place mechanisms to promote, facilitate and reward sharing at multiple levels

For example here at DevOpsGuys we:

  1. Heavily use Atlassian Confluence as a wiki for documentation and documentation is seen as a “living thing” that must be kept up to date because it has value to the team every day.
  2. Use HipChat for informal communication, “What am I doing now”, “Does anyone know something about topic xyz” etc. HipChat is also integrated with JIRA, PagerDuty, CI/CD. 
  3. JIRA Kanban boards for sharing “this is what the team / individual is working on how”, plus time-tracking and work status. 
  4. All of the 3 above are also accessible by the clients – so sharing means “sharing with the customer” too, not creating an “us&them” silo. 
  5. Blogging and presenting to share with the community is strongly encouraged and we’ve started a meetup group DevOps Cardiff (in addition to London Web Performance that I’ve run for 3 years)
  6. Our GitHub repo is a bit sparse at the moment but we hope to open-source some stuff in the future, particularly some samples around Powershell DSC

As we grow and we bring on more grads & apprentices everyone will be paired with a senior mentor to ensure that skills & experience are shared across team, and we’ll start doing weekly “brown-bag” session to further share knowledge.

One area we haven’t looked at yet is explicitly promoting sharing via an incentive/bonus scheme based on “# blog posts” or “# open source commits” or “StackOverflow Reputation“, mostly because I’ve never seen it work successfully in previous organisations in which I’ve worked.

That’s not to say it can’t work… but you have to think about it very carefully or otherwise you risk incentivising the wrong behaviour. My feeling at the moment is that this will remain “ad-hoc” when someone shares “something cool” or gets accepted to speak at a conference or something.

How do you promote, facilitate and reward sharing in your organisations? 


DevOps – The 3 question #DevOps Litmus Test

Are you REALLY doing #DevOps inside your organisation?

We’ve spoken about the 8 pre-requisites for DevOps before but today we’d like to propose a very quick “litmus test” to see if you’re really aligning your organisation with key #DevOps principles and not just doing infrastructure and release automation with a DevOps whitewash.

These 3 questions have been formulated of the basis of visits to companies that say they are doing DevOps and/or conversations with people at conferences & meetups about their progress with DevOps transformation.

#1 – Have you spoken with HR yet?

DevOps is about people.

HR are the “people people”. So how can you have do an organisational transformation (even if the scope is limited to just the IT department… which it shouldn’t, but I digress…) without involving HR?

DevOps will involve new ways of working, possibly new organisational structures, new incentives, new on-call rotas etc – all of which will have a direct impact on employees terms and conditions

Regardless of whether you see HR as Change Makers or Handmaidens at some point you will need to talk to them… and I’d recommend doing it sooner rather than later!

#2 – Have you spoken with Finance yet?

In a word… Flow.

Jez Humble has presented about Flow, Gene Kim talks about Flow in the 1St Way of Devops and we’ve even blogged about flow and getting off airplanes.

So what’s flow got to do with Finance?

Well, Finance people are, by and large, are addicted to ROI, and the easiest way to measure ROI is a project-centric view of the world. You propose a fixed unit of change with some notional return on investment, get allocated a cost code, Finance tracks that cost code, allocates you more money when you overspend because the project’s running late, and then sweep it all under the carpet when the whole business case turns out to be a bunch of hot air. Or maybe that’s me being cynical?

We happen to believe that the project-centric view of the world is also a great way to DESTROY value. I’d recommend checking out Allan Kelly’s posts on #NoProjects and #BeyondProjects for some great though-provoking stuff on this topic!

In any case the project-centric view of the world is normally “lumpy” – activity is tied to the budgeting cycle, things tend to start in waves – and budget ends when the project ends and then the job of running it in Production is allocated to a different cost code (normally the BAU cost centre).

All of this impedes achieving flow, and having a product-centric view of the world. So in order to achieve a true DevOps model you need to talk to Finance about how budgets are allocated, and ideally try to move towards a product-centric budgeting model.

#3 – Who’s your senior management sponsor?

Look, we’re huge fans of grassroots DevOps initiatives where enthusiastic people are trying to bring #DevOps principles into their organisation from the bottom-up. We’ve even been known to hand out hardcopies of the Phoenix Project to key people within organisations to try and get them thinking about better ways of delivering IT :-) 

But let’s be brutally honest – that’s only going to get you so far, and to get any further you’re going to need an allocation of resources (time & money) in order to really get things done.

And the best way to get money is to have a senior management sponsor push the initiative forward, remove obstacles and generally take credit help you achieve your DevOps transformation. So if you DON’T have a senior management sponsor then at best you’re doing a #DevOps pilot project, you’re not really “doing DevOps”. Yet.

Anyway, those are 3 quick questions you can use as a DevOps litmus test – what questions would you ask?


Get every new post delivered to your Inbox.

Join 2,096 other followers

%d bloggers like this: