There were a number of concepts presented at the PowerShell Summit last month that have been marinating in my mind for the last several weeks. Some were new and some were given that last little twist that allowed the light bulb to finally spark on. I was extra tuned into the presentations by the PowerShell team members. This was a rare opportunity, for me at least, to really hear from the horses mouth how they are using PowerShell and how they “hope” people will use the tools they are building. As active PowerShell users we all read the documentation, the blogs, and all the books from all the really smart PowerShell implementers who’ve come before us. They are all fantastic but this was kind of like getting that stock tip from an insider, “do this and your golden…”

One of the presentations was from Bruce Payette, one of the creators of PowerShell, and frankly a crazy smart guy. It was a very short 45 minutes to glean what I could. My notes would seem to indicate I ride the short bus… The theme was a DevOps cornerstone, configuration management. The demonstration was using PowerShell in a declarative way to manage that configuration. The other highlight from the PowerShell team was the half-day workshop that Kenneth Hansen and Hemant Mahawar, PowerShell program managers, provided by stepping us through an entire scenario. In the case of the workshop the activity was establishing a Hyper-V setup with VMs for domain controllers and web servers, all with PowerShell of course, no wizards, no button clicking.

One of the common concepts of these two presentations was one I was not familiar with, idempotent execution. Idempotency is the concept that something can be executed again and again with no unintended effects. In a scripting sense it accomplishes this all internally, no external state is saved as to where it may have left of or whether what it was doing last was successful. It works solely of the input its given.

A practical example would be a script whose purpose is to manage the connection string in a web.config file. Does this “super-awesome” script know if IIS and ASP.net are present before writing to a web.config? Does it know to add these roles if its missing, say from a vanilla build of your app on a fresh VM? Does this “super-awesome” script know to add this configuration if it is empty? Or does it just add it, expecting that the executor of the script would know better than to run it multiple times, thereby duplicating the configuration? What if its present does it know what the Dev values should be, as opposed to a QA or Production instance. Is this “super-awesome” script really 3 separate scripts, one for Dev, QA, and Production? Does this “super-awesome” script know that its checking for QA values, and updating them appropriately, from say a frantic manual change the new guy made who misspelled that totally clear, “corporate naming standardized” hostname? The idempotent script will do all of this and if executed again and again will keep asking and answering these questions internally and performing the necessary actions based on the environmental and structural inputs you’ve given it.

This is the genesis of configuration management and achieving idempotency. Your intent (structure and environment) are separate from your execution (logic). Multiple and varied intent may exist but logic is reusable and repeatable, without unintended consequences. Its an ideal for sure. We all get caught up doing these write it, fire it off, and live with it, PowerShell scripts. I’m certainly guilty of that. However I really see this concept as one of those differentiators within the PowerShell world. It focuses your PowerShell authoring and forces you to really understand the problem your trying to solve. Do you want to be just the PowerShell guy in your organization or do you want to be the guy whose PowerShell everyone else in the organization uses?

I’ve been working on translating a lot of the concepts that the team laid out in the PowerShell Summit workshop into something more practical for my day to day activities. I don’t spend much time coming from the VM level up. Most of my time is spent up in the application space, predominately IIS and its ilk. I build, rebuild, and fix enough busted up or base ASP.net environments that I need to move beyond knowing how to setup or fix it with PowerShell and into really managing it with PowerShell.