It’s All About the DSL (no not that DSL)

Three things to start this post off:

  1. Read my previous post, Hey you got some configuration in my execution
  2. Watch the preview by Kenneth Hansen and Jeffery Snover of the new “Desired State Configuration” in PowerShell v4
  3. Plan to attend PowerShell Summit 2014 (seriously!)

When I wrote that post last week I had heard that there was a “not to be missed presentation” by Jeffery Snover at TechEd this week. I was sort of putting my good thoughts and wishes out into the universe and hoping that something good came back. Well it did in a big way. What struck me the most as I was watching the presentation was just how identical it was to the presentations by Kenneth Hansen and the team at the PowerShell Summit. We literally got the scoop back in April, they did it back then with some language tricks and a bunch of custom advanced functions but the gist was the same. Only now it is baked in and much more extensible.

Below is one of the slides that they presented to us at the Summit. With the exception of the code on the right (and the mugs of Picard and Riker), its fundamentally the same as the one displayed at Monday’s preview. I think this slide also conveys well the heart of configuration management and also the thought process of Microsoft going forward with regards to PowerShell and systems.

MakeItSo_SlideMy hope after the Summit was for Cmdlets to help build and manage the Intent aspects of this diagram. What we ended up with was so much, much more than that. My understanding at least after watching the demo is that the the Intent aspects above will be managed by a PowerShell based Domain Specific Language (DSL). Domain specific languages are a computer science concept where a language is designed to solve a specific problem. As apposed to a general language that could solve any number of problems. A DSL could use the languages existing constructs to solve the problem or you might create a DSL other languages could independently parse and interpret. For example you would use C# to write a video game or host a web service, however you use SQL (a common example of a DSL) to query data, but would not use it to write a video game.

With the new Desired State Configuration (DSC) the team has built a domain specific language using PowerShell function declarations and hash-tables. In this case rather than using these common PowerShell constructs to build logic (foreach, get-, set-, if/then, etc.) your using those language constructs to represent your intent (in this case for environmental and structural configuration). Same PowerShell language but with distinct purposes and use cases.

Interestingly that intent “code” is stored in .psd1 files (PowerShell Data) files. As a point of interest if you have done any advanced function  and  module development in PowerShell you’ve likely built or generated module manifests. Module manifest files in PowerShell also use the .psd1 extension and are actually stored hash-tables. These exist today as a declarative configuration of a modules environment. So it looks like PowerShell is getting some new more visible declarative configurations, and the .psd1 file is the home for these. Another subtle, if clear, delineation of Intent and “Make It So”/Automation.

I’m still fuzzy on some of the implementation details but the PowerShell stuff works in conjunction with new functionality inside WMI (aka Microsoft’s implementation of CIM, the Common Information Model) as all the configurations get generated intermediately into MOF (Managed Object Files). In turn DSC providers (also written in PowerShell) do the “Make It So” (idempotent automation) aspects of  the endeavor.

PowerShell has become unequivocally and uniquely intertwined with the administration of Windows. In all my years with Windows I’ve never seen a single  technology permeate so thoroughly every single Microsoft product; Windows, SQL Server, Exchange, SharePoint, and Azure. An Azure engineer was on hand to demonstrate Azures use of DSC in VM deployment. Additionally an engineer from OpsCode, the developers of Chef (a Linux based/centric configuration management tool), demonstrated an implementation of Chef using the MS built DSC. I am very interested to see over the next few product cycles how the various Microsoft product teams use this, as well as all the 3rd party software and systems providers out there.

At the start of the preview Jeffery Snover itemizes all the points expressed, and implemented, from the Monad Manifesto he authored over a decade ago at Microsoft and was released publicly several years ago. Its stunning to see how successful PowerShell has truly been. I know of many Windows admins who are in denial of PowerShell’s relevance and its worth in their administrative responsibilities. With a successful DSC implementation PowerShell will cement its absolutely ubiquitous presence within all Microsoft products and services, and many external products that integrate or utilize those services. I’m speaking to the choir but its a great time to be a PowerShell knowledge worker.

Advertisement

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s