Band name jokes aside, the who DSC refers to is any target node. Why the separation and distinction? Well, as explained in the MOF earlier, we aren't dealing with just Windows servers. We could possibly be dealing with network switches, Linux servers, storage devices, and so on; the list potentially includes any device in your environment. By setting target node definitions in a structured way, we can describe the nodes in ways that make sense to anyone reading the configurations and also to the computers processing the configurations.

The DSC Domain Specific Language (DSL) defines a standardized way of describing the expected configuration of a target system, whether that is one system or several thousand systems. It describes the what of the target node.

A DSL is a specialized set of language extensions and grammar that makes it easier to codify a specific set of problems. Whereas a product like PowerShell is a general purpose language, DSLs are specifically built to address a specific set of problems.

You may wonder why we are bothering to define and discuss DSL here. You may think it's an advanced topic or something only developers need to know, but you would be wrong to discount it. DSLs are all around you and you use them every day. For example, HTML is a human readable DSL for web browsers to display content. The actual content is binary, but the HTML specification allows humans to write in a language they understand, yet also have the computer understand it.

In the case of DSC, the DSL is oriented at expressing all the different ways you can describe the expected state of a system in an easy-to-read manner. If you can read PowerShell code, then the DSC DSL is no different than reading a function declaration with a set of parameters. Most importantly, this easy-to-read structure for you is also easy for the DSC parser to read and turn into an MOF file. This abstraction of an abstraction allows you to write configurations in a language you understand and for that to be translated into a language the system understands.

For example, the target system should have a list of software installed, several settings modified, some services that should be enabled and started, some users to be created and then added to a local group, and several files to be created and have content added to them. It reads like a grocery list to you, but the computer can understand and execute it the same way every time it runs.

The DSC language extensions, Cmdlets, and resources provide a standardized way of testing whether that expected state is present on a target system.

This allows the different aspects of the actual execution of configuring a system to be codified away from the information deciding what settings to change or software to install. Whereas the what dealt with writing down the expected state, the how is concerned with how to make it that way. Or, as Captain Picard would say, how to Make it so.

This separation is important because it is expected that the list of things to do on a target computer will change, but it is not expected that how to execute that setting will change frequently. For example, there will be many types of files that you will create on many filesystems, but there are only a few ways to create those files. By separating the listing of the what, it allows the how to reduce variation by employing the idempotent DSC Resources, an important part of a DevOps workflow.

To summarize the preceding content, we can say:

We have seen the word idempotent in several places in this chapter so far, yet we haven't really defined it or covered why it is important. Let's clarify exactly what idempotence means.

Idempotence is an important concept, sometimes confusing, that we will touch on many times throughout this book. Idempotence is defined as an operation that has no additional effect if it is called more than once with the same input. Put another way, it is an operation that can be executed as many times as desired, and it will only change the system state if and only if it is not what the desired state is. For example, a PowerShell function looks for the x state and guarantees that it will only change the state of the system if it is not x.

It may seem silly to state something as obvious as this. If you feel this way, think of an MSI installer that installs version 1.1.1.0 of an imaginary software product. When you run the MSI, it only ever installs the software if it isn't already present on the system or if the version present is older than the current version. No matter how many times you execute the MSI, it will only change the system if version 1.1.1.0 is not on the system. This is idempotency. The MSI will only ever change the system state if it is not the desired state, no matter how many times you run it.

Idempontent operations are often used in network protocols or API design between dependent systems, and are used in DSC by DSC Resources. DSC Resources are required to be idempotent, in that they do not change the system if the system is in the state that the resource expects it to be in. For example, a DSC resource that operates on Windows Services will only try to start a given service if it is stopped, not if it is started. Another example is the DSC file resource, as that will change a file only if the contents do not match the expected string. By requiring idempotency, DSC Resources can be run as many times as you want, without ever performing an unexpected change.

When you install a piece of software on a machine that already has that software installed on it, you don't want there to be two copies of the software after you're done. You want the installer to be smart enough to detect the version of the currently installed software and then examine the version that you're attempting to install, and ultimately decide that the versions match and no installation needs to be done. That is idempotency in a nutshell.

At this point, you may be wondering if DSC isn't a re-implementation of Group Policy (GPO) or System Center Configuration Manager (SCCM). It's a valid question, as there are some overlaps in these technologies.

Group Policy is similar in that it is also a system of configuring operating systems, applications, and user settings in an environment. However, Group Policy is tied to Active Directory (AD) and has a lot of configuration overhead, a complex and sometimes confusing deployment methodology, and is very inflexible. This is not to say that GPO is bad; some of these apparent limitations are by design. GPO has been around since the Windows 2000 days and has had to deal with several decades of different approaches to software and server management.

In comparison, DSC is not tied to AD or a specific operating system platform. It is, by design, very flexible. As we have covered, it is designed to be responsive to the frequently changing technology and dynamic business environments we have today. Instead of obtuse schedules, DSC deployments are declarative and up front about what exactly will happen and when it will happen. GPO has rudimentary tooling that writes binary files for its configuration that can't be read by a human and can't be version controlled. DSC has human readable configuration files that are version controllable.

SCCM is also a configuration management system and is a huge piece of software that requires several servers and many hours to set up and maintain. It is not a small expense to purchase and continue to run, and it is clearly designed for a large enterprise that not only manages servers but user devices such as desktops and laptops as well. It is definitely an all-purpose tool that tries to encompass any need. Managing servers or without, comes free with PowerShell, and requires little setup time to use. While clearly designed toward server management, some desktop management scenarios are supported. It is definitely a fine-honed tool for specific purposes.