DevOps, Infrastructure as Code, and PowerShell DSC: The Introduction

Posts in this series
  1. DevOps, Infrastructure as Code, and PowerShell DSC: The Introduction

DevOps is the new cool thing (at least in the Windows world) everyone is talking about and the IT professionals (some of us at least) just give a blank stare every time the DevOps discussion comes up. We feel completely out of place. IT professionals are a part of the DevOps practices and not outside of it. With the rise of web-scale infrastructures, it is important for IT organizations to be more agile and efficient to support the ever growing need for flexible infrastructures than a normal IT professional would have ever imagined. This article series intends to shed some light on DevOps and what it really means for the IT professionals like you and me, and finally explains how and where PowerShell Desired State Configuration plays a role. Let us start with the most trusted definition of DevOps:

DevOps (a clipped compound of “development” and “operations”) is a culture, movement or practice that emphasizes the collaboration and communication of both software developers and other information-technology (IT) professionals while automating the process of software delivery and infrastructure changes. It aims at establishing a culture and environment where building, testing, and releasing software, can happen rapidly, frequently, and more reliably.

Let us keep the collaboration and communication part of this definition out of our discussion here. It is more of a soft-skill and a practice that should be nurtured between the development and operations teams. There are even tools that enforce this communication and collaboration. Let us focus on later parts the DevOps definition that is about automating the process of software delivery and infrastructure changes and building, testing, and releasing software rapidly, frequently, and more reliably.

A picture is worth a thousand words. So, here is the technical part of the DevOps definition in a picture!


What this picture depicts is the typical application code flow from development to production. The phases such as continuous integration and continuous delivery ensure that the developed application code is tested and is stable for deployment in production. The tests that run at these phases provide an assurance that the code will run as expected in all sorts of environments (Development, QA, Staging, and Production) where the code gets deployed. One thing you must note here is that for the application code to run as expected in any of the environments, you must have the same or similar infrastructure configuration. For example, when you start making changes to the application code, the development infrastructure where you perform unit testing of your code must mimic production infrastructure. If the application code in development requires infrastructure configuration changes, these configuration changes must move, along with the application code, from development to other environments as the code gets tested and deployed.

While delivering and deploying the application code in a rapid and efficient manner is important, it is equally important to ensure that the infrastructure where this code gets deployed is dealt the same way we deal with the application code. For reusable, consistent, and rapid deployments of infrastructure, you need automation. When you have automation, you always want to validate what you are doing because there are no humans sitting and watching the deployment as it happens or to click buttons to complete the deployment. And, finally, when something goes wrong, you want to quickly see what changed in your infrastructure automation and rollback those changes when needed.

This is where infrastructure as code comes into picture!

Infrastructure as Code

It is easy to argue that what I just described is infrastructure automation which you and I as IT professionals have been doing for ages. Right? One thing you must notice here is that infrastructure as code is not just about code alone. Infrastructure automation does play a role within infrastructure as code. After all, how else do we create reusable and repeatable infrastructure without automation. Infrastructure as code mandates software development practices in managing IT infrastructure.


The three major components of infrastructure as code are:

  • Version Control – Enables the method track and rollback changes to your infrastructure as needed. There are many tools that you can use here. My favorite has been Git. If you are new to version control and want to get started, take a look at my Git for IT Professionals
  • Unit/Integration Testing – Enables validation of your infrastructure code within various phases of DevOps pipeline and lets you feel confident about what you are pushing to production. Pester can be used here. We have great series on getting started with Pester.
  • Infrastructure Blueprints – Enable consistent, reusable, and rapid deployment part of infrastructure as code. Configuration as Code is one of the ways to create infrastructure blueprints but not the only option. Tools like Puppet, Chef, and a platform like PowerShell DSC enable Configuration as Code. These configuration management tools or platforms basically enable declarative way of handling infrastructure configuration. Infrastructure blueprints should always go hand-in-hand with unit/integration testing. We will see more about this in a later post.

Since the first two parts of infrastructure as code are already discussed in other article series here on PowerShell Magazine, I will only focus on infrastructure blueprints that enable consistent, reusable, and rapid deployment and what role PowerShell DSC plays in this space. When I say consistent, I don’t mean that the host names and IP addresses should be the same. Rather, the configuration aspects that impact the application behavior should be the same. This can only be achieved if there is a reusable method to repeatedly deploy this infrastructure in any environment – be it Development, QA, Staging, or Production. You need the ability to separate your environmental configuration from the resource configuration to be able to create a reusable deployment method that works across different environments. For example, the IP addresses and hostnames will be different within each environment. The number of frontend VMs that you would run in a staging environment would be different than the number of VMs in production. Once this level of separation is available, you can create a single blueprint for your infrastructure and then reuse it in any environment just by specifying the right environmental configuration. This is where Puppet, Chef, PowerShell DSC, and other configuration management solutions play a role.

PowerShell DSC

First of all, understand that PowerShell DSC is not Infrastructure as Code. It is one of the enablers of infrastructure as code. I mentioned configuration as code and that is where PowerShell DSC comes into play. It enables a declarative way of expressing your infrastructure configuration. Using this declarative syntax, you can create what I referred to as infrastructure blueprints in the previous section. PowerShell DSC supports separation of environmental configuration from structural or resource configuration. You can use the configuration data in your DSC documents to make your infrastructure blueprints reusable. To ensure that your infrastructure blueprints can be deployed in a repeatable and reliable manner, you need unit and integration tests once the deployment is complete. You can use Pester for this purpose. We shall look at using PowerShell DSC as a part of infrastructure as code in-depth in later parts of this series.

In summary, as an IT professional, it is important for you to know what DevOps brings to enterprise data centers and the difference between infrastructure automation and infrastructure as code. This means you transform yourself from an Infrastructure Professional to an Infrastructure Developer.

Filed in: Articles, DevOps, Online Only Tags: , ,

17 Responses to "DevOps, Infrastructure as Code, and PowerShell DSC: The Introduction"

  1. Karl Harnagy says:

    Awesome article! Infrastructure as Code has been very popular on Linux for awhile but I’m very excited to see more people interested in it on Windows. I’ve been working a lot with Otter (http://inedo.com/otter) which has a lot of cool integration with PowerShell and DSC — http://inedo.com/support/documentation/otter/modeling-infrastructure/powershell I’ve been doing a bunch of awesome proof-of-concept and demos lately. I really think this is the future on Windows.

    *Note my day job is at inedo so I might be a tab bit bias 😉

    • Ravikanth C says:

      Hey Karl, thanks for introducing Otter. Looks interesting. Does it already support full DSC and all custom resources? Would love to see a full demo of this.

      • Karl Harnagy says:

        Thanks Ravikanth!

        Yes — and actually, DSC resources and Otter’s Ensure Operations are quite similar conceptually. For example, xAppPool and “Ensure Application Pool” [1] do mostly the same thing, except the Otter operation has all of the options/settings available, and you can visually edit it in the web UI.

        But, if you already have custom or existing DSC resources you want to use, then you can just use the “PSDsc Operation”[2], which will execute them much like DSC runtime does (test if it’s configured, execute if it’s not).

        I’d be happy to show you Otter; you may want to look at the quick tutorial, just to see the main ideas (http://inedo.com/otter/tutorial).

        You can almost think of Otter as sort of the “management hub” for the infrastructure you want to manage as code, since it’s also reporting on drift, scheduling jobs, and those sorts of things, using the same infrastructure “code”.

        One of the goals with Otter is to help bring “infrastructure as code” to folks who don’t want to have to become masters at Ruby, etc., and who like visualization of status and configuration that they can share with their less-technical managers/team, who may not want to jump on the command line to just to query things.

        [1] http://inedo.com/support/documentation/otter/reference/operations/iis/ensure-app-pool
        [2] http://inedo.com/support/documentation/otter/reference/operations/powershell/psdsc
        [3] http://inedo.com/otter/tutorial

  2. Timor Kalerman says:

    Hi, just wanted to mention that I am already using a DevOps model which consist from the Release Management 2015 as the Continues Deployment server, the Microsoft TFS as the version control server, the MongoDB as the Configuration management server, and the Powershell DSC as the engine to deploy.
    I think this solution is the most Microsoft’s best way to user DevOps for now (except for the MongoDB – because Microsoft doesn’t support NoSQL DB server yet..).

    • Tamir Amram says:

      Hi Timor,
      Can you elaborate about your use of MongoDB as Configuration Management?
      It will be great if we can talk to share some thoughts and ideas 🙂


      • Timor Kalerman says:

        Yes of course.
        I am using MongoDB as my Non-SQL database for storing JSON like configurations that I defined like (Application Settings, Executable Settings, Service/Website Settings, Versions and so on). I use the JSON type of data because it is easier for me to store the configurations that way instead of using the regular SQL (Table structure way) and also it is easier to convert it to the DSC Configuration file that I use later for deployment.

        Then I wrote a PS script which uses a c# driver to get and convert the MongoDB document that I need to a Configuration Text file that I can supply to my DSC MOFs builder command, and then I start a Push deployment using the Start-DSCConfiguration.
        You can find me on LinkedIn if you would like some more explanations.

  3. Oh my goodness! Incredible article dude! Many thanks. 

  4. Robert Burke says:

    Outstanding article Ravikanth, thank you

  5. Thanks for sharing this article you have a good command on DevOps and Powershell. I follow this blog for the future posts.

  6. good thing about your post is that you put a lot of effort for explaination,it was a excellent post.

Leave a Reply

Submit Comment

© 2018 PowerShell Magazine. All rights reserved. XHTML / CSS Valid.
Proudly designed by Theme Junkie.
%d bloggers like this: