The State of WinOps

As 2017 closes, I have been thinking a little about “The State of Winops“, and the possiblities for “devops-ing all of the things” in the Windows orientated enterprise environments. The provided tooling has always worked better for managing desktop or laptop fleets than for managing servers at scale. Feedback, I have had from my local Microsoft representatives, is that even in cloud world many (most?) customers are still manually deploying and configuring resources. Yet, the opportunity exists to work in quite a different way.

WinOps (a portmanteau of “Windows” and “DevOps“) is a term used referring to the cultural movement of DevOps practices for a Microsoft-centric view.[1] It emphasizes the use of the cloud, automation and integrating development and IT operations into one fluid method on the Windows platform.[2]

Powershell with its structured object-based pipelines offers plenty of opportunity to automate, test and trap error states. If only as system operators we had enough confidence to manage all of the underlying configuration, software and services in the same way.

It has now been some fifteen years since the way forward was laid out in Jeffrey Snover’s Monad Manifesto that led to the creation of Powershell. Servers using versions of Windows Server that were not “Powershell natives” when built are quickly aging out. With the arrival of Windows Server Core and Nano Server, the ability to ship products that are require point and click, and do not offer unattended install diminishes. DSC offers a true hybrid approach for consistently applying configuration to Windows servers whether they are hosted on-premises, in private,or community IaaS clouds or in public clouds, or even within Windows Containers.

Does this atmosphere present 2018 as a golden age where from a system configuration and deployment point of view, that the rodents and point-and-click can be cast aside and replaced with the more document-able and repeatable processes that the shell based approach has always promised to deliver? Can we finally provide a user friendly experience backed by consistent, well-tested deployments that are no longer automation-ally challenged?

Delivering “Infrastructure as Code” in combination with Cloud Services such as Azure allow us to deploy consistent environments where test does actually reflect production. What if we included automated testing of infrastructure as well as the applications that execute upon it to support continuous change and advancement. What if the whole team could see proven test results and enact change confidence of knowing that will not break stuff…. And that should we have made an error (surely not, us!) it could easily be reversed with the help of a little version control.

Such an approach will embed learning in the operation of existing systems, and also develop the culture, skills and tooling needed to move from managing servers, toward orchestrating the delivery of services made up from components across IaaS, PaaS and SaaS offerings as appropriate.


Hello, Containers

Welcome to the Dev, Ops and Win Blog.

I am currently working on Infrastructure as Code and bringing DevOps approaches to a prodominantly Windows based Enterprise.

This promises to be quite a journey from which I expect the benefits of a different way of working to be immense. The intent of this blog to record some my own personal field notes up, down and across the full stack as this journey progresses.