You have heard a lot about it lately, Microsoft is
speeding up on their container investment and we can see the early beginning in
Windows Server 2016 Technical Preview 3.
But before we start to go deep into the container
technology in TP3, I would like to add some more context so that you more
easily can absorb and understand what exactly is going on here.
Server Virtualization
Container technologies belongs to the virtualization
category, but before we explain the concept and technology that gives us “containerization”,
we will take a few steps back and see where we are coming from.
Server (virtual machine) virtualization is finally
mainstream for the majority of the industry by now.
We have been using virtualization in order to provide an
isolated environment for guest instances on a host to increase machine density,
enable new scenarios, speed up test & development etc.
Server virtualization gave us an abstraction where every
virtual machine were in the belief of that they had their own CPU, I/O
resources, memory and networking.
In the Microsoft world, we first started with server
virtualization using a type 2 hypervisor, such as Virtual Server and Virtual PC
– where all the hardware access was emulated through the operating system
itself, meaning that the virtualization software was running in user mode, just
as every other application on that machine.
So a type 2 Hypervisor have in essence two hardware
abstraction layers, turning them all into bad candidates for real world
workloads.
This changed with Hyper-V in Windows Server 2008, where
Microsoft introduced their first type 1 hypervisor.
Hyper-V is a microkernelized hypervisor that implements a
shared virtualization stack and a distributed driver model that is very
flexible and secure.
With this approach, Microsoft had finally a hypervisor
that could run workloads considered as “always-on” and also based on x64
architecture.
I don’t have to go through the entire story of Hyper-V,
but to summarize: Hyper-V in these days reminds you a bit of VMware – only it
is better!
As stated earlier, server virtualization is key and a common requirement for cloud computing. In
fact, Microsoft wouldn’t have such a good story today if it wasn’t for the investment
they made in Hyper-V.
If you look closely, the Cloud OS vision with the entire “cloud
consistency” approach derives from the hypervisor itself.
Empowering IaaS
In Azure today, we have many sophisticated offerings
around the Infrastrucutre as a Service delivery model, focusing on core compute,
networking and storage capabilities. Also, they have taken this a step further
where we can use something called VM extensions in our virtual machines, so
that during provisioning time – or post deployment, we can interact with the
virtual machine operating system to perform some really advanced stuff. Examples
here could be deployment and configuration of a complex LoB application.
Microsoft Azure and Windows Azure Pack (Azure
technologies on-prem) has been focusing on IaaS for a long time, and today we
have literally everything we need to use any of these cloud environments to
rapidly instantiate new test & dev environments, spinning up virtual
machine instances in isolated networks and fully leverage the software-defined
datacenter model that Microsoft provides.
But what do we do when virtual machines aren’t enough? What
if we want to be even more agile? What if we don’t want to sit down and wait
for the VM to be deployed, configured and available before we can verify our
test results? What if we want to maximize our investments even further and
increase the hw utilization to the maximum?
This is where containers comes handy and provides us with
OS virtualization.
OS Virtualization
Many people have already started to compare Windows Server Containers with technologies such as Server App-V and App-V (for desktops).
Neither of these comparisons are really true, as Windows Server Containers covers a lot more and has some fundamental differences when looking at the architecture and use cases.
The concept, however, might be similar, as App-V technologies (both for server and desktop) aimed to deliver isolated application environments, in its own sandbox. Things could either be executed locally or streamed from a server.
Microsoft will give us two options when it comes to
container technology:
Windows Server Containers and Hyper-V Containers.
Before you get confused or starts to raise questions: You can
run both Windows Server Containers and Hyper-V Containers within a VM
(where the VM is the Container host). However, using Hyper-V Containers would require
that Hyper-V is installed.
In Windows Server
Container, the container is a process that executes in its own isolated user mode of the operating
system, but where the kernel is shared between the container host and all of its containers.
To achieve isolation between the Containers and the
Container Hosts, namespace virtualization is used to provide independent
session namespace and kernel object namespace isolation per container
In addition, each container is isolated behind a network
compartment using NAT (meaning that the container host has a Hyper-V Virtual
Switch configured, connected to the containers).
For applications executing in a container process, all
file and registry changes are captured through their respective drivers (file
filter driver and registry filter). System state are shown as read-only to the
application.
With this architecture of Windows Server Containers, it
is very likely that this is an ideal approach for applications within the same
trust boundary since the host kernel and APIs are shared among the containers. Windows
Server Containers is the most optimized solution when reduced start-up time is
important to you.
On the other hand, we also have something called Hyper-V Containers (this is not
available in Technical Preview 3).
A Hyper-V Container provides the same capabilities as Windows
Server Containers, but has its own (isolated) copy of the Windows kernel and
memory directly assigned to them. There is of course pros and considerations
with every type of technology, and with Hyper-V Containers you will achieve
more isolation and better security, but have a less efficient start-up and
density compared to Windows Server Containers.
The following two pictures shows the difference between server
virtualization and OS virtualization (Windows Server Containers)
 |
| Server Virtualization |
 |
| OS Virtualization |
So, what are the use cases for Windows Server Containers?
It is still early days with Windows Server 2016 Technical
Preview 3 so things are subject to change.
However, there are things we need to start to think about
right now when it comes to how to leverage containers.
If you take a closer look at Docker (which has been doing
this for a long time already), you might get a hint of what you can achieve
using container technology.
Containers aren’t necessarily the right solution for all
kind of applications, scenarios and tools you may think of, but gives you a unique
opportunity to speed up testing, development and to effectively enable DevOps
scenarios that embraces continuous delivery.
Containers can be spun up in seconds and we all know that
having multiple new “objects” in our environment can also lead to a demand of
control and management that also introduces us for a new toolset.
I am eager to share more of my learning of Windows Server
Containers with you, and will shortly publish part two of this blog series.
No comments:
Post a Comment