Linux dominates cloud computing. While explanations for this abound–everything from licensing to operating-system design has been cited–the bare fact is uncontroversial. PowerShell, though, especially in its 4.0 release, makes Windows Server competitive in a way I’ve seen no one outside Redmond adequately credit.

I should make clear a bit of my own background first: Unix is my natural home. When I think of alternatives to Linux, Solaris and the *BSDs come first to mind. A fully competitive Windows, though, makes for a healthier engineering milieu. Even if you’re more committed to Linux than I am, you’ll want to know what “the other side” offers.

At the rack level, Windows is hard to manage, or, more precisely, its management is hard to scale. Bruce Payette, Principal Software Design Engineer with Microsoft, makes it utterly clear in his UCMS ’13 presentation, “DevOps, Desired State, and Microsoft Windows“: Unix bases configuration on declarative documents, and Windows historically has configured through imperative application programming interface (API) requests. The natural way to provision a Linux instance is for someone to copy appropriate *.conf and similar to where they belong; on Windows, the canonical way to configure involves someone pushing buttons on a graphical user interface (GUI). “Managed” in the Unix world generally focuses on text files–versionable, first-class objects in the filesystem, diffable, and human-readable–while Windows management tools do things like replicate opaque system images across a pool. That difference is the big reason in the datacenter that Linux sysads regularly handle a multiple of the number of servers Windows administrators are assigned.

PowerShell changes those terms. It has changed them already, and Version 4 promises to do even more. Payette’s video, mentioned above, explains this in detail.

What you should know about PowerShell

From a DevOps-Agile-Lean perspective, PowerShell plays within Windows much the role that sh does for Unix. While language fans argue the syntax of Ruby vs. Go vs. Haskell vs. …, PowerShell also has a number of interesting and useful characteristics, particularly in comparison to its sh relatives: it builds in remote execution; it natively has the ability to invoke not only external executables, but also libraries; it’s richer in typing than sh, and even facilitates object-oriented coding and piping; and, with Version 4, it builds in “orchestration” and configuration as a workflow-oriented keyword. These advantages reverse the “terms of trade” within the datacenter: with all this available out-of-the-box on every Windows Server host, the latter become easier to script and configure than the Linux workhorses that have built up the cloud over the last decade.

One additional aspect of PowerShell that I see rarely mentioned bears on the nimbleness that DevOps accentuates. In the absence of PowerShell, the way to accomplish chores on Windows servers is to write “console applications”–perhaps in C#, often in Visual Basic, sometimes in Python or other languages. PowerShell makes it easy for sysads to script solutions together without firing up Visual Studio or Eclipse or a comparably “heavy” project-oriented interactive development environment (IDE). While DevOps is supposed to be a unified team, there will be variations in style within it. PowerShell quite nicely fits the circumstances of the DevOps members who want to consume libraries of organization-specific services, without having to invest in everything involved in constructing those services for themselves.

A final milepost of PowerShell’s progress is that Version 4 facilitates integration with Puppet and related DevOps tools. While I generally find it a challenge to gain much from video presentations, I strongly urge you to watch Payette’s; you’ll see that it makes Windows Server a far more interesting choice for the scalable, manageable DevOps host in the datacenter of the future.