There are lots of technologies I’m not familiar with, but what I started noticing lately is that they have been evolving so fast that it’s sometimes difficult to even figure out a good starting point when trying to become more familiar with them.
Imagine waking up in the driver seat of a car moving at a relatively high speed without having any experience of driving a car at all. That’s definitely not a good way to start getting the experience – you’d probably want to learn some basics on the parking lot first.
Unfortunately, this is how I often feel now when looking at another technology, windows containers included. You keep hearing about docker containers, so one day you decide to take a closer look, and the feeling is exactly that – it’s the feeling of waking up in the moving car when you have no idea of even where the steering wheel is.
I’ve spent several hours trying to get through all the posts describing containers technology in the last few days, and, then, realized that a few things which are often mentioned simply add to the confusion. That’s until most of it finally came together, so, if you are in the same boat(or car) this post might help you, too. Just keep in mind I’m looking at the containers from the Windows perspective.
- Conceptually, containers are application deployment packages which include more than just the application itself. They also include the dependencies required to run the application, and all that comes with the high level of isolation. Sounds like a virtual machine? Well.. keep reading
- Docker has been one of the leading technologies behind containers, though, until a few years ago it was mostly about Linux (then, again, Docker has been around for only 5 years so far)
- You may hear that containers are not virtual machines since they rely on the OS-level virtualization(so they are not supposed to be running their own independent OS per se). It seems that’s how it used to be in the Linux world.. until Microsoft (and Docker) decided to throw in Windows containers, and that’s where things started to get wild
With the OS-level virtualization the idea used to be that an application running in the container would still be using host operating system. From the application standpoint, everything would look quite isolated, but, in the end, that would be the main reason why running a Linux container on the Windows host system would not be possible. You can’t make Windows look like Linux, after all.
And, then, we got two types of containers in Windows. There are windows containers(those are classic OS-level containers), and there are Hyper-V containers. The latter are probably called “containers” since they still work like any other Docker container from the Docker standpoint. But, technically, they are running as virtual machines (presumably highly optimized, but still). For example, you can run a windows containers on Windows 10, and your container can be using windows server 2016 OS.
At this point, you may want to look at these 3 articles/posts – there is lots of information there, but it should help you get your head around the main concepts, at least:
Now, containers are great, but you need tools to deploy the containers, to monitor them, to automate various deployment steps, etc.
This is where we need to start looking at the frameworks like Kubernetes:
There are others, such as Docker Swarm. But Kubernetes is the main one at this point.
Let’s say we have containers and we have some kind of framework to manage their deployment. Where are we going to deploy them, though?
This is where three leading cloud companies (Microsoft, Google, and Amazon) have something to offer, and, if you are trying to compare those offers, have a look at this post:
At this point I would assume that, if you are are using one of those clouds for something else, you might choose a corresponding Kubernetes implementation from the same vendor. In other words, if you are a Microsoft customer utilizing various cloud services from Microsoft, look at the AKS first, since it’ll be using Azure infrastructure when deploying the containers.
Also, if you run into the term “Azure Container Services”, have a look at this post to see why it’s no more.. IT’s, now, “Azure Kubernetes Service”
Now what about the size of windows containers? The size of base windows containers varies from a few 100 MB-s to tens of GB-s, which you will see from the post below:
The same post actually describes a few other useful concepts, such as containers upgrade cadence.
Microsoft has its own introduction into Containers, which is really useful, though it is focused on the Windows Containers and does not expand on how they are related to the containers in general:
So, from the Windows Containers standpoint, how does the licensing work? There is an answer here:
The way I see it, we don’t need to licence containers themselves, but, depending on the licence we have for the host system, we get different rights for the containers running on that host system.
And, finally, what is the main use case? Why not to use applications,
There is more reading, though:
I am still not clear on what is the perfect use case for Windows Containers. It seems there are only two base images (windows server and nano), so, by packaging our apps into windows containers, we are simply saying that we’ll be using one of those two versions of the operating system, and, of course, we add quite a bit of “fat” around our applications. Since it’s not just the application code that we need to install now. Why not to use a virtual machine and deploy multiple apps on that machine then? Would not it actually save the resources and/or time?
You can look at these two posts to get an idea of the answer:
To me it seems that containers belong somewhere in between the Virtual Machines and old-fashion application deployment models. If you were to provide full VM for each of your applications, that would be one way to do it, but that would take a lot of resources. You’ll have great isolation and packaging, though. If you were to deploy an application directly on the host system, that would take the least amount of resources from the host, but that would provide the least level of isolation and/or packaging. In both cases when saying “packaging” I just mean that every application has some dependencies. For example, a web application requires some kind of web server. Different web applications may require different web servers, etc.
Containers are somewhere in between. You can package the app itself and all required components into one single container, then take that container and move it between different environment as is. Compared to a VM, you are not really getting a dedicated machine, but, compared to a single app, you are getting all the dependencies embedded into the container.
Hope that helps. Any additions/clarifications/corrections? Let me know..