What are the benefits of DSC with regards to operational efforts?

DSC
1

Hi,

from a technical point of view I can grasp some benefits of using DSC. When reading “The DSC Book”, written by Don Jones and Steve Murawski, says the following:

“DSC is important – crucially important – to anyone who works with Windows servers. Even if that isn’t the only OS in your environment, DSC is massively important, because it’s going to gradually become the only means by which you manage Windows-based servers. That’s a big statement, and it deserves some explanation.”

I am working as a solution architect, which means there are questions like “How many man hours per month do we need to operate 100 Win boxes?”. From this perspective, DSC seems just like another method to get the same results we can get today. Maybe 15% more efficient.

In big IT environments there will always be some kind of GUI tool which can be operated by help desk / call center personnel, because they are cheaper than the IT admin writing the powershell scripts. These tools have to be purchased / written / maintained - if there is DSC or WMI or a C program or whatever methods below. And no 100 servers are the same - which means you still have to customize DSC for groups of servers / single servers.

I also guess that DSC will be integrated into AD and use the GPO mimic already in place - allowing blocking / merging of DSC objects.

Am I missing something here? I am really interested in a better understanding.

Do you think DSC will generate huge saving in the future (once it’s capable of using multiple DSC objects / “Resultant Set of DSC” :slight_smile:

Thanks for any ideas!

Regards,
Andreas

2

I’m not sure where you get that DSC is only 15% more efficient. Perhaps I’m not familiar with what you’re doing today.

DSC already does generate huge savings for the many companies using it; along the same lines as solutions like Chef or Puppet, and for the same reasons. DSC’s use extends beyond domain environments (which is what limits GPO). And, in v5, DSC supports partial configurations to produce a single, consolidated configuration from multiple sources.

I think part of what you may be missing is that you’re thinking of DSC as the same thing as Group Policy. It isn’t, and it doesn’t target the same workloads. There’s no such thing as a “DSC object” or “resultant set,” even when using partial configurations. That isn’t the intent. You’re getting into bigger architectural questions that are a bit difficult to go into with a forums post, though.

Youtube.com/PowerShellorg has a number of presentations you may find helpful, as does Microsoft’s Channel 9 website. In fact, I did a session at TechEd 2014 that might provide a different perspective.

Keep in mind that DSC is targeted mainly at server workloads. You don’t mention if you are thinking about servers or clients. But the point of DSC is to create a human-readable (big deal) document that describes a server’s configuration, and which forces the server to remain in that state (big deal), but which has no requirements for Active Directory (big deal), and which is cross-platform (big deal) so you can start to standardize on a single technology.

DSC isn’t attempting to do anything about your day-to-day management GUIs for the help desk. It has nothing to do with those, and would not be underneath them.

DSC still supports logic (e.g., scripts), so it can make decisions about the configuration to produce for a given server. There are a huge number of approaches you could use to produce per-server configurations, the differences being more in how each approach accommodates different organizational processes and preferences.

I think maybe you’re still just scratching the surface of the technology. Not that it’s perfect or the solution to every problem, but I think there’s a lot more than you might realize right now.

3

Hi Don,

to give you some information on my background: I work for a large European IT outsourcing company operating thousands of servers for small to large companies. When it comes to server setup there are automated tools in place which produce the desired output, e.g. a W2012 server with all the backup, anti-virus, multipath, inventory, patch management software installed and configured. I see that DSC could be part of this automated setup procedure. But will it generate huge saving? Not sure.

Today we pay license costs for the automation, in contrast using DSC we would have to pay some programmers to create and maintain DSC scripts. And interfaces to existing Change Management / Ticketing Tools would need to be created as well.

When it comes to “desired state”, we don’t have an exact match. Software distribution makes sure server get the same configuration. ITIL processes make sure that systems aren’t re-configured without a change. But nothing that’s self-configuring. And of course, a person with admin right could re-configure a server without a change.

Example: Let’s imagine we operate 200 servers spread across Europe for a single customer, and there would be a DSC infrastructure in place. Whenever somebody wants to add a feature / a function to a server, ITIL Change Management needs to be invoked. A formal process is started to evaluate risks, costs and approvals are requested. Once approved somebody will do the click-click-restart action and we are done.

In this scenario, DSC would “only” help at the last step, right? A “DSC admin” would need to be part of the change process, because the central “Desired State” file for this server needs to be changed, sent to the server during the change implementation and somebody needs to verify functionality. As 200 servers might change frequently, the DSC admins needs to be part of most changes.

Regards,
Andreas

4

[blockquote]When it comes to server setup there are automated tools in place which produce the desired output, e.g. a W2012 server with all the backup, anti-virus, multipath, inventory, patch management software installed and configured. I see that DSC could be part of this automated setup procedure. But will it generate huge saving? Not sure.[/blockquote]

I don’t think anybody’s positioned DSC as “generating huge savings” over any given existing toolset that accomplishes a similar task. The savings is in having automation in the first place. However, I’ll point out that DSC is not just about generating the initial output, nor is it an inventory tool, nor is it a patch management tool. DSC is about producing a desired configuration, and then ensuring that configuration stays in place over time. If the desired configuration changes, DSC makes it easier to implement that across a large number of servers. DSC doesn’t necessarily require you to write your own code or scripts to do these things, which can be a time savings.

[blockquote]Today we pay license costs for the automation, in contrast using DSC we would have to pay some programmers to create and maintain DSC scripts. And interfaces to existing Change Management / Ticketing Tools would need to be created as well.[/blockquote]

Yes, obviously you have to do whatever level of integration you desire with your existing tools. That would be the case in any scenario. I would disagree about paying programmers to create and maintain DSC scripts. I think you may misunderstand what DSC is and how it works; depending on what you want to configure, exactly, there might well be no “scripting.” Yes, you might have to code some custom resources - but I’d argue that if you needed to hire programmers for that, then your administrators are under-skilled for today’s business environment. DSC should be a DevOps function, not a dedicated programming effort.

[blockquote]Example: Let’s imagine we operate 200 servers spread across Europe for a single customer, and there would be a DSC infrastructure in place. Whenever somebody wants to add a feature / a function to a server, ITIL Change Management needs to be invoked. A formal process is started to evaluate risks, costs and approvals are requested. Once approved somebody will do the click-click-restart action and we are done.[/blockquote]

Yes, all of your change management processes would be the same, because those are processes, not technologies. I don’t know what a click-click-restart action is. If you already have tooling that lets you implement and maintain changes by clicking stuff, then you should just use that tooling.

[blockquote]In this scenario, DSC would “only” help at the last step, right? A “DSC admin” would need to be part of the change process, because the central “Desired State” file for this server needs to be changed, sent to the server during the change implementation and somebody needs to verify functionality. As 200 servers might change frequently, the DSC admins needs to be part of most changes.[/blockquote]

Well yes, with the understanding that the last step is usually difficult. For example, absent any tooling, it usually involves constructing custom scripts, which are often complex because they need to first query the existing state of a machine before attempting to change it. DSC shortcuts all that by integrating the Get/Test/Set logic and abstracting those functions into reusable modules that can be provided by vendors rather than custom-coded.

And yes, whoever “owns” the DSC configurations would be the implementation portion of your change management process. Although the architecture of DSC makes it especially easy to move through dev/test/production cycles. You create the proposed config, you deploy it to a test environment, and you verify it. Once verified, you deploy it as-is to the production environment, and you’re pretty assured of an identical result in production. In many ways, DSC lends itself better to formal change management processes than ad-hoc scripting.

I feel a bit like you’re asking me to justify DSC against your current methodologies, which I obviously can’t do, since I know so little about your company. And I’m not a consultant, so I honestly don’t need to know. All I can do is try and outline what DSC does. DSC wasn’t meant to solve YOUR problems per se; it was meant to solve a common set of problems in the industry. It does a good (and getting better job) of achieving its goals. That doesn’t necessarily mean your goals are identical.