Why all the abstraction?
It seems like we are writing scripts just to have them turned into another format altogether, which in turn is converted into something else. Why all the indirection and abstraction? Why don't we write the final result ourselves, the first time? The primary reasons are readability and flexibility.
DSC configuration files are written in PowerShell syntax, which we already established as being consistent and readable. When the configuration is human-readable, it's understandable to the whole team and not just the implementer. It's written down in textual format, so it can be controlled in a source control system such as Git, Subversion (SVN), or Team Foundation Server. Deployment processes (sets of instructions on how to complete a task) are automatically saved and backed up by the source control system, and available to the whole team instead of one person's desktop.
Readability serves more than just the implementer and the team. Written configuration files codify the deployment process in a historical record. In that record, we can see the progression of the system by comparing the text files between releases, thereby monitoring drift and variation.
This increases flexibility by enabling a variety of tools to produce the output DSC can execute. You may have noticed that we keep referring to the compiling to MOF, that the DSC engine reads MOF, and that there is only one MOF per target host. There's a good reason that the end format is MOF and not something else like a PowerShell script.
The MOF was defined by the Distributed Management Task Force (DMTF), which is a vendor-neutral organization that works toward standardized interoperation between platforms. You may not be aware of it, but you have been using their work for quite some time if you have been using Windows Management Instrumentation (WMI). WMI is an implementation of Common Information Model (CIM), which is a DMTF standard that defines a structured way to describe a system and its properties. The Microsoft Developer Network (MSDN) site: https://msdn.microsoft.com/en-us/library/aa389234.aspx explains that WMI can use CIM on target nodes. The Wikipedia site: https://en.wikipedia.org/wiki/Common_Information_Model_(computing) goes into more information about the history and open standards of CIM.
The DMTF defined the MOF syntax and format so that any vendor or system can implement it. Microsoft happens to be the largest implementer so far, but other tooling companies use it as well. Since any vendor can implement the standard, it means several important things can happen.
If all DSC needs to function is the MOF file, you don't necessarily need PowerShell to produce the MOF file. Any third-party tool can implement the specification and provide their own (possibly improved) way of compiling MOF files. An open market for tooling gives options to the user. For example, there are many different text editors to write your scripts in; each has its benefits and compromises that you can evaluate and choose between. This enables third-party vendors to compete and provide solutions that suit a given user's needs. Companies such as Puppet and Chef can implement their own or extend what Microsoft has already done.
The most exciting thing is that since the MOF standard is platform independent, the configuration scripts you write can run on multiple operating systems. At the time of writing, Microsoft is currently completing work to support running PowerShell DSC on many Linux distributions, as announced here: https://blogs.msdn.com/b/powershell/archive/2015/05/06/powershell-dsc-for-linux-is-now-available.aspx. So, whether you run Windows or Linux or both, you can manage the configuration of your systems with PowerShell DSC using a single standard consistent syntax.
