Starting DSC using WMF 5 - Setting company expectations

DSC
1

Hello PowerShell community. I’m looking for thoughts and feedback on the following scenario at work as we start to dive into DSC.

My management has bought into the promise of DSC. I’m glad for that (truly). But, the major kick-off to this effort was to hire in a consultant for 3-months, during which we: 1) learn version control, 2) build a server baseline in DSC, 3) build a test framework (pester), 4) Do this using an agile 2-week sprint methodology, 5) at the end, deliver base OS build config via the new DSC configs; 3 of us are working on this. (Another group is doing Linux-with-Chef). This is our FIRST adventure with DSC.

Issues I’ve run into: I can’t excel at all this simultaneously. [Not to mention I could not simply ‘unwind’ from existing work on a dime.] I’ve never worked in ‘software design’ sprints before and I find it constraining and challenging for my learning process which is low-and-slow. Additionally, we decided strategically to utilize WMF 5, which you know is not production ready yet; I’m working on class-based custom resources which don’t support pull server yet. But our program manager is selling this as production ready at the end of our consulting engagement in about a month. By example, when I hear how Steve Murawski built server configs in early DSC for Stack Exchange out of 6 or 7 resources, 15 composite configs, plus all the testing – and it took him over a year – I think there’s a disconnect with expectations and reality at my organization. Another common approach I’ve heard is, '‘pick something in your datacenter’ like what services should be running on servers, and use DSC for that, as a start. I’m working to get this feedback heard.

I’ve always been highly self-directed and tend not to work well under arbitrary constraints (yeah I realize I have to deliver output somehow and within reason, that’s my job). The “motivation trifecta” of Autonomy, Mastery & Purpose resonates with me. These 2-week sprints and daily standup meetings crush my autonomy and interrupt my mastery. My efforts work in bursts where periods of slowness are followed by bursts of stuff that comes out as it starts to make sense. The purpose gets distorted by the program manager when she sells it as production ready too soon. It is so frustrating because DSC is so important. For the rest of the local team working on Windows, it’s business as usual – click Next, Next, Next Finish. Maybe a few PowerShell scripts here or there ad-hoc.Getting the rest to come on-board at the right time may be somewhat like moving a boulder.

I’ve also tried to assess whether it’s just me or the system in which I’m working (am I too slow, am I thinking about it too much?, Have we bit off more than we can chew to start?) I’m not a fast scripter but I do produce production-quality work.

Assuming my verbosity didn’t kill you, I wonder simply what gut reactions people have for this, based on their experiences.

2

That short of a sprint development cycle makes it really hard to create complete solutions if you have nothing to start with. It works best when you have an established base that you build off of with realistic goals that can be accomplished in that cycle. It’s meant to give you a clear vision for 2 weeks in your case of what to work on. If you feel like it isn’t enough time the scope of the sprint may be too big and needs to be trimmed back. You will always end with a backlog in a sprint unless you scoped too little work, this rarely ever happens in my experience. It will take a couple sprints before you find the right mix that works for your team. If you run into unexpected issues that makes the work take longer that’s ok, it’s just a focusing routine that makes sure you are working on the things that drive business value. Hopefully your manager had sprint lead experience in the past otherwise they may not understand this is something that takes tuning and time to get right. You may find 2 weeks really is too short and you bump it to 3 or 4.

Learning DSC will happen over time, don’t stress too much about knowing it all now or soon. Just learn what you need to be successful for this sprint, and plan that into the time it will take to accomplish the tasks in the sprint. Each sprint it will get easier. By my 10th or 11th custom DSC resource it was cake, I can crank one out in no time at all if I know what it needs to do and it isn’t some complex beast like I’ve seen some of the community ones attempt to be. Simple and sweet, does one function only is best. I digress, you will learn this stuff, at your own rate regardless. It will all depend on the scoping of your sprint and how much you think you need to get done vs what is possible to get done and don’t forget to include research in the time estimation for tasks it isn’t just 4 hours (this is an example) per DSC resource to build and test, the time it takes to put up the framing and do initial research may be 4 hours but to complete and build is another 4. Again these are just examples to think about when you do your sprint planning.

I can’t speak to using WMF5 in production, I would love to but have the same concerns as you do as it is in preview. So for now I am sticking with the old way of doing DSC resources in WMF4, it’s a little bit more work but it works the same way in the end.

My initial experience with DSC was about a week figuring out the basics, building a pull server, figuring out how I wanted to structure my scripts, how to build a basic DSC resource, and do a basic DSC pull config. I spent the next two weeks writing over two dozen DSC resources to build a configuration of what I consider a more complex scenario, multi-instance MSMQ failover cluster with iSCSI storage to our SAN. I’ve completed about 95% of the tasks I know of, there is always one more thing that we do manually that is just a click that I want and need to automate ends up as another small DSC resource, simple and sweet.

This does pay off. I think you know that. A peer of mine recently came out of a meeting needing an instance like this MSMQ cluster by July and it would otherwise be a big deal if the prior work wasn’t done. Now it’s just a couple dozen lines of configuration data and he’s done. No servers to “build”, software to install, did he get all the settings right, etc. Its is one of the closest things I’ve seen to IBM pixie dust in 15 years doing Windows Server administration. This person has good PowerShell background but again took quite a bit of time to dig around in it and is low and slow like you. He’ll get DSC, he sees the value and wants to learn it. There are others that could care less, its just a matter of convincing them that the week it takes them to build that server can be done in an hour of configuration data instead, or better yet working on using our CMDB to pull the configuration data from instead so they just fill out a form instead of building hashtables, json, psd1, or whatever other mechanism you use for storing that configuration data.

PowerShell DSC is young in its lifecycle it will get better. It isn’t going away. There are other products that can accomplish the same thing, I’m not as found of other products as Microsoft has done a killer job integrating this into one of the most powerful scripting languages I’ve ever used, but they are there and can get the job done. You are lucky that your management has bought into the DSC pill, I would love to have that kind of backing to automate with DSC as my tool of choice. Unfortunately it looks like I’ll have to use another DSC style tool that I will more than likely make invoke either powershell scripts or maybe DSC to configure items that the tool doesn’t support.

You aren’t alone with struggles and frustrations around what really is a change in culture for Windows Server sysadmins. Some will really struggle. Those that haven’t learned PowerShell are in the worst situation as if you’ve avoided PowerShell up till now I can’t imagine how with all the things moving into it and out of traditional GUI. Those that learned PowerShell but don’t lean on it everyday to do their job will struggle. Its people that when asked a question or need to solve a problem that jump right into ISE to build a solution, they are going to thrive with DSC. Those are the kind of people you want to be our sysadmins. Not all sysadmins will want to do that and I think they will find their place, and it may be not as a sysadmin.

3

Adam:

Thanks for your detailed reply. The disconnect I am having with the software development sprints is aptly described when you mention that it flows better when you have a base to start with. We are trying to develop the base and the solution simultaneously and at a fast pace. I have nothing wrong with embracing a ‘developer-like’ role, I’m just not one instantly. I’ve got a big dose of cognitive dissonance. I fully embrace DSC as a key ‘way forward’ in Windows and I’m considered a thought leader in my area, but this particular working format (of which I had no input on, despite being a lead) has soured me. The journey is a key element of the ultimate success, I firmly believe that. And team members are not clones of one another in that journey.

I’ve been on the PowerShell bandwagon for a while. I have a laundry list of ad-hoc scripts and some GUI tools as well that make life easier. There’s many areas I still want to dig into, that I’m aware will add tremendous value. Currently I’ve got one foot in some of the ‘old’ ways of doing things, and one foot in the future at the moment. I am working to maintain a position on the future side.

4

Hey Marty,

Great post. I blogged about it a bit.

For the short version:

Marty,

I think that you are in a tough spot, but not insurmountable.

I’d really suggest checking out Don’s video (linked above) on patterns for developing resources and use that to develop the module based resources (rather than the class based ones). This will help in the “production ready” capacity and you can transition to class based resources when you are comfortable.

If you don’t already, get a build pipeline in place so you can deliver a configuration with one resource to one machine from source control. This will be your lifeline and even if you don’t get a full server baseline by the end of the project, you should be able to get one in place shortly thereafter. Resources can be updated/tweaked/fixed and if you have a solid pipeline to deliver those changes at will, you’ll be able to move a lot faster.

I know you don’t love sprint workflow, but try to embrace it. If your standups are more than, “what I did yesterday, what I’m doing today, and what’s blocking me” - push back. Standups should be quick and informative and let you get back to work. Let the sprints help show if your (company) expectations are too high!

Hang in there Marty!

5

Steven:

Thanks for the time you spent on your reply and accompanying blog post. I was looking for perspective and this helps tremendously. Also, very timely that you mention Don’s resource design video. I JUST finished watching this earlier this week. It is a great resource (no pun intended - thank you, Don!). With regard to your blog post, I will add, we do at least have well defined OS build, so the baseline is about porting over settings into DSC, and much less about deciding what the baseline is.