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.
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. And 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.
As this is a series on Azure Kubernetes Services (AKS), we will look into the following topics:
Windows and Linux containers on Azure;
Differences between Windows Containers and Linux Containers;
Use cases in containerizing.
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 .Net Core the Linux use case for companies became even bigger. With .Net Core 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 spend a year developing in .Net Framework and your migration path to .Net Core will take months of development effort, you are unlikely to do that. 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.
Sign up for our Deepdive Azure Kubernetes Services (AKS)! Get more velocity, efficiency, and agility.
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 to 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 of 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. 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 project “Teleport” where the deployment of images is sped up immensely but transporting the layers instead of traditionally pulling the image. 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!).
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 Window 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.
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 really 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 .Net Core 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/rebuild 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 really 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 really well for you.
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. Through common AKS challenges, you will be ready for AKS. Click here for dates and register!
Kubernetes is “hot & happening”, almost every company already uses or wants to use Kubernetes. Creating an AKS-cluster seems easy enough, but what if you want to create an AKS-cluster for serious production workloads? In this article we will give you some pointers and best-practices which will help you create an AKS-cluster ready for production environments.
The evolution of AKS: from Containers to Kubernetes to Azure Kubernetes Service (AKS)
For some time now [Azure] Kubernetes is thé platform to orchestrate containers. Why is this and what are the benefits of using Kubernetes and managed Kubernetes (AKS)?
One of the motivations for using containers and Kubernetes I come across are “We want to be multi-cloud”. But how easy is it to achieve a hybrid or multi-cloud scenario?
This e-book gives you all the information you need to decide if Azure Kubernetes is a good match for your software architecture. We also tell you more about our best practices on security, update scenarios and monitoring and managing of AKS cluster (and many more!).
In this article I am going to go over a very important topic, updates. When I say updates, I am referring to not only Kubernetes updates, but also the worker node OS updates. Many people forget about patching the worker node OS believing that it is handle by Microsoft. This is not the case.
Many people talk about Microservices and Service Mesch, but what is this? In this article we'll look at what Microservices are, what a Service Mesh is and what you can do with it, and finally whether you really need it now.
You have a deadline and promised your customers to launch your new platform on a specific date, everyone is working hard and you’re barely meeting your target date. And then someone asks.. “What about security?”
Kubernetes is “hot & happening”, almost every company already uses or wants to use Kubernetes. Creating an AKS-cluster seems easy enough, but what if you want to create an AKS-cluster for serious production workloads? In this article we will give you some pointers and best-practices which will help you create an AKS-cluster ready for production environments.
Lead of DevOps at Intercept | Microsoft Azure MVP | CISSP | Spreker
Get in touch
Don’t be a stranger. Put our knowledge to the test, and get to know us a little better. We will have answers to your questions within one business day.
Kubernetes is “hot & happening”, almost every company already uses or wants to use Kubernetes. Creating an AKS-cluster seems easy enough, but what if you want to create an AKS-cluster for serious production workloads? In this article we will give you some pointers and best-practices which will help you create an AKS-cluster ready for production environments.
The evolution of AKS: from Containers to Kubernetes to Azure Kubernetes Service (AKS)
For some time now [Azure] Kubernetes is thé platform to orchestrate containers. Why is this and what are the benefits of using Kubernetes and managed Kubernetes (AKS)?
One of the motivations for using containers and Kubernetes I come across are “We want to be multi-cloud”. But how easy is it to achieve a hybrid or multi-cloud scenario?
This e-book gives you all the information you need to decide if Azure Kubernetes is a good match for your software architecture. We also tell you more about our best practices on security, update scenarios and monitoring and managing of AKS cluster (and many more!).
In this article I am going to go over a very important topic, updates. When I say updates, I am referring to not only Kubernetes updates, but also the worker node OS updates. Many people forget about patching the worker node OS believing that it is handle by Microsoft. This is not the case.
Many people talk about Microservices and Service Mesch, but what is this? In this article we'll look at what Microservices are, what a Service Mesh is and what you can do with it, and finally whether you really need it now.
You have a deadline and promised your customers to launch your new platform on a specific date, everyone is working hard and you’re barely meeting your target date. And then someone asks.. “What about security?”
Kubernetes is “hot & happening”, almost every company already uses or wants to use Kubernetes. Creating an AKS-cluster seems easy enough, but what if you want to create an AKS-cluster for serious production workloads? In this article we will give you some pointers and best-practices which will help you create an AKS-cluster ready for production environments.
