Microsoft’s big cloud bet is hybrid cloud, services that can run either on-premises or in the cloud, or across both simultaneously. Central to this bet is support for container-based applications, where code and workload can run on your own servers or on Azure without requiring any modifications.
You can see much of what it does in its Azure Stack HCI and Azure Arc tools, which bring Azure cloud capabilities to on-premises systems that use Windows Server to host Azure services with virtual machines and containers . Both are built on Microsoft’s Hyper-V virtualization platform, host both Linux and Windows, and take advantage of features built into modern server hardware.
A quick guide to Windows containers
Much of what Microsoft does with on-premises Azure services is available to your own applications and tools because you’ll find that it uses standard Windows Server features. This means your own code can take advantage of Microsoft, especially when it comes to Windows container support.
We’re all familiar with containers in Linux and use tools like Docker to manage isolated application userlands. This approach ensures that all dependencies for an application can be managed and deployed along with the application while remaining separate from other applications, without having to run a full virtual machine for each application.
Windows works similarly to Linux for its standard container model, running a number of container management services inside Windows that control how application process containers interact with the Windows kernel. Because of these design decisions, Windows containers are more dependent on the host OS version than Linux containers and must be built on the same Windows version as the host.
You can work around this limitation by using Hyper-V containers, which run in the same virtualized environment as Windows VMs, but consume fewer resources. They are more secure and additionally isolated from running in Hyper-V. Your Windows Server license type determines how many containers you can run; With Datacenter you have an unlimited number of both types, while Standard keeps an unlimited number of process containers, it limits you to two isolated Hyper-V containers.
While Windows containers are quick to launch and easy to create and manage, they have one major disadvantage over Linux containers: since they all contain a base image, they can be large. Downloading a new Windows container from a remote repository every time you want to launch a new instance or apply an update takes longer than the Linux equivalent.
SEE: Settings Kit: Cloud Engineer (TechRepublic Premium)
Windows Server 2022 and containers
Microsoft has developed a new version of Windows Server, Nano Server, to keep the image size to a minimum and remove most non-essential services. While Nano Server is still the recommended base image for modern cloud-native applications where you need to quickly launch new nodes, if you’re lifting existing code and containerizing it, you’ll probably prefer to use Windows Server Core as the base image.
Windows Server Core is quite a bit larger than Nano Server, so Microsoft has worked to reduce its size significantly. Figures on the official documentation for Windows Server 2022 show a drop in size from just under 3.5 GB to around 2.75 GB. That’s a 33% reduction, resulting in a significant reduction in download times.
A key difference between these container base images and mainstream Windows Server is how they handle updates. Instead of using the traditional Windows update process, Windows container OS images are delivered in two parts: an RTM layer based on the Windows Server 2022 Core version, and a patch layer with all the latest patches and security fixes. The two are combined when an image is deployed, and while the RTM layer does not change size, the patch layer changes over time. Both are needed to deploy a container, so you need to consider the patch layer.
Alternatively, you can download a new base image every month from Microsoft’s own container registry. These contain all the latest updates and will be a smaller download. Microsoft’s own container images for .NET and for IIS are updated through the same process. At the same time, base image support lifecycles have improved and are now aligned with Windows Server 2022, with images supported through 2026.
Windows containers and Kubernetes
Microsoft uses Windows Server 2022 to introduce a new class of Windows containers. These new host process containers are designed to extend Windows support for Kubernetes and provide access to host server functionality including devices, storage, and networking. Instead of having to log into containers with administrator accounts to manage their Windows services, you can deploy Host Process Containers on all your Kubernetes clusters and manage them directly, using them as local or domain users based on the host server’s Active Directory membership to be executed.
Other new management tools, based on support for group managed service accounts, allow containers to work with Active Directory without requiring a managed host. Containers can work with a gMSA by using a secret store with the account information stored on the host, which can be populated without requiring the host to join the domain. This approach is useful when working with Kubernetes because it allows you to tie Active Directory membership to an application, not a server that exists solely to host a Kubernetes instance.
Running containers on Windows, particularly on Kubernetes with its tendency to run many small nodes on a single server, used to impact networking. Windows Server 2022 aims to reduce this by improving network scaling. These changes allow you to run hundreds of nodes on a single server while improving the performance of the Hyper-V virtual switch.
SEE: iCloud vs. OneDrive: Which is Best for Mac, iPad, and iPhone Users? (free PDF) (TechRepublic)
Optimization of container operations
An interesting Windows Server 2022 update for Windows containers is coming to Windows Admin Center. Here you can now quickly containerize ASP.NET applications directly from a Web Deploy package. This approach simplifies moving from developer tools to a container running on a server, automatically validating images, and pushing to an Azure Container Registry. You can use WAC to manage ACR instances and control containers running in Azure Container Instance from your on-premises servers, whether they’re running in Azure or on an Azure Arc managed system.
Another small but useful solution comes from virtualizing time zone support in Windows containers. Instead of being dependent on the host server’s time zone, they can now switch from the local time zone to a virtual time zone, allowing geographically sensitive code to support users’ time zones more effectively. You use PowerShell to set the container’s time zone when you first install it on your host, and this setting persists across reboots.
Windows Server 2022 continues to showcase Microsoft’s shift from traditional application hosting to its preferred hybrid cloud approach. With much of its work on Windows containers centered around working with Kubernetes, it’s clear that it sees the two technologies as a way to support modern applications both on-premises and in Azure. By giving you the tools you need to manage and support Windows containers on-premises with Windows Server, Microsoft is counting on you to first consider Azure Arc as a management and container-hosting platform for your code , aiming to move you to Azure Stack HCI first and finally to Azure. With Windows Server gaining features like this, it’s a bet it can certainly win.