Doing DevOps on Windows is one of the most frustrating things IT organizations have to deal with. In 2021, Windows organizations often have to make do with “Linux-based” tools that feel cobbled together and more often than not, work poorly in their environment. This often pushes IT organizations to the expensive (and incorrect) conclusion that moving to Linux is the only other option.

I’m not arguing Windows is better than Linux. This article simply outlines the third (and easiest) option to properly do DevOps on your Windows servers without having to switch or compromise.

What is a Windows-First & Linux-Based Tool

A Linux-based tool is a tool that was designed to work primarily in Linux and was eventually ported to work in Windows. A Windows-First tool is…well you guessed it – a tool that was designed to work in Windows FIRST.

The simple and honest truth is that no matter how much effort a team puts into porting a tool from Linux to Windows, it will never be as good as a tool that was designed with Windows in mind.

It’s a real challenge for Windows organizations to implement DevOps best practices even in 2021 since most tools are Linux-based. Many Windows teams feel frustrated, left behind, irrelevant, and threatened because of this. Surveys of industry professionals show that people believe Linux is the future of DevOps and believe Windows DevOps will die off just like Zune or Betamax.

Why So Many IT Organizations Choose Linux

DevOps started amongst Linux users. So first movers’, shakers, and advances happened in Linux environments. However, as many Game of Thrones fans can tell you, a rich history is no guarantee of current quality. It’s because of this long history that most tools in DevOps were originally built for Linux, to solve Linux problems.

However, Linux can’t take all the credit for its DevOps success. In recent years even Microsoft’s CEO Staya Nadella has said “Microsoft Loves Linux.” And it’s not just on stage, Microsoft has been heavily pushing the DevOps crowd to Linux through their recent technologies: NET5, Azure, etc.

It should come as no surprise that a general perception that “Linux is Required for DevOps/Automation” has become commonplace. 

Why We Think Windows is Underrated

Chances are, your current technologies and people are on Windows. Although informal surveys say Linux is the king of the DevOps world, the actual server market share data tells a much different story.

According to Gartner’s research, actual server market share trends show Unix (HP UX, IBM AIX) and other (mostly System Z) servers are in decline while Windows continues to grow (5.3% growth in 2017). ​

It would be foolish for me to simply say that “Windows is the future”, but Windows still holds a major market share.

What’s baffling from this data is that Windows servers have a lead over Linux, but Windows organizations have to choose between using poorly ported Linux-based DevOps tools in Windows or migrating to Linux to do DevOps.

If Linux is so Popular Should I Just Move?

Well yes, but actually no.

Migrating to Linux is not a feasible option for most organizations. It’s a difficult, expensive, and incredibly time-consuming process. Moving from Windows to Linux basically means starting over from scratch, and transferring all current data to a new system. Small companies might have the benefit of flexibility and would be able to make the move. However, most companies will work with what they have and what they have are Windows licenses, Windows servers, and a team that knows how to work in a Windows environment.

This is why Windows DevOps teams feel so frustrated. They’re stuck in a system that doesn’t work with tools that don’t enable them to improve their situation.

The 2 Main Challenges of using Linux-based Tools at a Windows Organization

Adapting Technologies

Many Linux-based tool features aren’t available on Windows OR If they are, they’re a poor afterthought.

Since most DevOps tools were built for Linux, it makes sense that they’re designed to fix Linux problems.

Adapting People

Forcing Windows users to use Linux-based tools is like forcing a carpentry team to start making metal chairs. Carpenters can’t make metal chairs. Attempting to do this will result in major problems with 2 natural solutions.

Solution #1: Fire All of your carpentry team and hire new welders. Carpenters understand the theory of chair-making, and many might know basic metalwork. However, asking them to start welding on that knowledge alone will result in sub-par chairs. But good welders are in demand and difficult to hire​. On top of that, how is your carpentry team manager supposed to know what a good welder looks like?

Solution #2: Train all your carpenters to weld.​ However, your carpentry team most likely wants to work as carpenters and doesn’t want to throw away their knowledge. Re-training a team also comes with an incredibly high price tag. A lot of re-training = training costs, newly re-trained employees = many mistakes, and many mistakes = higher repair costs. On top of that, chances are your newly-trained welding/carpentry team doesn’t understand the processes enough to properly document issues when they happen, That leads to even higher repair costs since your in-house team doesn’t know what to fix.

In the DevOps world, this will lead to legacy servers that everyone is too afraid to fix.

But enough with the analogy. Let’s get real and technical.

Windows VS Linux Servers and How it Affects Your Team

Modular Vs Integrated

Linux is highly modular and essentially only an operating system kernel. ​It works as a set of specific versions of specific packages. Developers working on Linux often choose packages and versions based on their own criteria and preferences while Operations validates those choices.

Windows is tightly integrated​ and has “everything you need” pre-bundled. “Features” can be enabled or disabled meaning that there is much less customizability. Developers ask how servers are configured/how we WANT them to be configured and Operations dictates which configurations Developers may use.

Whichever you choose all comes down to personal preference. Windows vs Linux should be seen as nothing more than a means to an end.

Accelerating Development​

Linux environments give developers more control over their choices. For every function in Windows, Linux has 5. Linux DevOps teams can pick and choose which specific configuration accelerates their projects and plans the fastest. On the other hand, Windows dictates the environment. Developers are able to simply enable and disable pre-bundled features without further thought. This streamlines the decision-making processes.

The User Experience: GUI VS Commands

Windows comes with pre-bundled features. That means it’s much easier to make a cappuccino, but it also means it’s much “chunkier.” More features (whether or not you use them) means more space.

Linux is like creating your own custom cappuccino machine that applies the perfect amount of pressure on your beans and steams your milk to exactly the right temperature you want. It might be better in the end, but it’s much more difficult to get there.

Windows-first Tools

If your organization is Windows-based, then you need Windows-based DevOps. In most cases, it’s not worth switching to Linux. There is a growing library of Windows-first tools. Inedo’s tools are a Window-first set of tools that allow you to keep your current staff and current infrastructure.

In my next article, I’ll explore WinOps, the best practices and tools of DevOps for Windows organizations, including PowerShell DSC, Linux Tool Evaluation Framework​, WinOps and Docker, Chocolatey, and package management in Windows.