DevOps as a practice has largely grown from the need to manage infrastructure and configuration for large scale applications. Frequently this has led to the technical choice of fleets of Linux-based application servers operating in a dynamic environment such as VMWare or AWS. The reasons for this technical choice are straightforward. Linux enjoys a lightweight and standardized remote administration mechanism through Bash and SSH. Software installation and dependency management are usually a breeze thanks to Linux distributions’ package managers.
Consequently, the art of DevOps has traditionally lagged in the world of Microsoft Windows. Historically automation on Windows has been a pain point. This is due to a few factors:
- Cultural mindset: Windows sysadmins aren’t as accustomed to the idea of automation.
- Tooling: Windows’ remote administration tools have been “good enough” to keep the demand for automation low.
- Interface: The GUI-first nature of Windows has always resisted automation.
Many enterprises, however, are still deeply dependent on Microsoft Windows, SQL Server, and other Windows-specific products. There is simply a tremendous amount of existing .NET code that businesses aren’t ready to toss out. As Microsoft has been making the cultural shift towards the cloud with the Azure platform and improving its general compatibility with the Linux world with such initiatives as the Windows Subsystem for Linux (WSL) and .NET Core, the DevOps community has been steadily improving the outlook of Windows automation and deployment.
Scripting and Remote Administration
[Source: How-To Geek]
Modern PowerShell is a true contender with Bash in the scripting space. For better or worse, many Bash commands are aliased under PowerShell to have similar functionality, such as ls and curl. But beware, gentle user! For these commands use different flags and positional arguments, and PowerShell has a unique, object-oriented approach to return values, so unfortunately even simple Bash scripts are usually not PowerShell compatible and thus will require porting.
However, PowerShell can also operate remotely the way one might use Bash over SSH to login to a Linux machine to remotely administer it using Bash. The result is considerably lower bandwidth and easier automation than using the Windows GUI via remote desktop client, or a streaming VM client. The caveat is that using PowerShell remotely in this way can be considerably trickier, especially for non-domain and transient target hosts, particularly if not using SSH as the transport.
This leads us to configuration automation. Puppet and Chef are both mature configuration platforms with robust Windows support. However, due to their weight, dependence on complex DSLs, and master-agent architectures, they have fallen somewhat out of favor in modern DevOps practices.
Enter the newer generation of masterless, imperative configuration platforms such as Salt and Ansible. Both support configuring Windows server targets, however Ansible is a Linux-native tool and to run it from a Windows control machine means installing some flavor of Linux using the WSL. These tools rely on PowerShell remoting to drive system configuration, and so while flexible and capable, can also be somewhat of a pain to set up initially.
Not to be discounted, the HashiCorp configuration management stack is also available as native Windows binaries and through Terraform supports infrastructure management across all major cloud providers as well as on-premises virtual environments and some configuration tasks.
Containerization is a staple of modern DevOps deployment. Fortunately, over the last couple of years, Docker for Windows has matured into a production-ready environment. Docker for Windows runs as a Windows service with deep integration with Hyper-V and the WSL layer to provide containers in the Windows ecosystem. In fact, with relatively fresh builds of Docker and Kubernetes, K8s now supports Windows Server container instances based on Windows server 2017 build 1709 or later.
DevOps is Live for Windows
If you’ve had reservations with rolling out DevOps tools and techniques in your company because Windows has been a second-class citizen in the DevOps world, think again! The tools and technologies are catching up quite quickly thanks to the hard work of the community and an increasing and welcome openness by Redmond to embrace Linux and virtualization on the platform.
Are you considering adding DevOps to your Windows environment? Do you have questions about the Cloud or DevOps? Comment below and join the conversation!