News

Snover Highlights DevOps and Nano Server at Build Event

• By Kurt Mackie
• 04/01/2016

The DevOps message was in force this week at Microsoft's Build event.

Jeffrey Snover, a Microsoft Technical Fellow and the inventor of the PowerShell scripting language, didn't present at Build but he took part in a Microsoft-produced Q&A session at the event. His Friday chat is available on demand at this page.

Snover explained that while PowerShell started out with a focus on improving Windows Server management via a DevOps mindset, PowerShell 5.0 is now starting to add more developer-focused aspects as well. For instance, it's now possible to implement .NET classes in PowerShell, Snover said. You can also have subclasses in PowerShell, as well as interfaces and inheritance. It's more natural to express a contract using a class, Snover explained.

PowerShell vs. Bash
In response to a question, Snover threw cold water on the notion that the PowerShell environment might get replaced by the Linux Bash shell on Windows. Microsoft announced this week that it had enabled the Bash shell on Windows to help developers that regularly use open source, Linux-based development tools. Snover said that Microsoft made that move because developers using those tools typically found the Windows workflow to be "difficult." The Linux tools didn't have "the right semantics" for Windows, he explained.

Snover said that there won't be a Bash shell for Nano Server, which is Microsoft's minimal footprint deployment option (beyond Server Core) in Windows Server 2016. "The Bash shell is focused on developers and their desktops," he explained.

However, Nano Server will be supported by Microsoft's Service Fabric, Snover said.

At Build Day 2, Microsoft announced that its Azure Service Fabric was generally available. It's a service that can be tapped to support scalable apps. In addition, Azure Service Fabric enables rolling updates with automatic rollbacks when things go awry.

Snover also answered a question about whether Microsoft would port PowerShell to Linux. He said that there was incredible amount of interest at Microsoft in having PowerShell on Linux, with a strong demand for PowerShell to become a universal shell. However, the main limiting problem in going that route was that PowerShell had been written in .NET code (C#), and .NET didn't exist on other environments at the time, "but now it does." (Microsoft announced it was bringing .NET core into open source back in 2014.)

WSA Installations
Microsoft is shifting its approach with Windows Server 2016 installations. In the past, Microsoft had not taken an architectural stand on a set of key issues that caused conflicts between developers and operators, Snover said. However, Microsoft has a new installation approach with Windows Server 2016 called "WSA" or Windows Server Applications, which is an APPX (.appx) approach for installing servers, Snover said.

"We just took APPX, extended it, and made it friendly to servers," Snover said. It was done to smooth the app packaging interfaces typically dealt with by both operators and developers, he added.

APPX is an application packaging approach for Windows Store apps that Microsoft first introduced with Windows 8. It was designed to simplify the scripting typically involved in packaging apps.

WSA uses the declarative approach of APPX to install Nano Server instead of MSI (.msi) install packages. The concept is more fully explained in this Microsoft blog post.

The configuration of Nano Server gets carried out separately from installation under this WSA install concept. Either Desired State Configuration or other technologies are used to configure Nano Server. Microsoft has described Desired State Configuration as a kind of PowerShell push-pull method designed to keep a server in an optimal state.

Microsoft dispensed with the MSI approach for Nano Server because MSI is problematic for remote installs. Nano Server is remotely managed only, and that happens via PowerShell or WMI (Windows Management Instrumentation) scripts or using a browser with a graphical user interface (GUI).

MSI packages also are problematic for Nano Server installs because there's no offline installation support, "which is one of the major goals for Nano Server in the long run," Microsoft's blog explained.

With Microsoft's cloud approach, server reboots and size became issues. Microsoft wanted something fast when it developed Nano Server. It refactored the server OS and got rid of the GUI stack and 32-bit support. Consequently, Nano Server requires one-tenth the number of patches of Windows Server because of its size reduction, Snover said. Security vulnerabilities are lowered because of the reduced footprint. The deployment time is reduced 26 times with Nano Server as well. Also, the amount of kernel memory consumed by Nano Server is less than half that of Windows Server, he added.

Snover said his joke is that he didn't come to Microsoft because of his strong love for Windows. "I came to Microsoft because I wanted to create something I did love, and Nano Server is that thing."