Dev darling Docker embraces Windows Subsystem for Linux 2

Microsoft's risky strategy: Develop on Windows, deploy to Linux

Visual Studio code with Docker and remoting to Windows Subsystem for Linux 2
Visual Studio code with Docker and remoting to Windows Subsystem for Linux 2

Docker has published details of what its container technology will look like for developers working on Windows, after the release of Microsoft's Windows Subsystem for Linux 2 (WSL 2) that is currently in preview.

WSL 2 takes a different approach than the existing WSL. Instead of redirecting system calls to run Linux binaries, WSL 2 runs a Linux kernel in a Hyper-V Virtual Machine, but with integration with the host Windows operating system, so you still get most of the features of WSL 1.0.

Linux compatibility in WSL 1.0 was insufficient to support Docker containers, but in WSL 2 they will work.

Docker is embracing this change. The brief history of Docker on Windows looks like this. First there was Docker Toolbox, released in August 2015, which uses the VirtualBox hypervisor to run Linux in a VM. Then came Docker Desktop, released in 2016, which uses Hyper-V for Linux support, to the relief of developers juggling with incompatible Windows hypervisors. Then in 2017, Docker, working with Microsoft, added support for Windows Server Containers – containers that run Windows rather than Linux applications. At the time, Microsoft enthused that this would "revolutionise the way [customers] build software and modernise existing applications, all with the same platform." The current version of Docker Desktop for Windows installs with Linux containers as the default, but with an option to switch to Windows containers.

Diagram showing how Docker works with WSL 2

Diagram showing how Docker works with WSL 2E

Now Docker has said it will:

Replace the Hyper-V VM we currently use by a WSL 2 integration package. This package will provide the same features as the current Docker Desktop VM: Kubernetes 1-click setup, automatic updates, transparent HTTP proxy configuration, access to the daemon from Windows, transparent bind mounts of Windows files, and more.

The big feature this will enable for developers is the ability to use Linux tools to interact with the Linux Docker daemon (service).

Docker added:

With WSL 2 integration, you will still experience the same seamless integration with Windows, but Linux programs running inside WSL will also be able to do the same.

Other advantages include dynamic memory allocation in WSL 2, enabling Docker to make more efficient use of resources, much faster cold start-up which means the Docker daemon does not need to run when not in use, and more reliable container access to files on the Windows side.

Docker envisages developers using the "Remote to WSL" extension in Visual Studio Code (VS Code) in order to edit code in Windows while interacting with Linux though the VS Code terminal.

All good news? It is from Docker's perspective since it will have less work to do in order to run well on Windows, and the benefits for developers are real.

Microsoft dons penguin suit

The surprising aspect to all this is the effort Microsoft is making to promote Linux application development to its developers on Windows. The reason for this change of heart is the Azure platform, which means Microsoft can profit almost as much from hosting Linux applications as from Windows, particularly if those applications use other Azure services.

Projects like the cross-platform .NET Core and SQL Server for Linux are also part of this trend. The Docker news is of no interest to developers using Windows Containers, but there are not many of them. At Microsoft's Build conference last month, Gabe Monroy, lead program manager for the Azure Container Compute team, was asked whether Windows Containers are for legacy and Linux Containers for new projects. "I think that is a fair description," he said, demonstrating how the company's thinking on the subject has shifted.

Similarly, WSL 2 makes life better for developing Linux applications on Windows, but there are downsides. Running Linux in a VM as opposed to redirecting system calls is better for compatibility but inherently worse for integration. One aspect of this is that in WSL 2 I/O performance to files within the Linux VM is much faster, but I/O performance between Linux and the host is worse. Another is that WSL 2 has no access to serial or USB ports.

"I primarily want my source of truth (my files) to be on the Windows side of things. WSL1 had the perfect working model for me," said a developer in response to the announcement of WSL 2 previews for those on Windows Insider builds.

Microsoft's response? "We understand that this could be a blocker for many people, and so we aren't discontinuing working on WSL 1." This will be a half-truth though; Microsoft will now put most of its effort into WSL 2.

Develop on Windows, deploy to Linux is an interesting strategy for Microsoft and one with obvious risks for the future of the Windows side. ®

Sponsored: Your Guide to Becoming Truly Data-Driven with Unrivalled Data Analytics Performance

SUBSCRIBE TO OUR WEEKLY TECH NEWSLETTER




Biting the hand that feeds IT © 1998–2019