Geeks With Blogs
Alex Hildyard
Desired State Configuration -- rightfully so -- is getting a lot of press just now, and it is becoming synonymous with certain deployment solutions, like Chef and Puppet. What about the others -- for example, Nolio or Octopus Deploy? Are they going to fall by the wayside because they don't "do" DSC? What about MSBuild? What about WiX? I want to clear up a few misconceptions.

Here's my first point. *Don't confuse a workflow without conditions and an implementation with conditions.* Let's take Octopus. If you're deploying a website, you'll probably have a step called something like "Deploy Website", which will create or recreate the website in question, and then proceed to populate its various bindings, etc., and you're absolutely right, that's not very DSC. But there's no reason you have to do things that way. There's nothing to stop you pulling in the latest Powershell DSC resources and writing Chef-style configuration, in which your Step templates resemble recipes and your workflow resembles a cookbook. If you *do* decide to do this, you may not end up with exactly the same configuration as you would have had if you'd first dropped the website and recreated it, but, as I'll explain further below, *that really doesn't matter.*

My second point: *Behind the scenes, DSC may be a new name, but it's a very old concept.* Even MSI, an atomic, transactional deployment technology has DSC aspects behind the scenes. For example, unless you specifically tell it otherwise, its default behaviour is NOT to copy a file it knows is already correctly staged with a matching checksum.

Let's go back to first principles, and look at DSC in slightly more abstract terms.

* It usually performs really well
Yes, you read that right. While I don't tend to see people extolling DSC because of its performance metrics, think again about what's actually going on. With DSC you have a pre-condition step, followed by an action. That's just lazy evaluation by another name. You don't need a post-condition step to confirm the action actually worked, because you've already got one: it's your pre-condition step, run a second time after the entire system has been deployed, to confirm that everything worked out. If (most of the time) you aren't blowing your entire system away to redeploy it completely from scratch, then most of the time your system isn't going to be changing much between releases, and therefore there isn't much to do to move it from Release 1.0 to Release 1.1.

* It tells you the state of your system
It's easy to forget that between software releases things can change on your servers concerning which you have no knowledge, and over which you have no control. Cutting across your software deployments, an IS or Infrastructure team is involved in server patching, and the two of you are usually blissfully ignorant of each other's Release schedules. And then, in the background, the BAU team is silently fixing bugs, addressing defects, "optimising" queries, rolling out ad hoc Application monitoring software, changing email address lists in configuration files. Come your next major release, chances are the system you're about to blow away before redeploying isn't going to be quite the same one you originally deployed. But because DSC is based on pre-conditions, it's very easy to run these in isolation (essentially the -WhatIf switch). This is extremely useful, not just because it helps confirm the system is in a vaguely acceptable state (all the servers are actually up, all the App pools running, etc.), but because it brings all the system changes to light, so that you can have intelligent conversations with the BAU team, pointing out that you've noticed they've changed the distribution lists and logging levels, and you're about to overwrite their changes, so would they like you to set them back the same way again afterward or not?

I should however qualify this, since perhaps it paints too rosy a picture. I still get white knuckles running an ad hoc -WhatIf against a Production system outside its service window (if I even have permission to do that). Unless I have full access to the underlying code, I can't prove my -WhatIf will be entirely without side-effects, and can't guarantee that it won't affect system performance at the time, either. I feel the way forward here is a combination of familiarity and positive reinforcement. Establish that you will check the system state on a regular (eg. daily) basis; agree a time window, and then do it religiously. The first few days your script will probably get blamed for everything from an air conditioning unit malfunction to changes in the CHF/EUR. But familiarity breeds contempt (in a good way), and soon people will see more value than risk in what you're doing. Failing this, at least make sure there's a "system state check" scheduled at the start and preferably end of your official deployment window. This is a good place to run those checks.

* It makes clear what configuration you actually need
Think again about the DSC versus non-DSC way of configuring a website. If you blow it away and recreate it, it will come back with certain defaults. But if you only configure the bits of it that directly affect your application, you can remain blissfully ignorant about other details of its configuration.

This is important for two reasons. Firstly it means, contrived as the case may be, two very different applications, both deployed in a DSC-aware way, can coexist where "ordinarily" one would think the two should be in conflict. For example, perhaps they share the same Application pool, the same file system folders, a common Event source. They can do this because they only configure what they need.

And the second point follows naturally from the first. If an application only configures what it needs, then by definition it also knows what it needs, and what it's done. If an application deployment drops the Default website, slaps it back on again with some new bindings, and then finds it's broken some other system, it won't be able to articulate this programmatically, because it has no interest in how the new website "defaults" (that it's chosen not to configure) differ from the previous website's settings that it failed to examine before it dropped it. As a mind-set, non-DSC configuration tends to see itself as the rightful owner of all system resources, while the DSC approach, in contrast, tiptoes about the periphery.

* There is more than one way to deploy the system
Humans are creatures of habit. You won't be popular if, on the night of the deployment, you declare: "I haven't a clue how this deployment's going to roll out, but I'm sure it'll all be working by the end of the night. Oh, and if I do it tomorrow, I'll probably do it completely differently again ..."  But that's essentially how DSC works, because it may (or may not) have work to do. Of course, this is a simplification. As I explained at the beginning, DSC does not mean that your system randomly reconfigures itself in any old order it feels like. Things in the list need to happen in order; it's just that not everything in that list needs to happen. I also want to put a slightly different spin on this. *Multiple deployment paths all lead to a testable system state. And multiple deployment paths lead to multiple ways to repair a broken system state.* No one wants a deployment to fail, but I, for one, feel more comfortable in a failure situation with a DSC approach, because I can see exactly how far the deployment has progressed, and I can try multiple approaches to remediate things.
Posted on Thursday, January 22, 2015 1:39 PM | Back to top

Comments on this post: Deployment Tools: DSC or not DSC?

# re: Deployment Tools: DSC or not DSC?
Requesting Gravatar...
Wanted State Configuration is the PowerShell group's interpretation of a revelatory way to deal with designing servers UK Assignment Writing Service and is an other option to the basic approach of standard PowerShell contents. PowerShell DSC can be utilized for huge numbers of the normal arrangement errands that need to run when another server is provisioned.
Left by Cherish Kevin on Oct 20, 2017 7:15 AM

Your comment:
 (will show your gravatar)

Copyright © Alex Hildyard | Powered by: