The Argument for DSC
Desired State Configuration is Microsoft's technology, introduced in Windows Management Framework 4.0, for declarative configuration of systems. At the risk of oversimplifying a bit, DSC lets you create specially formatted text files that describe how a system should be configured. You then deploy those files to the actual systems, and they magically configure themselves as directed. At the top level, DSC isn't programming - it's just listing how you want a system to look.
Microsoft is actually a little late to the game on declarative configuration game. The Linux and Unix world has had tools like Chef and Puppet, which at their very core perform a similar task, for a long time. What's important is that DSC isn't an add-on, it's a core part of the Windows OS, now. And while the toolset for DSC isn't yet as mature as tools like Chef and Puppet, DSC provides an inbuilt foundation that, in its v1 implementation, is incredibly robust and extensible.
DSC is the last major piece of functionality outlined in PowerShell inventor Jeffrey Snover's Monad Manifesto, a document in which he envisioned PowerShell itself, PowerShell Remoting, and a declarative configuration model. The implementation of that Manifesto has been happening since 2006, when PowerShell v1 was released to the public. For the most part (as you'll read in this guide), that implementation has been done in a way that's extremely cross-platform friendly. PowerShell Remoting, and even DSC, are based on open, third-party standards. With that standardized foundation, Microsoft can let other folks focus on tooling, knowing that those tools don't have to be Windows-dedicated since other operating systems can utilize these same technologies.
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. That's a big statement, and it deserves some explanation.
|By the way, nothing in the following should be construed as an argument about Windows being better/same/worse as compared to any other OS. This is a discussion about Windows, in and of itself, without any of that being a value judgement or comparison.|
The Evolution of Administration
In its beginning, Windows was administered mostly by graphical tools, and a few command-line ones, communicating directly with services on local or remote computers. You clicked a button in a dialog box, and the tool would talk to the Security Accounts Manager (SAM) and create a user account.
As environments grew large and IT teams smaller, folks needed to automate many of those processes. Graphical tools are inherently difficult to automate; the first phase in Snover's Monad Manifesto was a command-line shell that provided a consistent command-line language for automating administration. Command-line tools are inherently easy to automate, because they can be sequenced in simple batch or script files. A consistent and all-encompassing command-line language was something Windows had never had; management pressures within Microsoft were brought to bear to make PowerShell as all-encompassing as possible (an investment still underway). Guidelines were put into place to make it as consistent as possible (with largely positive results).
It's important to note that commands continued to communicate directly with services. Run New-ADUser , for example, and the command communicates directly with a service running on a domain controller to create the new user.
Scale-out was the next phase of the Manifesto. A command-line automation language is fine, but if you have to run around typing commands on individual computers, you still have an upper limit on efficiency. The ability to push commands to remote computers, in parallel, over a standardized communication protocol, was needed. PowerShell v2 delivered that in its Remoting feature. Now, one computer could easily tell a thousand others what to do, more or less at once. Remoting also reduced some of the burden on command developers. They could now assume that their commands always ran locally, on whatever computer was running their technology, and let PowerShell handle network communications. Not having to deal with communications made it significantly easier for command developers to pump out more commands, increasing PowerShell's technological "coverage."
But to this point, administrators still ran commands, and commands talked to services. Everything was very imperative: computers did what admins told them to do, more or less right then. If the environment changed, admins had to construct new scripts to implement the new changes. Admins then had to go back and make sure the changes had been implemented correctly, and continually re-check to make sure things stayed that way. If something got mis-configured, the fix was often a fallback to manual reconfiguration. You couldn't just run the same script, since it was designed to take a system from Point A to Point B, not from Point-A-Except-For-This-One-Thing to Point B.
DSC represents a significant break in administration, because it asks administrators to no longer communicate directly with services on computers. That means no graphical tools that talk directly to a service. It also means no running commands that talk directly to services. In other words, DSC asks administrators to not actually configure anything themselves.
Instead, DSC asks administrators to describe, in fairly simple text files, how they would like a computer to be configured. The computer, in turn, reads that text file, and configures itself accordingly. The configuration process is granular, so that if one item gets mis-configured, the computer can still bring itself "into compliance" by fixing that one thing.
DSC couldn't have existed without PowerShell, because PowerShell is what gives DSC the ability to implement changes. PowerShell is the one common language that all Microsoft products speak (to some degree or another, with constant improvement). In other words, without PowerShell, Microsoft products wouldn't have consistent enough automation capabilities for DSC to exist. Now that DSC does exist, administrators can actually focus less on PowerShell, because they'll be separated from it by a couple of less-complex layers.
Imagine a graphical tool where you click through a wizard to add a new user to your environment. Only that tool doesn't actually talk to a domain controller to create the user account, nor does it talk to a file server to create their home directory. Instead, the tool merely modifies a couple of text files that contain the configuration for a cluster of file servers, and for your domain. The file servers and domain controllers periodically re-read those files, and implement whatever they say. So, you click a button, and a few minutes later the user, and their home directory, magically exists. It's automated, but you didn't need to do any programming. The configuration files are where you, as an administrator, make your changes.
Growing the environment becomes simpler. "Hey, you are going to be a new domain controller. Go look at configuration file DCX34766578348 and make yourself look like what it says." Poof, done.
DSC represents a massive change in how Windows administrators think about their entire environment. Provided every configuration setting can be boiled down to a DSC setting - which will be true over time - then "administration" will essentially become "intelligent editing of text files." Pretty powerful stuff.