In October, Microsoft rolled out the latest and greatest version of its server operating system, Windows Server 2016. There were a lot of innovative and cool features that came with the release, and one of them was the introduction of Nano Server. This bite-sized code promises not only to change the way we deliver the Windows operating system itself, but also to change the way we think about creating, deploying, and managing applications that run on it.
, a bit of history to frame it up. Nano Server was originally created by Microsoft to perform two functions for their Azure cloud. One was to have a very small footprint version of Windows to run applications that were built for the cloud. These applications were later termed “Born-in-the-cloud” applications.
The second was to accommodate their venture into the next generation of DevOps and beyond with the Microsoft Container technology. Linux containers were already in wide use in Azure, and developers and their operations staff wanted them for Windows as well. They already had the option to run Server Core, but it still wasn’t fast enough to match what they saw in their Linux deployments. Nano Server provides high density factors for code and containers using very few resources, as well as a very small attack surface (which means there’s less for hackers to try to take over).
Microsoft also took a slightly different approach to the code itself, deciding to refactor the existing Windows code rather than to spend an enormous amount of time creating something or rewriting what they had. Refactoring involved changing internal behavior in the Server 2016 code, without changing the overall external behavior. (Editor’s note: So this is the opposite of the end-user-facing refactoring we sometimes write about here at BrianMadden.com.)
What was released was a slimmed down, modular, secure, and very fast version of the Microsoft operating system. The latest release of Nano Server is estimated to be around 20 times smaller than the size of Server Core, with almost a 95% reduction in overall virtual machine file size. The attack surface has been reduced so that Nano Server will require fewer than 20% (estimated) of the total reboots required by the full OS each year, and 90% fewer security bulletins. The cold boot time of Nano Server can be as little as 5 seconds in a virtual machine, and 30 seconds on bare metal hardware, minus the BIOS and drivers. And the density factor for Nano Server running as a Hyper-V host is off the charts with estimates that it could host up to 1,000 Nano Server guest machines within one terabyte of RAM. That is just not feasible with any other flavor of the OS.
What about the management of Nano Server? Since the kernel is very small and secure, there is no GUI built into the code. When Nano Server boots, you are presented with what is called the “Recovery Console.” This text-based console allows you to change just a few distinct and critical things in the OS, including changing the firewall rules, enabling WinRM, and IPv4 and IPv6 networking. Outside of that console, you do have an option for a text-based, out-of-band serial console called the “Emergency Management Service.” But for most day-to-day management, of which you will have to do very little with Nano Server, you will most likely use PowerShell or any of the Windows Administrative Tools that are available to manage any Windows Server OS machine. These include tools like Event Viewer, Services, Server Manager, and the like. One amazing offering from Microsoft in Azure is called the Remote Server Management Tools. They allow you do some really great things with any Windows Server, including Nano Server, from the cloud. You can run a RegEdit session, collect performance data, and launch a remote PowerShell session right from the cloud. How cool is that!
Let’s talk about how to create a Nano Server image. As mentioned, Nano Server can run as a Hyper-V host as well as a Hyper-V guest. It can also be run right from bare metal with the appropriate drivers loaded. Now, Nano Server is not a downloadable ISO as the other flavors are. You must create a Nano Server image from the full Windows Server 2016 bits. There are a few ways to create your image, and the TechNet documentation here shows you how, step-by-step. It talks about how to do it with PowerShell, using the “NanoServerImageGenerator” module supplied in the Server 2016 ISO. But, for those that are still not PowerShell savvy, there is also now a GUI that will guide you every step of the way, and it is called the Nano Server Image Builder. Either way, after just a few minutes, you will have an image that is ready to deploy and it will have you up and running with everything you need.
Now, Nano Server is meant to run a very limited amount of applications and services. When you create your Nano Server image, you can specify these to be included in the final image by adding what are called Packages. Packages can contain things such as DNS, IIS, DHCP, and more. You could also add those packages at any time after the image is built by running a simple PowerShell command. You can also add drivers, change firewall rules, and so on. The list of official Microsoft packages is small for now, but it will grow over time. Installing applications and services that are not packages, such as the OpenSSH Server, MySQL, the Systernals Suite (and a GitHub script to auto install it), can be done simply by copying the files into the Nano Server and running the commands necessary to install and run them. There are many, many others that are available via a simple GitHub search.
One important thing to point out about Nano Server is licensing. Microsoft has decided that Nano Server will follow the same Server 2016 editions of Standard and Datacenter, with the additional requirement of Software Assurance. If you wish to run Storage Spaces Direct, or boot Nano Server off bare metal hardware, then you are required to buy the Datacenter Edition, which will set you back over $6,000. But if the workload you’re is Hyper-V, then you would have to pay that price anyways. Smaller services, such as DNS or DHCP servers will only require Standard Edition. You can refer to the Microsoft Licensing for Server 2016 document to get more clarity. In my opinion, I think that Nano Server is really the next logical step in the evolution of the Windows Server OS. Microsoft got this one mostly right, and any small imperfections that come from the newly-minted slimmed down code—compared to the massive millions of lines of code that make up the Server 2016 OS—should only get better with age.
From an administrative standpoint, having these machines running specific workloads, or even as Hyper-V hosts, allows for less hardware, less complexity, and less patching, which in turn means less administrative headaches overall. Now I won’t go so far as to say it relieves all the pain, because along with that awesomeness comes the learning curve of managing an OS without a GUI, and that will prove to be either difficult for some, or even a deal-breaker to others, who will in turn deploy Server Core, or worse, the full GUI. I do think that server administrators will warm up to it over time and really embrace its strengths in their on-premises, hybrid, and cloud environments. I encourage you to not think about the bloated features and the convenience of the GUI. Ask yourself, what workloads could you run on Nano Server in your environment? What are the possibilities?
And in case you thought I forgot about running Microsoft containers and Nano Server, in my next writing installment, I’ll be covering that in-depth and I’ll include all you can do with these awesome new innovations from Microsoft.
Learn what makes Windows Nano Server special