I watched a video on ITPro.tv about PowerShell Desired State Configuration DSC. They introduce it, and effectively run a script. However, this was their first (real) introduction of scripting too, so I didn't pick up the difference between DSC and regular scripting. I've done some regular scripting before, and maybe they just didn't have that great of an example; it seemed like a regular script could install a role/feature and copy some files just fine. I didn't see the benefit to DSC compared to just a script. Aside from a machine being able to poll for some kind of changes, which they didn't cover in practice, just in theory.
What are the benefit(s) of DSC over traditional scripts; for example "install role, copy file"?
- With PowerShell, you can connect to remote machines and tell them to do stuff, so that's not exclusive to DSC.
- With DSC it seems like you're doing some sort of compilation to make a mof file, and then you run it from the shell after the script, which seems like an unnecessary step.
- The MSDN overview reads like an overview of PowerShell, and I don't see the differentiating characteristics.
Best Answer
As you have said, you can do pretty much everything you would do with DSC, with straight powershell code.
But, DSC is all about configuration management.
Configuration management is about patterns and practices of using code and various systems to ensure a system is in a specific state. Ref 1 2
One important thing about Configuration management is idempotence. Meaning the code describing your system in the configuration management system will be checked and ran against your system periodically. Lots of basic scripts are not well designed, and will do the correct thing the first time you use it to configure a system, but the next time they will error, duplicate things and so on. Configuration management systems ideally will abstract away a large portion of the testing and state checking code you have to manually add in a script, to make your script idempotent.
Another important thing about DSC and many other configuration management systems is about making re-usable resources that actually do the work that can be shared with anyone and everyone in the world. In this way your actually 'configuration' should be just the few specific details that are specific to your environment. This also means you should need to write a lot less code, since you can re-use things that has been used and vetted by many other people.
I have included a few links above, but there are many good web sites you can find on the Internet about the theory of configuration management systems. The general theory applies to all configuration management systems (puppet, chef, dsc, ansible, etc) it is certainly worth learning, and worth using in most environments.