Microsoft’s big cloud bet is a hybrid cloud, services that can either run on-premises or in the cloud, or across both simultaneously. At the heart of that bet is its support for container-based applications, where code and workload can run on your own servers or on Azure without needing any changes.
You can see much of what it’s doing in its Azure Stack HCI and Azure Arc tools, which bring Azure cloud features to on-premises systems using Windows Server to host what would be Azure services, using virtual machines and containers. Both build on Microsoft’s Hyper-V virtualization platform, hosting both Linux and Windows, taking advantage of the capabilities built into modern server hardware.
A brief guide to Windows containers
Much of what Microsoft is doing with on-premises Azure services is available for your own applications and tools, as you’ll find it’s using standard Windows Server features. That means your own code can take advantage of what Microsoft is using, especially when it comes to supporting Windows containers.
We’re all familiar with containers in Linux, using tools like Docker to manage isolated application user lands. This approach ensures that all the dependencies for an application can be managed and delivered alongside the application, while keeping it separate from other applications without the overhead of running a full virtual machine for each application.
Windows works in a similar manner to Linux for its standard container model, running a set of container management services in Windows that control how application process containers interact with the Windows kernel. Because of these design choices Windows containers have more dependencies on the host OS version than Linux containers and need to be built on the same Windows version as the host.
You can get around this limitation by using Hyper-V containers which run in the same virtualized environment as Windows VMs but use fewer resources. They’re more secure, with additional isolation from running in Hyper-V. Your Windows Server license type will determine how many containers you can run; Datacenter lets you have an unlimited number of both types, while Standard keeps an unlimited number of process containers, it limits you to two Hyper-V isolated containers.
While Windows containers are fast to launch and easy to build and manage, they do have a major downside over Linux containers: as they all contain a base image they can be large. Downloading a fresh Windows container from a remote repository every time you want to launch a new instance or apply an update will take longer than for the Linux equivalent.
SEE: Hiring Kit: Cloud Engineer (TechRepublic Premium)
Windows Server 2022 and containers
Microsoft did develop a new version of Windows Server, Nano Server, to keep the image size to a minimum, stripping out most non-essential services. While Nano Server remains recommended as the base image for modern cloud native applications, where you need to start new nodes fast, if you’re lifting and shifting existing code into containers, you’re likely to prefer to use Windows Server Core as your base image.
Windows Server Core is quite a bit larger than Nano Server, so Microsoft has worked to significantly reduce its size. Figures on the official documentation for Windows Server 2022 show a drop in size from slightly under 3.5GB to around 2.75GB. That’s a 33% reduction, offering a significant reduction in download times.
One key difference between those 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 shipped in two parts: An RTM layer that’s based on the Windows Server 2022 Core release and a patch layer with all current patches and security fixes. The two are combined when an image is deployed, and while the RTM layer size doesn’t change, the patch layer will change over time. Both are needed to deploy a container, so you will need to take the patch layer into account.
Alternatively, you can download a new base image each month from Microsoft’s own container registry. These contain all current 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 life cycles have improved, and now align with Windows Server 2022, with images supported until 2026.
Windows containers and Kubernetes
Microsoft is using Windows Server 2022 to introduce a new class of Windows containers. These new Host Process Containers are designed to extend Windows support for Kubernetes, giving access to host server features, including devices, storage and networking. Instead of having to log into containers with admin accounts to manage their Windows services, you can deploy Host Process Containers to all your Kubernetes clusters and manage them directly, running as local or domain users based on the Active Directory membership of the host server.
Other new management tooling, based around support for Group Managed Service Accounts, allows containers to work with Active Directory without needing a managed host. Containers can work with a gMSA using a secret store with the account information held on the host, which can be populated without needing the host to join the domain. This approach is useful when working with Kubernetes, as it allows you to associate Active Directory membership with an application, not with a server that exists simply to host a Kubernetes instance.
Running containers on Windows, especially in Kubernetes with its tendency to run many small nodes on a single server, used to impact networking. Windows Server 2022 aims to reduce that by improving how it scales networking. These changes enable you to run hundreds of nodes on a single server, at the same time improving the performance of Hyper-V’s virtual switch.
SEE: iCloud vs. OneDrive: Which is best for Mac, iPad and iPhone users? (free PDF) (TechRepublic)
Streamlining container operations
One interesting Windows Server 2022 update to Windows containers comes in Windows Admin Center. Here you can now quickly containerize ASP.NET applications straight from a Web Deploy package. This approach simplifies going from developer tools to a container running on a server, automatically validating images and pushing them to an Azure Container Registry. You’re able to use WAC to manage ACR instances, as well as controlling 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 fix comes from virtualizing the time zone support in Windows containers. Instead of depending on the host server’s time zone, they’re now able to offset from the local time zone to a virtual time zone, so that geographically sensitive code can support users’ time zones more effectively. You’ll use PowerShell to set the container time zone when you first install it in your host, and this setting will persist across reboots.
Windows Server 2022 continues to show Microsoft’s shift from traditional application hosting to its favored hybrid cloud approach. With much of its work on Windows containers focused on working with Kubernetes, it’s clear that it’s seeing the two technologies as a way to support modern applications on both on-premises systems and in Azure. By giving you the tools you need to manage and support Windows containers on-premises with Windows Server, Microsoft is betting that you’ll consider first Azure Arc as a management and container hosting platform for your code, with the aim of moving you to first Azure Stack HCI and finally to Azure. With Windows Server gaining features like these, it’s a bet it may well win.