Microsoft Trims Nano Server for Container Work – InApps Technology is an article under the topic Software Development Many of you are most interested in today !! Today, let’s InApps.net learn Microsoft Trims Nano Server for Container Work – InApps Technology in today’s post !

Key Summary

This article from InApps Technology, authored by Phu Nguyen, details Microsoft’s strategic refinement of Nano Server in Windows Server 2016 to focus exclusively on container workloads, driven by customer usage patterns. It highlights enhancements for container orchestration and the evolution of Windows Server for modern, containerized environments. Key points include:

  • Nano Server Evolution:
    • Initial Role: Introduced as a lightweight, no-local-logon OS for Windows Server 2016, aimed at compute/storage clusters and infrastructure roles, but telemetry showed predominant use in container scenarios.
    • Refinement: Microsoft stripped Nano Server of unused infrastructure components (e.g., WMI, IIS, .NET, PowerShell, drivers, event loggers, scheduled tasks) to create a smaller, container-optimized image, reducing its footprint from 1GB to sub-500MB (uncompressed), with goals to match Linux container image sizes (e.g., with .NET Core).
    • Purpose: Optimized for higher density, faster startup, and consistency between development (laptop) and production environments.
  • Container Enhancements:
    • Orchestration Support: Adds networking features for Kubernetes and Swarm, including network overlay support, hot-adding network interfaces, and sharing network interfaces between containers (initially for shared kernel containers in Nano Server 1709, later for Hyper-V isolation containers in Server Core).
    • Storage: Supports mapping SMB volumes and named pipes into containers, improving storage connectivity and orchestrator compatibility.
    • Modularity: Components like .NET and PowerShell are now optional layers, pulled as needed, enhancing container-native flexibility.
  • Server Core Role:
    • Infrastructure Hosting: Server Core retains infrastructure roles removed from Nano Server and is used by Azure, Azure Stack, and Hyper-V containers as the host for Nano Server images.
    • WSL Integration: Windows Subsystem for Linux (WSL) added to Server Core (not Nano Server), enabling scripts to manage containers and cross-build Linux/Windows container images.
  • Update Strategy:
    • Semi-Annual Channel: Nano Server and Server Core receive updates every six months, requiring Software Assurance or cloud hosting (e.g., Azure). Server Core also offers Long-Term Servicing Channel (LTSC) for traditional infrastructure roles.
    • DevOps-Friendly: Shorter release cycles simplify validation compared to three-year cycles, appealing to developers managing containers versus traditional admins (e.g., Active Directory).
    • Adoption: Nano Server sees “shockingly high” container adoption, per Taylor Brown (Windows Server team).
  • GUI Management:
    • Azure Server Management Tools (SMT): Discontinued (June 30, 2017) due to feedback about requiring Azure for on-premises management. Previously offered web-based task manager, registry editor, and Hyper-V management.
    • Future Plans: Microsoft promised new GUI options for troubleshooting at Ignite (September), addressing customer demand for user-friendly interfaces for GUI-less systems.
  • InApps Insight:
    • Nano Server’s container focus aligns with trends in Microsoft-Red Hat partnerships (e.g., OpenShift Windows containers), LunchBadger’s Kubernetes solutions, and Cloud Foundry’s Diego/Lattice for container orchestration.
    • InApps Technology can leverage Nano Server for clients building containerized applications, integrating with Azure Durable Functions, Power Fx for low-code, or GraphQL APIs (e.g., Apollo) to deliver lightweight, scalable solutions in hybrid cloud environments.
Read More:   Best Tools to use for API Testing in 2025

Read more about Microsoft Trims Nano Server for Container Work – InApps Technology at Wikipedia

You can find content about Microsoft Trims Nano Server for Container Work – InApps Technology from the Wikipedia website

When Microsoft introduced Nano Server in Windows Server 2016, as a small-footprint server OS with no local logon, it was targeted at a few different workloads. The company has found the software is increasingly being used for one type of workload: managing containers.

As a result, the company has whittled down the core of Nano Server to just those components needed to run containers. It has also added in networking support to accommodate the needs of container orchestrators, notably Kubernetes and Swarm.

For Microsoft, Nano Server is the heart of Windows Server; a minimal refactoring that future versions of Windows Server will build on, with “just enough” of an operating system to run applications without introducing more of a risk surface than necessary. For customers, it was designed to run both containers and some key infrastructure roles.

“When we launched Nano Server last fall, it had a very small footprint for a compute cluster, a storage cluster and other infrastructure roles, but people weren’t using it for that, but they were using it for containers,” Chris Van Wesep, Microsoft Enterprise Cloud product marketing director told InApps Technology. The anonymized telemetry in Windows Server 2016 showed that “the vast, vast majority of Nano Server deployments were for container scenarios not for the infrastructure scenarios.”

Nano Server will include more platform support for container orchestrators like Kubernetes and Swarm.

That’s why the next version of Windows Server, which will be available in the latter part of this year, removes those unused infrastructure roles from Nano Server to make a smaller image still. A smaller image means higher density, faster startup times and the ability to deploy enough containers on a laptop to be consistent with the production environment on the server for development and testing.

Those roles will be in Server Core, which is what Azure and Azure Stack run on, and is what you’ll use to host your Nano Server images. Hyper-V containers also need Server Core, not Nano Server

Smaller, Faster, More Containerized

“The feedback we got on Nano Server was ‘it’s good, but it could be better’,” Van Wesep explained. “Customers are saying ‘You got it down to sub 500MB, but I would like to see it 200MB or sub 100MB smaller.’ There is a tradeoff that needs to be made here and we’re making that tradeoff; Nano Server is an optimized-for-containers runtime image.”

At one point, the Nano Server image was 1GB, uncompressed, Taylor Brown from the Windows Server team told us. “We have a lot of components that really weren’t relevant to containers but they were relevant to physical machines and virtual machines, like the recovery shell. They weren’t optional components; they were just parts of the OS that we couldn’t pull out in a container-native way.”

Read More:   Operators and Sidecars Are the New Model for Software Delivery – InApps 2022

For the next release, Microsoft is already committed to getting the uncompressed image down to 500MB and Brown called that conservative; “I think we’re actually going to exceed that in the first release and we’re really committed to continuing down that road. The pull size, the compressed size, and the on-disk size will both get much, much smaller.” In the long term, the goal is to have a Nano Server image with .NET Core in be the same size as a Linux image with .NET Core.

That means removing a lot of components. “We’re gutting Nano Server,” Taylor said. “We’re pulling out WMI, we’re pulling out IIS, we’re pulling out .NET, we’re pulling out PowerShell, we pulled out every driver, we pulled out event loggers, we pulled out scheduled tasks.”

That might well break workloads, so Brown encouraged developers to join the new Windows Server Insider program to try this container-optimized version of Nano Server as soon as possible, so the team can add back any components that turn out to be necessary. “We’ve got to be aggressive; the vision is let’s cut and prune and get the thing as optimized as possible. Let’s not be afraid, let’s move forward fast and make this thing small.”

Components that used to be part of the images will now be optional. “You’ll pull down Nano Server and if you want .NET, you pull down .NET on top of that, if you want PowerShell you pull down PowerShell. If you don’t want .NET, you don’t have to have .NET, if you don’t want PowerShell, you don’t have to have PowerShell. These are all optional layers now and very native to the container experience.”

Windows Server 1709 will add support for mapping SMB volumes into containers (credit Microsoft)

Nano Server will include more platform support for container orchestrators like Kubernetes and Swarm. It already has network overlay support, so you can make native bridge networks across Swarm clusters, but the next release, named 1709, for the planned September release date, will add mapping named pipes into containers, which means you’ll be able to run container orchestrators as container images — for both Docker and Hyper-V isolation containers.

Nano Server will also let you hot-add network interfaces; that’s been a problem for Kubernetes, which starts a container without network adapters and then adds them to the container. Also useful for Kubernetes is what Brown called “initial support” for sharing network interfaces between containers; that will work with shared kernel containers in Nano Server 1709 but Hyper-V isolation containers in Server Core won’t get it until a later release. Mapping SMB volumes from file servers and named pipes will make it easier to connect storage to containers and have it remain accessible as containers move around.

Read More:   An Introduction to Queue Theory – InApps Technology

Adding the Windows Subsystem for Linux to Server Core hosts (though not Nano Server) will also be useful for scripts that handle containers. You can even use Linux containers to build Windows container images, and vice versa, giving you a lot of flexibility to work with the tools you want.

Going GUI

Nano Server has always had a GUI — of sorts. The Azure Server Management Tools gave you the traditional task manager, registry editor, control panel, performance monitor, disk management, user and groups management, device manager, file explorer and even Hyper-V management through a web interface. It worked with Nano Server, Server Core and Server with the full desktop experience, all the way back to Windows Server 2012, but you needed both an on-premises gateway and an Azure account to use it. That service never came out of preview (so it was never supported for production workloads — previews are ‘use at your own risk’) and Microsoft is discontinuing it as of June 30, 2017.

That doesn’t mean Microsoft thinks you don’t need a GUI for troubleshooting. “We got a lot of feedback saying ‘we think the functionality is really neat but it would be great if you didn’t force us to go through Azure to get back to our on-premises stuff,” Van Wesep told us. He promised more information about what will replace SMT at the Ignite conference in September, but there will definitely be options. “We’re dialed into customers saying ‘If you’re going to keep pushing GUI-less things then you should give us a nice way to interface with them’.”

Nano Server and Server Core will both be part of the new Semi-annual Channel, getting updates twice a year. You need Software Assurance to get those updates — or to be using Azure or a hosting provider that provides them. Server Core is also available as Long Term Servicing Channel (which is the only way you can get Windows Server with Desktop Experience). That’s because the container model Nano Server is now aimed at is still evolving and new features will arrive regularly.

If you want to run containers and container orchestrators on your own infrastructure rather than handing over the update work to a cloud provider like Azure Container Service, you need to be prepared for regular updates.

Nano Server and (if you want) Server Core will get updated every six months through the Semi-annual Channel (credit Microsoft)

Six-monthly updates should be less work for DevOps teams to adopt than big updates every three years, Brown suggested. “When we have long release cycles, a lot of stuff changes and it takes a long time to validate it and certify it and get it into production. A shorter release cycle should be a lot easier.” In general, he noted that the developer audience is more open to updating Windows Server frequently than admins running infrastructure roles like Active Directory, “as long as you give me new features.”

And Nano Server is proving very popular for containers, he told us. “We’ve got crazy Nano Server adoption for containers; the numbers are shockingly high.”

Feature image via Pixabay.

InApps Technology is a wholly owned subsidiary of Insight Partners, an investor in the following companies mentioned in this article: Docker.

Source: InApps.net

Rate this post
As a Senior Tech Enthusiast, I bring a decade of experience to the realm of tech writing, blending deep industry knowledge with a passion for storytelling. With expertise in software development to emerging tech trends like AI and IoT—my articles not only inform but also inspire. My journey in tech writing has been marked by a commitment to accuracy, clarity, and engaging storytelling, making me a trusted voice in the tech community.

Let’s create the next big thing together!

Coming together is a beginning. Keeping together is progress. Working together is success.

Let’s talk

Get a custom Proposal

Please fill in your information and your need to get a suitable solution.

    You need to enter your email to download

      Success. Downloading...