Containers are one of the most significant new features in Windows Server 2016. They are also among the most confusing,...
for two reasons. First, although containers have existed in the open-source world for quite some time, they are a new concept to Windows. Second, Microsoft is simultaneously introducing two different types of containers: Windows Server Containers and Hyper-V Containers.
More powerful servers made virtualization possible
At one time, server hardware was relatively modest in its capabilities. Workloads needed dedicated hardware to run. Over time, server hardware became far more powerful; many applications consume only a small fraction of the resources that a modern server can deliver. Server virtualization was introduced to make better use of the hardware by allowing multiple workloads to run simultaneously within VMs. These VMs acted as isolation boundaries, with each virtual machine having its own dedicated operating system, virtual hard disk, memory allocation, etc.
Over time, the pendulum began to swing in the other direction. Whereas VMs were originally created to improve hardware utilization, users began spinning up so many VMs that the hardware once again became the limiting factor. A physical server can only host so many workloads before resources run out.
As server virtualization matured, hypervisor vendors looked for ways to increase the number of VMs that a physical server could accommodate. These vendors introduced features such as thinly provisioned virtual hard disks and memory overcommitment. Containers can be thought of as being similar to these types of features because they can help a server to accommodate additional workloads.
Containers trim virtualization bulk
This raises the question of how virtual servers and containers differ from one another. A virtual server is designed to be self-contained with its own operating system, applications and hardware resources. If a problem occurs inside of a VM, that problem would not affect other VMs because the virtual server acts as an isolation boundary.
The problem with VMs is they are larger than they really need to be. Think of an application server, for example. That application server contains the application and a dedicated operating system. This operating system consumes storage space, memory, CPU cycles and other hardware resources. While this might not be an issue for hosts with a small number of VMs, imagine if a host had to run a large number of VMs and all of those VMs were running the same operating system.
Containers seek to solve this size issue by using a single operating system instance that all the containers share. A container is similar to a virtualized application in that it stores the application's binaries and configuration files, but only stores operating system components the application modifies, such as registry entries or application specific drivers.
Why Microsoft offers container choices
Why is Microsoft introducing Windows Server Containers and Hyper-V Containers? There are a number of different answers to this question, but most come down to trust.
When Windows Server Containers are used, the containers leverage the host operating system. This might be OK for running trusted applications, but it would not be desirable for running an untrusted application. Hyper-V Containers provide an extra isolation boundary where each container has its own copy of the operating system binaries. The only real difference between a Hyper-V Container and a Hyper-V VM is that Hyper-V Containers can be managed by Docker, while Hyper-V VMs cannot.
Containers are a mechanism for improving efficiency through the sharing of operating system binaries. Not only does this approach improve host capacity, it also makes patch management easier because there are fewer operating systems to patch.
How to protect Hyper-V containers
Microsoft and Docker talk partnership
Microsoft jumps in with container technology