Bash on Windows, Powershell and Docker: Why Microsoft is calling time on the server GUI
Take one last look -- and say goodbye to the Windows Server GUI.
It's been a long time coming, but at its Build 2016 developer conference Microsoft unveiled two tools that finally put the nails in the coffin of the server GUI. And it's about time too.
Looking at the recent history of Microsoft's server operating system and tools, it's been a slow unwinding of the mistakes made with the original NT releases. First came PowerShell, and with it a true Windows command line environment. Closely related was the development of Windows Server Core, which dropped the GUI in favour of a command line-driven experience (while still letting apps have their own GUIs). Windows Server takes things further with the container-focused Nano Server, which has no GUI capability at all -- and even takes away the command line.
At Build Microsoft announced support for the Unix Bash shell on Windows, showing developers using secure shell tools to work directly with a remote Unix server. While many focus on Windows finally supporting Unix and Linux software (with successful attempts to use X to run graphical Unix applications on Windows PCs), what's most important here is a continuity of the development -- and operations -- toolchain from Windows PC to Unix server.
With Bash running on Windows, you can use the same scripts and tools on a Windows PC as on a remote server, with secure access to servers from your desktop without leaving a command line prompt. There's no need to use VNC or other remote desktop tools to connect to a server, or even a SSH terminal like PuTTY: all you need is a Windows command line (one that's improved dramatically in Windows 10). That means server builds can be less complex, only requiring essential tools, minimizing attack surfaces and protecting apps and user data.
The second, much lower key announcement was perhaps more important. Anyone working with containers on Windows Server 2016 would have noticed that there was an issue with the two management options. Containers deployed using the Docker tools couldn't be managed with PowerShell, and vice versa; neither tool could even see the other's containers. Build saw the launch of a new PowerShell container tool that replaced the original with one that worked directly with Docker -- making Docker the default tooling for containers in Windows Server 2016.
What made this announcement different was that by targeting the Docker REST APIs, PowerShell could now work with Docker containers on any platform. You'll be able to install the PowerShell module on Windows machines, and manage containers remotely, on Windows Server and on Linux. That's an important shift for Microsoft, bringing out a management tool that works against APIs that aren't its own Windows Management Interface.
This approach points to an interesting direction for PowerShell and PowerShell modules. There's long been a discussion around PowerShell support for Unix, and there is a selection of official and third party cmdlets for remote management of certain Unix functions. There's been plenty of speculation about a Unix port of PowerShell, but with more and more Unix tooling now offering APIs for DevOps platforms and for SSH connections, the need to actually port Microsoft's tools to Unix is going away.
What now seems likely, especially with Windows support for SSH just over the horizon, is that any future support for Unix in PowerShell will be along the lines of the new Docker module. Using your Windows PC you'll be able to target PowerShell scripts against specific Unix commands, either wrapping shell scripts in PowerShell and executing them over SSH, or by targeting applications and services directly via REST APIs.
With Bash and with PowerShell, Microsoft now has two widely used remote operations platforms in Windows. It's time to say goodbye to the server graphical UI.
The death of the server GUI doesn't mean we won't be using GUIs to manage our servers. It's just that those GUIs will be running on our desktops, laptops, and mobile devices.
We can see aspects of this future already in System Center, Microsoft's management tooling. Using its Virtual Machine Manager to build virtual infrastructures, you can quickly point and click your way through building a set of virtual servers running on a virtual network.
But under that point and click management UI is a very different set of tools that take those GUI-driven management services and translate them into PowerShell or Bash scripts. What was a manual way of building a virtual machine suddenly turns out to have been a way of authoring the script needed to automate the process. All you need is to copy the resulting script into an editor, and you're ready to turn explicit machine names into variables and you've got a generic cmdlet that's ready to use again and again.
It's a model that's taken in a deeper, more complex, way in Azure, with the move to using Azure Resource Manager templates to describe and deploy entire infrastructures. Using tooling built into Visual Studio you can quickly build a template that deploys not just servers and networking, but also configures and connects Azure's platform features, like databases and storage.
So why is Microsoft pushing for this change now? Perhaps the biggest reason is Azure, and the issues of running a planetary-scale cloud service. You can't point and click in the GUI of every one of millions of physical and virtual servers. Instead you have to automate every action, building scripts and services that can manage infrastructure and applications at scale. Using PowerShell, we can build those scripts to work against remote Windows Management APIs, quickly running commands across a fleet of servers, often working in parallel.
It's a scenario that's led the development and direction of PowerShell, and alongside, the move to a set of Windows Server options that remove its dependency on a graphical shell in favour of the command line in Server Core, and now with no UI options at all in Nano Server.
Remote management APIs mean you can use either remote administration tools or web front ends if you want to get hands on with a server, with batch scripting for mass actions. That same model is coming to the UNIX world, with the arrival of unikernel servers for container hosting.
There's a lot to be said for a world of UI-less servers. It's first and foremost a huge reduction in the attack surface and in the maintenance load. Servers become smaller, more agile, and more easily configurable. You can build a server that's optimised for a single task; using a thin server as a host for a series of containers that isolate key functionality, protecting both applications and the underlying OS. There's also the added benefits of using script-driven technologies like Desired State Configuration to keep a server configuration stable, and Just-Enough Admin to make sure that administration rights are only delegated when needed, and then only for a specific task.
On the client-side, a combination of Bash on Windows and an API-aware PowerShell gives Microsoft a powerful set of tools for both its developer and its system administrator users that's ready for a world of GUI-less servers. Putting all together, and the result is a very interesting future indeed.