Greetings,
I havent really been in a situation where I can push a greenfields DSC till now.
However, I need some selling help.
The conversation always goes something like this:
“DSC is great for configuring things” -Reply - I can do that with GPOs.
“DSC can ensure things are installed” - Reply - I can do that with SCCM.
I would love a summary of what DSC better than existing technologies and more importantly how and why.
Thanks
David Z
DSC works without taking a dependency on either Active Directory or SCCM, which can make it more appealing for cloud scenarios where you’re spinning up and tearing down lots of short-lived compute instances.
DSC also has none of the limitations of Group Policy. If you can write a script to do something in PowerShell (which covers basically anything you can do to a Windows computer, period), you can wrap that script in a DSC resource.
DSC integrates with existing configuration management solutions, such as Chef, Puppet and Ansible. (This is more of a v5 statement, though; v4 integration with Chef is less friendly.)
So, all of that said, if you already have a Windows-only shop where you have heavy investments in GP / SCCM, and all of your servers are joined to an AD domain, you may as well keep using your existing technology. There’s not a huge benefit to switching over to DSC unless you intend to move toward one of the other scenarios, such as the ability to configure machines that aren’t joined to a domain.
Have you read the comparison in The DSC Book?
I’m currently implementing DSC as part of an SMA engagement, where I am building a VM provisioning scenario.
Even though they have all servers managed by ConfigMgr, using DSC is more ‘real-time’ and easier to report on.
Workflow goes like this:
SMA provisions VM - SMA builds the DSC depending on what variables it was given - DSC customises VM - SMA continues to do stuff - SMA notifies user of having completed.
This would be hard to do with just ConfigMgr.
I’m keen to use it but I don’t see many people taking it up given the existing alternatives.
This is indeed a big statement from the DSC book -
“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.”
I don’t agree. I’m still working at places full of Windows XP and Server 2003 - Lifecycles are huge due to the investment of versioning up.
Same goes with peoples investment in Group Policy and SCCM. Microsoft won’t take any of that away for decades.
It is likely that Windows Server 2016 will include the “Nano” install that won’t even allow you to RDP into it. But you will still be able to apply Group policy and install the SCCM and other agents.
I think the only thing you can say about DSC is that “It will be possible to configure everything via DSC”. But all other options will still be on the table IMHO.
Cheers
David
DSC is platform where different configurations tools will able to use DSC in order to configure servers and will take full advantage of WMI and PowerShell. If you are still running WMF 2.0 and WMF 3.0 for because of application dependency is not worth for your company to look in DSC. I will only look into if at least you are running WMF 4.0 and started looking in WMF 5.0, a lot of the cool stuff are being develop in WMF 5.0
I am not saying not look into DSC, start playing with the technology in a lab because as PowerShell, DSC is just to keep growing over time. If you want to convince your management come up with a 3 year plan that aligns with Microsoft strategy “Cloud First”. For example CHEF, Azure Automation, Azure Stack will use DSC.
I really am a powershell evangelist and have played with DSC but implementation is difficult as it doesnt have those killer selling points - yet.
I have worked for very large companies that have absolutely no long term interest in the “cloud”. They are developing their own internal cloud.
DSC configuration and text and can be stored in version control.
SCCM stores configuration in a database, there is no version control.
I expect newer version of system center will leverage DSC.
Go to the application owners who are strategic to the business and ask how you can enable them to move faster using the internal cloud solution. Looking strictly at tools, if they are presented with either using tools designed for operations or configuration as code, they will usually go with the tools that are most closely aligned with what they already know.
Question back to you - what would those killer selling points be?
Go to the application owners who are strategic to the business and ask how you can enable them to move faster using the internal cloud solution. Looking strictly at tools, if they are presented with either using tools designed for operations or configuration as code, they will usually go with the tools that are most closely aligned with what they already know.Question back to you – what would those killer selling points be?
We don’t have an internal cloud solution. There wont be one for years. Im afraid I dont understand your question.
Further up you stated “and have played with DSC but implementation is difficult as it doesnt have those killer selling points – yet.” I’m just asking what selling points you need? If you had a wish list, what would be on it?
The replies are always along the lines of “what does dsc give us that we dont have already?” dsc configures stuff - so does group policy, dsc makes sure stuff is installed - we have sccm for that.
The selling points would be detailed practical statements about what it does that nothing else does or why it does it much better or simpler.
It may be a resource by resource thing.
For example, Group policy is extremely simple for setting registry settings. Its easy to do and the flexibility of targeting is enormous.
So, in my mind, the registry “resource” in DSC cannot compete with Group Policy.
So maybe DSC has a niche in certain resources that it does better than anything else on offer. Which means its just another tool that sits beside, but will never replace, group policy/SCCM etc.
Cheers
David Z
The tools are designed around facilitating two very different processes. You could change tools and not process, but as you’ve stated the benefit would be limited.
Sounds like a blog post in the making. 
IMHO you should not start ‘selling’ DSC, unless you fully understand what it is and how it works.
To be clear, I’m still in the process of learning this technology. And until I can implement it with my eyes closed, I would not try to ‘evangelize’ it to customers.
That said, I would like to reference to what Jeffrey wrote in his famous PowerShell Manifesto:
[ul][blockquote]The traditional approach to management models produces an inconsistent admin experience.[/blockquote]
This quote is interpreted by me like: “In every environment there is possible a jungle of management tools, all with a specific purpose”.
DSC provides you a way to move towards a homogeneous management framework, which can take away the complexity of using a myriad of tools like SCCM, GPO’s, RES Automation Manager, VMware Orchestrator, NetApp Workflow Automation, etc. I’m quite sure that most company’s use either one or a combination of these tools. DSC provides in my opinion a valid alternative to these tools. Of course, you have a learning curve first, but was that different with the other tools available in the company?[/ul]
[ul][blockquote]Monad takes a different approach: it minimizes the cost of automation and provides immediate end-user benefit by providing scenario-based automation extension classes and in-the-box tools that exploit those classes. Monad can support almost any automation schema but strongly encourages the use of standard schemas by providing a set of base classes for specific administrative scenarios. Those base classes include: Navigation, Diagnostics, Configuration, Lifecycle, and Operations.[/blockquote]
Jeffrey is talking here about in-the-box tools which enables you scenario-based automation. This is a strong value proposition. You don’t have to buy extra tools, software, licenses, because it’s already available in the box. As part of Satya’s strategy, he is saying to his engineers that they should provide the tools to their customers to make them as successful as possible. And the PowerShell team is exactly doing that; they provides us with DSC, which allows businesses to automate scenarios in the fields of Release Management, Deployment Management, Configuration Management and Operations Management. And all of this trough a consistent language, which is inherently growing in functionality. And this functionality is only limited to the fantasy of the PowerShell team, the community and YOU.[/ul]
Furthermore, Thomas Limoncelli wrote some nice stuff about Automation in his book: “System Administration - The Practice of System and Network Administration”
[ul]One of the six Basic Principals is Automation:
[blockquote]Automation means using software to replace human effort. Automation is critical. Automation improves repeatability and scalability, is key to easing the system administration burden, and eliminates tedious repetitive tasks, giving SAs more time to improve services.[/blockquote]
DSC is delivering automation to you in the form of a Desired State. This Desired State is automating the well-known, predictable and stable computer system which makes your SAs and customers happy. You are able to set-and-forget the configuration of a system trough DSC, and therefore concentrate on improving stuff for your customers. The built-in component of DSC in Windows Server is providing you exactly this, the Make It So Engine [ooops… I mean the Local Configuration Manager [LCM], thanks Jeffrey :] ].[/ul]
[ul]In the book is a mention of “First-Class Citizens”, which are the platforms that receive full support. This means training for the platform to be able to provisioning and support these platforms. Most customers I encounter have either Windows or a specific taste of Linux. Instead of having training for both platforms, you can leverage DSC to provisioning these two big platforms. DSC is also able to put a Linux system in a desired state.[/ul]
And for some more obvious reasons:
[ul]DSC saves you money. Because DSC enables you to automate processes, and this saves time. But is is a general automation truth.[/ul]
[ul]DSC prevents you to make mistakes. Because of the thinking process involved into developing DSC documents, you are forced to come up with a flawless installation/configuration, which can used repeatably. [/ul]
[ul]But also because DSC uses a declarative format, and not an imperative format, you are able to say WHAT has to happen, not HOW. This prevents to put in wrong parameters with wrong values.[/ul]
I could go on with more arguments, but the key point is that DSC is here to stay, and become big.
To put it in a metaphor: You have a Ferrari, but not yet the highways. There are few highways on where you can drive, and in the future only more highways will be constructed.
And as a last advice, If you try to ‘sell’ DSC, don’t use words only. Show to a customer what you can achieve with an, for example, installation of SQL on a Windows Server using DSC. And tell how much time this saves, and put a calculation about money with it.
I think you can construct a nice pitch talk from all the comments in this thread, and let us know please!
Automation saves money - And I can achieve a great deal of automation without DSC and without learning anything new.
Don’t get me wrong, I too love powershell, but am still to be convinced that DSC is worth the time and effort to work out how to do what most people know how to do really easily with existing tools.
I will continue to play with DSC and hopefully try and use some of its bits as a way in.
Cheers
David Z
David, is this a statement your personally support, or are you quoting resistant people? [blockquote]And I can achieve a great deal of automation without DSC and without learning anything new.[/blockquote]
My reply is to either you or those resistant people then
I quote Jeffrey Snover again: [blockquote]As IT PROFESSIONALS, we are being paid to be PROFESSIONAL.[/blockquote]
That means to me, that we are being paid to deliver the best value to the business. If you say you can achieve a great deal of automation without DSC -to the business-, then I fully support this opinion.
This is because we all did some form of automation all these years, without DSC. DSC is the new kid on the block, and we have to see how it competes with the other tools available.
But if you say that you can achieve automation without learning anything new -to the business-, then I strongly disagree with you.
Yes, maybe you can achieve automation NOW, but looking at how fast technology advances, this statement does not keep up in, let’s say, 6 months from now. And then you will bang your head into the wall because you didn’t learned to use DSC.
I already said it, all these tools we are using, we had to learn. DSC is not different. But in my opinion, DSC is one of those disrupting technologies, like PowerShell is. In the beginning of Monad (MSH), most people I knew were reluctant towards it. Now these are the guys and gals behind the frontrunners. They deliver the same value to their business as before, and not MORE.
So if you really need to have a pitcher for DSC, I would say this:
[blockquote]DSC delivers more value to the business because of the constant development of the technology. And because of this development, DSC is and will be fully supported with all products Microsoft is producing. And because of this, DSC will speed up integration of new functionality into the business.[/blockquote]
I think I have a chance to have a real go at DSC. The place I’m at is going to migrate to Windows Server 2012 and they wanted a “security hardened” image deployed using SCCM OSD and traditional group policy.
I think we could do a vanilla server 2012 install with all the roles/features and security settings done via DSC. Is this possible?
Thanks
David Z