Why the Windows Subsystem for Linux Matters to You – Even if You Don’t Use it

You’ve probably heard that Microsoft now allows you to run up a Linux shell inside Windows. Perhaps you stifled a yawn and moved on to another tech article. You don’t run Linux, so who cares? Anyway, wasn’t there that Cygwin thing that let you do that, years ago? Or just run it up in a VM. Big deal.

But there’s more to it than meets the eye. Much more.

The underlying technology behind the new WSL subsystem, now available on Windows 10, is the result of one of Microsoft’s most significant and far-reaching innovations for many years – the outcome of a research project that dates back to 2011, called Project Drawbridge.

Drawbridge had an ambitious goal; to refactor the decades-old tangle of subsystems in Windows into a clean architecture that supports a new kind of entity; a picoprocess. A picoprocess is an ultra-lightweight container which devolves all interaction with its environment through a channel to a security monitor, which in turn orchestrates communication with the rest of the Windows subsystems.

Compared to the hundreds of Windows DLLs and thousands of API calls, that channel is an amazingly slender 45 commands wide. By carefully choosing the channel operations that need to be performed, it’s possible to separate the picoprocess cleanly from the underlying operating system.

WSL is the first Microsoft product running on Windows to use this new technology, but it won’t be the last. By refactoring the Windows environment in this way, Microsoft can, at last, start implementing security by design. And it also has huge implications in other areas; the explosion of interest in containerization (e.g Docker) means that Windows has been left struggling to maintain its relevance as a server-grade operating system. Now, at last, an infrastructure that will let Windows move towards scaleably supporting containers is in place. And by extending Windows to support Linux as a first-class citizen, management frameworks such as Kubernetes can easily be extended to handle Windows and non-Windows servers consistently.

You’ll note that I said WSL is the first product running on Windows to use the new technology. However, it’s not the first Microsoft product to benefit from the Drawbridge initiative. That – interestingly – was SQL Server for Linux. You see, platform abstraction cuts both ways. It makes it easier to port applications designed for other operating systems to Windows, but it also makes it possible to go the other way. To make SQL Server for Linux possible, Microsoft abstracted its platform requirements into a subsystem they call SQLPAL, making it far easier to move this complex product away from its Windows native environment.

OK, but what about cloud-based infrastructure? Well, Microsoft has apparently been quietly working to integrate the Drawbridge technology into their Azure offering. While we haven’t seen any public announcements on this recently, you can be sure that the technical success of WSL and its largely positive reception by the tech community will have energized Microsoft to push forward in this area. The obvious attractions of containerization technology in the cloud, coupled with the success of the competing Amazon AWS Lambda initiative will be driving factors here.

Cleanly separating the operating system from its consumers in this way has other benefits, too. For example, the advent of low-maintenance client devices such as the Chromebook has rekindled interest in the ‘thin client’; an idea that was too far ahead of the technology of the day to really gain traction. But if you can abstract away dependencies on large, complex, entangled subsystems, you can also start refactoring those subsystems internally in ways that would have been impossible when “everything connects to everything else”. Since you have a standard contract of a few dozen “system calls” only, how the actual “heavy lifting” gets done can be modified without breaking your consumers.

This then allows you to modularize your back-end functionality into ‘grains’ which can be dynamically loaded as required. Then your “thin client” device can still perform useful work even when it is not connected to a network, and without being constrained by some fixed amount of inbuilt OS functionality that cannot easily be extended.

Recall that Microsoft’s Jerry Nixon said when Windows 10 was released that “Windows 10 is the last version of Windows, we’re all still working on Windows 10.” Seen in the light of the Drawbridge initiative this starts to make a lot of sense. Why would “an operating system version” now have a fixed, constrained set of services which could only be augmented “by upgrading to the next version”, when you can refactor everything to a much more granular level and then “rip and replace” subsystems independently of each other?

So that’s why WSL matters. As a technological tour-de-force it’s impressive in its own right. But as tangible proof that Microsoft *can* untangle 30 years of Windows cruft, it points to an exciting future where the modularity, security, upgradeability and manageability of complex systems, both on-premises and in the cloud, will take a giant leap forward.

And it’s also a wake-up call for companies that have been deferring updates to Windows 10. Sure, Windows 7 has been stable and reliable, and it’s easy to look at Windows 10 and think ‘why bother’. This isn’t helped by historic memories of Windows upgrades that, arguably, were not as solidly engineered as they could have been (ME, Vista, Windows 8).

But with Windows 10 we’re seeing Microsoft undertake a complete ‘from the ground up’ progressive re-engineering exercise. It’ll take time – but the benefits, particularly in “security by design”, as well as modularity and scalability, are enormous. Unlike some of its predecessors, Windows 10 is not ‘change for change’s sake’ and, under Satya Nadella’s enlightened leadership, Microsoft is not the company you dealt with a decade ago.

So plan your migration process now. Subsystems like WSL may not be critically important to you – but the solid foundations on which they are being built should be the foundations on which your critical business processes rely.