[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.