The promise of Windows Server 2016 Nano Server was that, rather than deploying the server equivalent of a swiss army knife into production, you could instead deploy a highly optimized workload specific scalpel.
Built to spec
With Nano Server you built the server for a specific task rather than deploying the server and adding roles and features later. This made the server more secure because it had a radically reduced attack surface over other Windows Server deployment options. Unused roles, such as IIS, couldn’t be deployed if the server was compromised because you couldn’t add roles to Nano once it was deployed. If you wanted to add roles, you needed to deploy a new Nano instance.
Not for legacy server administrators
Nano server was so specialized and attuned to modern practices of systems administration that you couldn’t sign on to it locally and instead had to perform all administrative tasks remotely. You couldn’t remote desktop to it and if you connected a monitor to it, you could only see basic diagnostic information such as IP address and be only able to configure simple firewall rules. Nano Server was a precise expression of the philosophy “Cattle Not Pets”. Nano server was a simple units of workload hosting rather than as a monolithic multi role components of datacenter infrastructure.
There was certainly some reluctance on the part of some long term server administrators to embrace this “remote first, can’t log on at console” option. Even though most administrators do perform administration remotely rather than RDPing across to specific servers, many also want the safety net of being able to sign on locally should something go dramatically wrong. In a few years “just redeploy the workload if something breaks dramatically” might be more generally accepted by Windows Server administrators, but today only a minority of cutting edge DevOpsy types are fully comfortable with that idea.
Unfortunately the promise of Nano server will go unrealized because Microsoft has altered course with its plans for Nano. Rather than supporting functioning as a bare metal host operating system or as a virtual machine guest operating system, as of Redstone 3, Nano will only be supported as a container operating system for Windows Server and Hyper-V containers.
This means that if you want to deploy an application in a Windows container, your first choice for container OS will be Nano and only if the app won’t run on a Nano container, on a Server Core container. The future version of Nano will be slimmed down even more so that it is of comparable size to Linux containers, making them quicker to deploy and minimizing their resource impact.
The promise of Nano server and the reality of it when Server 2016 RTM’d were quite separate. The RTM version of Nano server certainly indicated the future promise of the product, but it was also often more complicated to use than it needed to be. Joining a domain or applying software updates was less than straightforward.
Most assumed that this was something that would be improved in time. While few actually deployed Nano in production, there was a push amongst those of us that talked about Windows Server 2016 to evangelize the idea that at some point in the future you’d deploy Nano as your first deployment option, Server Core as your second option, and finally, if you couldn’t avoid it, Server with a GUI.
Nano versus Containers
Microsoft’s switch in focus to Nano as a server operating system for containers makes sense for multiple reasons. When Nano was conceived, Windows containers simply didn’t exist. While using Nano as a bare metal host made sense, it was harder to articulate why organizations would choose to deploy a Nano VM over a container when the container usually had the smaller footprint and both had a similar level of functionality.
There would have been a greater difference between Nano and containers if Nano had been able to host a greater number of Windows Server roles and features. One of the most common questions I got about Nano when I was presenting on and demonstrating the operating system was whether or not it would function as a domain controller. My answer, until last week, would have been “at some point in the future”. The answer today is “very unlikely”.
So while part of Microsoft’s change in direction can be attributed to how ready Nano was for real world workloads (it wasn’t there yet), part of it must be attributed to how people have ended up using containers, which has made the case for Nano less strong.
A bold path not taken
The future of general purpose operating systems is in flux. On one side there is a push to move many roles and features hosted by on-premises servers into the cloud so that they can be consumed through a subscription model. On the other side is the reality that the general purpose Windows Server 2016 has the quickest rate of adoption of any of Microsoft’s server operating system releases, meaning that no matter what the cloud spruikers say, there is still a great desire for on-premises general purpose server operating systems. Nano as a bare metal host and virtualization guest server operating system is most likely an idea that was simply ahead of its time. Maybe, at some point in the future, Microsoft will try it again to see if “ahead of its time” has transitioned to “an idea whose time has come”