Microsoft’s big cloud bet is a hybrid cloud, services that can run on-premises or in the cloud, or on both simultaneously. At the heart of this bet is its support for container-based applications, where code and workload can run on your own servers or on Azure without requiring changes.
You can see a lot of what he’s doing in his Azure Stack HCI and Azure Arc tools, which bring Azure cloud functionality to on-premises systems using Windows Server to host what would be Azure services, using machines virtual and containers. Both are based on Microsoft’s Hyper-V virtualization platform, hosting both Linux and Windows, taking advantage of capabilities built into modern server hardware.
A Brief Guide to Windows Containers
Much of what Microsoft does with on-premises Azure services is available to your own apps and tools, as you’ll find it uses standard Windows Server functionality. This means that your own code can take advantage of what Microsoft uses, especially when it comes to supporting Windows containers.
We’re all familiar with containers on Linux, using tools like Docker to manage user areas of isolated apps. This approach ensures that all of an application’s dependencies can be managed and delivered alongside the application, while separating it from other applications without the overhead of running a full virtual machine for each application.
Windows operates similarly 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 are more dependent on the version of the host operating system than Linux containers and must be created on the same version of Windows as the host.
You can work around this limitation by using Hyper-V containers that run in the same virtualized environment as Windows virtual machines, but use fewer resources. They are more secure, with additional isolation against 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 isolated Hyper-V containers.
Although Windows containers are quick to launch and easy to create and manage, they have one major drawback compared to Linux containers: because 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 will take longer than the Linux equivalent.
SEE: Recruitment Kit: Cloud Engineer (TechRepublic Premium)
Windows Server 2022 and containers
Microsoft developed a new version of Windows Server, Nano Server, to keep image size to a minimum, removing most non-essential services. Although Nano Server is still recommended as a base image for modern cloud-native applications, where you need to start new nodes quickly, if you’re lifting and moving existing code into containers, you’ll probably prefer to use Windows Server Core as the base. image.
Windows Server Core is a bit larger than Nano Server, so Microsoft has worked to drastically reduce its size. Figures from the official Windows Server 2022 documentation show a drop in size from just under 3.5 GB to around 2.75 GB. That’s a 33% reduction, delivering a significant reduction in download times.
One of the main differences between these container base images and the 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 release and a patch layer with all of the fixes and fixes from current security. The two are combined when an image is deployed, and while the size of the RTM layer does not change, the patch layer will change over time. Both are needed to deploy a container, so you’ll need to consider the patch layer.
You can also download a new base image every 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 lifecycles have improved and now align with Windows Server 2022, with images supported through 2026.
Windows and Kubernetes containers
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, providing access to host server functionality including devices, storage, and networking. Instead of having to log in to containers with administrator accounts to manage their Windows services, you can deploy host process containers to all your Kubernetes clusters and manage them directly, running them as local users or as domain based on the Active Directory membership of the host server.
Other new management tools, based on support for group managed service accounts, allow containers to work with Active Directory without the need for a managed host. Containers can work with a gMSA using a secret store with account information held on the host, which can be populated without the host needing to join the domain. This approach is useful when working with Kubernetes because it allows you to associate Active Directory membership with an application, not a server that simply exists 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 this by improving networking scaling. These changes allow you to run hundreds of nodes on a single server, while improving the performance of Hyper-V’s virtual switch.
SEE: iCloud vs OneDrive: Which is better for Mac, iPad and iPhone users? (free PDF) (TechRepublic)
Streamline container operations
An exciting Windows Server 2022 update for Windows Containers is available in Windows Admin Center. Here you can now quickly containerize ASP.NET applications directly from a Web Deploy package. This approach simplifies moving developer tools to a container running on a server, automatically validating images and pushing them to an Azure Container Registry. You can use WAC to manage ACR instances, as well as 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 fix 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, so that geo-sensitive code can support user time zones more efficiently. You’ll use PowerShell to set the container’s time zone when you first install it on your host, and this setting will persist across reboots.
Windows Server 2022 continues to show Microsoft’s shift from traditional application hosting to its preferred hybrid cloud approach. With much of his work on Windows containers focused on working with Kubernetes, it’s clear he sees both technologies as a way to support modern applications on 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 you’ll first consider Azure Arc as a container hosting and management platform for your code. , with the goal of moving first Azure Stack HCI and finally Azure. With Windows Server gaining features like these, it’s a bet it just might win.
Comments are closed.