There have been a lot of questions from customers and on internal distribution list lately on Release Management, Agent-based vs vNext and how best to deploy to PaaS. So instead of answering the same questions over and over again I decided to write this post and just point them here.
There are a couple of points I want to clarify. First nothing stops you from running a DSC script via the Microsoft Deployment Agent. The agent can run any PowerShell and DSC is just a PowerShell extension and can be executed via the Microsoft Deployment Agent. Second DSC is not an “Agentless” solution.
From a Release Management perspective some people describe Desired State Configuration (DSC) as an agentless deployment. That is not a true statement. The LCM or Local Configuration Manager running on the machines is the agent. The nice thing about this is if you are targeting Windows Server 2012 R2 or Windows 8.1 the LCM is already installed and ready to go. But don’t kid yourself: it is an agent. If you are targeting older versions of Windows you have to install Windows Management Framework 4.0 before you can use DSC. Therefore, the experience of setting up an agent based or vNext (I prefer calling these DSC pipelines and will for the rest of this post) based pipeline both require the installation of an “agent” on the target machine.
Many users of Release Management see DSC as an “Upgrade” or replacement for the agent based solution. I could not disagree more. There are situations that DSC simply does not do well and others it is great for. If you really look at DSC from the Get, Set, Test perspective it limits its use. A resource that is hard coded to return false from its Test method has no business being a resource. Therefore, running test via DSC makes no sense.
As with DSC the same can be said for the agent based solution. There are some things it does great and others where it does not. Many people are running to DSC because it is new and shiny but it is not a panacea. Don’t get me wrong I am a big fan of DSC and can’t be more excited about getting it running on Linux but it is simply a tool in my tool box.
I don’t see the DevOps world as a one or the other situation. DevOps is about People, Process and Products and getting them to work and communicate better while automating your pipeline with whatever makes sense for your desired result. If it is DSC, great. If it is PowerShell, Chef, Docker or Puppet, fine. Or maybe it is a combination of all of the above.
The goal is a way to easily track, manage and automate the promotion of our code from one environment to another.
The agent based solution is alive and well. The goal of deploying to PaaS for example can be achieved today using an Agent based solution that scales much better than the DSC alternative. Let me explain why. In a previous blog post I describe a technique of using a DSC pipeline to deploy to a PaaS website. In that post I simply deploy to a single stage using an IaaS VM as a proxy to execute my DSC. Release Management today does not allow you to have the same server in multiple environments for a DSC pipeline. This means for each stage of my pipeline I would have to stand up a proxy. However, compare this to the Agent based pipeline where the same machine can appear in multiple environments. This allows you to reuse a single proxy machine to target all your stages.
I don’t feel DSC is the answer to all our problems. I feel very confident that it is not. We are not in a DSC or bust situation.
Solve your problem with the best tools you have which might not necessarily be the newest tool you have.