Blog Azure Cloud Native Infrastructure Modernization

Windows containers in a Linux world

A common question when someone is looking into transforming/containerizing their solution is “I’m now running on a Windows-based system; do I use Windows containers, or do I go with Linux containers?”. And that is a very valid question. We'll try to answer this very question in this article. 

A common question when someone is looking into transforming/containerizing their solution is “I’m now running on a Windows-based system; do I use Windows containers, or do I go with Linux containers?”. And that is a very valid question. Long story short: Go with Linux containers if you can. But that’s not always reality, is it? What if you already have spent years developing your current solution and the software stack you are using isn’t supported or doesn’t work as well on a Linux-based system? Then Windows containers might just be a solution for you.

Windows containers in the container ecosystem

Windows containers have gotten a lot of comments and are even made fun of (even by me) but, it’s not a fair comparison. Linux containers have been around for a long time and are usually the standard you would go with if you are starting from scratch. With the release of cross platform .Net versions, the Linux use case for companies became even bigger. With .Net being cross-platform it made it very easy to containerize your solution based on Linux.

As mentioned in the introduction, a lot of companies have legacy code based on different stacks. Take .Net Framework for example. If you spent years developing in .Net Framework and your migration path to a modern .Net version to support multiple platforms will take months of development effort, you are unlikely to do that. It is too big of an investment or too big to oversee at least. If you still want to containerize your solution to add more scalability and force standardization (more on this later) then Windows Containers will be a very good fit for you.

How Windows containers differ from Linux containers

You wouldn’t have guessed it but they differ quite a bit. Yes, you’re still writing a Dockerfile, building it, and running your container but that’s where it stops. Before you get started with Windows containers we highly recommend you read up on the concepts, the limitations, and their capabilities here.

The operating system

Well first of all... It’s a different operating system. But that does mean something. Where we are used to having a wide variety of options for images when it comes to Linux containers. With Windows containers that’s a different story. There is a strong link between the container OS and the Host OS and you are advised to make them match to prevent combability issues. These requirements become even more important when you use process isolation. Microsoft has released these guidelines to determine which image is best for the scenario. Having the correct base image matters.


Where did my Graphical User Interface go?

Yes, it is not really a difference but it’s something worth mentioning if you’re used to running your solution on Windows. When it comes to containers, there is no GUI. Now you might be thinking “Yes Captain Obvious we know” but hold on! In a Linux ecosystem, we are used to working from the command line but from Windows.. Not so much. Yes, we use PowerShell but how many of your applications are you actually installing from the command line? Exactly.

If you were to containerize your Windows Application that means everything needs to be running from the command line and through the Dockerfile. This might sound like a limitation, but the opposite is true. You are going to standardize and script your deployments! Sometimes that means you need to change some things in your installer or get rid of it altogether if it doesn’t support any command-line options and sometimes, you’re already good to go.

Image sizes

I’m not going to state that Windows containers are “slower” because really when it comes to the runtime itself, they don’t have to be. The biggest difference is the container image. Windows images are larger than Linux images. When you run your container the Docker image is downloaded and it takes a bit longer than downloading a Docker image based on Linux. If you take that into account and pick the correct image for your workload it shouldn’t be too much of a problem.

Then there are also recent developments that might take away this difference or minimize it to a point where you no longer care. Take a look at Artifact Streaming. Once supported, in a world of Windows containers, this will be a big win.

I’m using Azure Kubernetes Services, now what?

Good question! Easy and honest answer! Kubernetes supports the use of Windows node pools. That means when you’re installing AKS you can have one or multiple node pools. Those node pools can be Windows. Do note that you always need a Linux node pool as well. The default node pool is also where the services required for the cluster to function are hosted, these are based on Linux.

That means, if you’re going for Windows containers, you’ll have a minimum of two-node pools. Just as with Linux node pools, these are managed by AKS itself and you don’t have to worry about them too much. If you do want to troubleshoot the nodes you can access them through RDP (the node, not the container!). Alternatively we can also SSH into the Windows Node (this will be the best practice going forward). 

You don’t need to access the nodes to install or approve Windows updates. On node pools Windows update is disabled. Instead, you can upgrade your Windows node pool just as any other node pool.

Other than that, most features are supported for Windows containers. Things like persistent storage networking (CNI) are there and ready for you to use. If you want to dig into the technicalities of what’s different and what the limitations are please check the official Kubernetes project documentation.

The use case for Windows containers

Back to the beginning. What really is the use case for Windows containers? I see multiple scenarios happening in practice. One is where scaling and standardization is a big ask. If you run a legacy application based on Windows and you’re eager to add more scalability and standardization then containers are overall a good way to distribute your app (Note that if you’re going all in on containers these shouldn’t be your only motivations). If you’re eager to get rid of that IIS app on a virtual machine that you deploy for every new customer then Windows containers might just be the answers you’re looking for.

Then I’m also seeing a common scenario where customers are transitioning to containers but not everything is optimized for use on Linux containers just yet. This is where the use case of multiple node pools comes in very handy. Let’s say you’re transforming to containers and a modern .Net version while you’re at it. Maybe some parts of your solution require a bit more work to transform (let’s assume those parts are dependent on Windows). You no longer have to wait, and you can start to use AKS right now. Those Windows containers will eventually be transformed/rebuilt into Linux containers but the development investment doesn’t have to take place right now. Maybe you’re happy with the hybrid Windows / Linux scenario and you’ll let it run for quite some time… Or not. Both are an option but having the ability to choose between the types of operating systems is a game-changer when it comes to the container ecosystem.

Yes, they are different but if you follow the rules (limitations) and use cases this can work out well for you.

Presentation Simon

Visit our AKS workshop!

Learn even more about AKS through our interactive AKS workshop. In 1.5 hours you will receive the benefits and best practices to make your environment more efficient.

Azure Kubernetes Services (AKS)