Windows Server Containers, what are they and where do they fit?

There are a lot of questions to be answered around Windows Server Containers. Two top questions are “what are they” and “where do they fit”. To answer these questions fully would require too much time and too much soapboxing for me to put in this blog post.  I’ll do that in a later post, but I think I can talk about containers at a light level to help start setting expectations.

What Are Containers?

If you search for “containers” online, you’ll learn that there are many cool ways to store household items and even better ways to ship large quantities of products quickly by sea. I think I might be buying a product to store my sweaters in a vacuum-sealed pouch under my bed, space saving indeed. J Interestingly enough, you’ll need to prefix your search with Windows or Linux to get meaningful details on server containers, but this folderol does bring up an interesting point: they are called containers because they are a method of packaging and delivering distributed applications quickly. This is not much different than if one is needing to get thousands of cow-shaped refrigerator magnets from Taiwan to Los Angeles quickly and safely using a shipping container. If you think of a custom application’s life cycle that requires many deployments weekly or sometimes daily to keep up with the changes, you can quickly see a fit for the idea of virtual containers.

I’ll try to sum up containers in a single paragraph, of course focusing on Windows Server Containers in particular. Windows Server Containers offer a higher level of isolation then normal processes running in Windows Server, by using new operating system technologies such as namespaces and enhancements to technologies such as job object. A container shares the host kernel but isolates the application from other containers and processes running on the server. This allows for a greater density of isolated applications running on a single host.

You say that containers sound cool, but not quite cool enough to sign up for using them just yet? No problem; let’s add in the fact that container packages are a layered approach to building up a deployable application, so simply speaking you can create an image that will host web sites which will include IIS and the new ASP.NET 5.0 software installed, and then developers can use that image to deploy applications, creating a new upper layer and test, tear down and test again. All this is done without changing the underlying layers. But here is the really cool part: you can then deploy that same package into production after accepting it in test and it will run the same way it did for the developer and testers. And for an added bonus, what if you can deploy this container in Azure or in your own data center without changing it?

Where do containers fit?

This question has been touched on a little in the above paragraphs, but to truly know where they fit may be easier to know where they aren’t a fit. First we need to think of containers as cattle not pets(I know some people have cattle as pets and some people don’t like the analogy, but hopefully you get the idea). The container doesn’t require the same type of care and feeding a server would; it may require a different level of care but certainly less feeding. What I mean by that is my application requires care and thought, and even the container’s layered images should be maintained, but I do that to a new package and kill the old package off when the new packages are ready to go. So containers are great cattle. With this in mind it’s easy to see that a stateless application is the way to go, at least any application which doesn’t attempt to store state in the container. Containers are also not a replacement for server desktop applications; they do not have Windows GUI capabilities because they contain only a limited OS. So, GUI-less applications are the place to be, or at least applications that do not run a GUI in the server’s process. Some applications like games and websites render on the local system not the server, so they make great examples of applications that are well-suited to containers.

If we add this all up and include the fact that Visual Studio extensions are available for VS 2015 to build out Docker files and integrate with Docker APIs, we can easily see that a custom LOB application in Dev/Test scenarios is a sweet spot. It’s worth noting that in Windows Server 2016 TP3 not all capabilities are turned on yet, and the more isolated (compared to Windows Server Containers) container model of Hyper-V partition separation is also not available yet. Why am I saying “Docker” all of a sudden? Well, Docker can be considered a container manager, occupying a management layer above the container itself. Although not required for Windows Server Containers, Docker offers value in many ways, like offering a central hub to share containers and an existing fan base of users.

Some interesting points

Since Windows containers are fairly new, the information is flowing and changing at a rapid pace. For now, there are some things to note and below there are a number of links to VERY useful information and samples with examples included there. It’s also important to remember that Windows Server Containers are a shared-kernel model of containment. This means two very important things. First, the base OS image that is managed by MSFT must mirror versions with the host. Second, a Windows container can’t share anything on a Linux kernel or visa-versa, so you can only have Windows Server Containers on a Windows Server host.

Why am I posting this? Just because! Well actually, I work with a lot of people testing and looking at new technologies, especially containers, and in some cases we start the conversation with a high-level overview such as this one, so I thought it would be worth sharing the same overview with a wider audience. Another reason is I would like to hear from more people about their experiences and use cases around containers, so feel free to reach out to me.