As per the official documentation, Desired State Configuration (DSC) is a management platform in PowerShell.
It is built around different components:
Configuration keyword.The DSL is what allows us to use the Declarative Syntax within PowerShell to define the configuration policy of your systems, and compiles (or serialize) into MOF Documents. The LCM is the agent what enacts those MOF documents, whether on demand or periodically when using the Pull model.
The pull server is a glorified File server that implements the MS-DSCPM protocol to talk to the LCM. The Report server is a data collector aggregating the results of each DSC runs in its database.
The DSC resources are some sorts of interfaces enabling idempotent characteristics to scripts configuring atomic resources, or a composition of different resources. The most populars are written for the Windows LCM supporting PowerShell 5.1, but some exists for Linux and can be written in Python or pretty much any language.
DSC is a platform enabling idempotent and declarative configuration, that helps managing complexity of an infrastructure when used within a Release Pipeline.
It is best used for Policy-Driven infrastructure, where version-controlled documents describing the unique source of human intent, drive and deliver the configuration of the infrastructure components, automatically.
In essence, it’s Infrastructure from code, whatever the code is, including YAML, and whatever the automation is in the pipeline, including Chef, Puppet, a DIY DSC solution or other Configuration Management solutions.
It is those concepts—and many more—that the industry often refer to when talking about Infrastructure As Code (and the book from Kief Morris is a great read).
Since its apparition with Windows 2012 R2, DSC has been announced as a platform not a solution, but what does that mean?
DSC was created to provide the bricks you need to help create Infrastructure as Code solutions for Windows, based on PowerShell (and later, cross platform, and with other languages). It’s aimed at you, individuals and organizations building a Do-it-yourself solution, or other solutions to integrate and tap into the PowerShell and DSC community and ecosystem.
The solutions, such as Microsoft’s Azure Automation DSC now Azure State Configuration, can leverage any and all of those components, and enhance them. Others, like Puppet or Chef, might only integrate the resources and execute them from their agent.
So when you look solely at DSC and documentation, you’ll see many missing bits and pieces you would expect if you think about turn-key solutions: Visualization, Reporting, certificate management, Configuration Data management… Some of those have been solved by the community, or are available in those solutions.