Desired State Configuration in DevOps

In this step, you’re going to learn about the concept of Desired State Configuration (DSC), why DSC is required, and its benefits.

The Evolution of DSC

Windows PowerShell was understood as a scripting language to help administrators automate routine jobs. PowerShell quickly gained ground, and today most products are accompanied by a PowerShell module to enable product administration via scripts.

Scripting traditionally relies on a start state, followed by a list of instructions to achieve an end state. The biggest drawback to this approach is that when the start state changes, the scripts tend to break. For example, when you create a script to install a web application on a server, the script assumes that the server will have Internet Information Services (IIS) preinstalled. If the target server does not have IIS, the script fails. The script could fail even if a different version of IIS is installed. This makes scripts very fragile and unreliable.

What is DSC?

In Windows Server 2008 R2, Microsoft shipped an add-on to PowerShell called Desired State Configuration (DSC). DSC allows you to describe your environment’s desired state with a simple declarative syntax that has been introduced into the PowerShell language and then distributed to each target node in your environment. This solves the problem of configuration drift by either correcting it or reporting it. Without adding complicated logic to your script, you can make and deploy incremental changes to your configuration over time without fear of putting your systems in a bad state.

The Benefits of DSC

The DevOps way of working demands getting software out to end-users more frequently. Continuous delivery of software relies heavily on automated provisioning of infrastructure. While the traditional way of provisioning infrastructure with declarative scripts gives you an automated process, it significantly reduces the predictability in dealing with change.

DSC can add significant value to your release pipeline. With on-premises or infrastructure as a service (IaaS) applications, DSC is an excellent choice to help control the environment configuration and support your deployment scenarios. The benefits of DSC include:

• DSC provides idempotency, meaning that the desired state will be reached by applying the entire configuration, regardless of the current state.
• You can spin up and tear down known versions of your environments.
• You can avoid troublesome issues because of environmental differences between development and production
• You can express the application environment-specific dependencies in code and carry them along in version control.

What DSC is not

DSC is not meant to be used for every scenario. If you’re deploying Azure platform as a service (PaaS) resources, it’s recommended that you use Azure Resource Manager to get the virtual machines (VMs) started and the networking configured. This is not something that DSC is designed to do. Once the VMs are running, you can use DSC to get the local configuration the way you want it and ensure that the configuration elements you care about don’t change.