Azure and OMS – Better Together

Azure and OMS – Better Together

Recently, Microsoft announced an enhancement to both Azure and OMS where you can now simply enable the OMS extension for your virtual machines and they will start to report directly to the OMS Workspace associated with that subscription.

In this blog post, I will walk you through a real-world example on how we integrated OMS with Azure to ensure availability for some Windows Server Containers as part of a project.

Overview

We wanted to be able to rapidly test and deploy Windows Server containers to Azure using Azure Resource Manager templates. This would of course lead to development of one or more ARM templates, leveraging custom script extension to perform the heavy lifting within the virtual machine(s).

If you are familiar with container technology and have followed the investment from Microsoft in this area lately, you have probably heard of the Azure Container Service that now is in the public preview. This is an end-to-end solution that you can spin up in Azure using a very abstracted template that will instantiate around 23 resources for you.

If you want to achieve the same with Windows Server Containers today, you must rely on your own ARM skills to make this happen, as the current Container Service is Linux-only.

Container technology is an additional layer of abstraction that you can host on a virtual machine, and whatever you put inside a container today should either be considered as stateless, or you should have externalized the state through the application layer.

In our case we were using stateless containers that would go down in case the container host (the virtual machine) went down or had a reboot in Azure.

With the capabilities available in Microsoft OMS today, this should be a real good use case to combine resources in Azure and OMS to ensure that if the specific event occurred, the container should be running and respond to requests in minutes.

Understanding the requirements

Windows Container is a part of Windows Server 2016 Technical Preview 4 today, which is an available image for you to use in Azure.

Although there’s two supported runtimes for containers in 2016, only Windows Server – and not Hyper-V Containers is supported, as the latter requires support for nested virtualization.

Further, the image in Azure is running Server Core – which also applies to the Windows Server Containers you can host there. In other words, there’s no graphical user interface J

When you use the image in Azure, you will get a default – empty Windows Server Core Image to use for your container exploration. If you want to add applications, server roles and more to a container, you need to be aware that you should treat your containers as Lego blocks.

In our case, there was a need to test several specific Web applications hosted on a Windows Server Containers.

This meant we had to build something that would spin up a new container image, add the Web-Server Role to it, and commit the container to the library as an image so that we could use that image when deploying the web applications on top of it.

From an ARM template perspective, that would mean that we would add a Custom Script Extension resource and associate it with the virtual machine resource.

The Custom Script Extension would then point to a repository that contains the script (PowerShell script in this case). The PowerShell script would support several input parameters so that the entire ARM template would be reusable for others who would like to deploy something similar in the same fashion.

The script would spin up and create containers, and ensure that the correct firewall settings and NAT rules were applied from the container host to the container(s), so the container could be publicly accessible from the outside, following the rules that were defined in the Network Security Group in the template.

So far, so great

From a deployment perspective, this should be good.

Since containers aren’t the same as virtual machines as you can run on your local Hyper-V, you will not get anything that reminds you of Live Migration in the current build. So for us to increase uptime and availability for the containers on the container host, OMS became very interesting.

With the OMS extension, we could easily associate the virtual machine with an OMS Workspace to retrieve critical information about our containers runtime environment.

Not only do we get the insight of our environment in OMS, but we can also leverage the agent to invoke another powerful Azure/OMS resource – Azure Automation.

The goal was now to monitor the virtual machine for specific events, and if the Log Search query would return such result in a given timeframe, we would link that result to an alert we have created in OMS.

From there, we could do remediation through an Azure Automation Runbook.

Since this was an event that was going on inside the operating system of the virtual machine, a Hybrid Worker was considered as the best solution, so that we could trigger Azure Automation to invoke the runbook within the Hybrid Worker context.

Since the OMS agent is also the same agent you would use for Hybrid Worker to Azure Automation, we only had to tell the agent where to register post deployment.

In order to handle this, another Extension (OMS agent) was added to the ARM template, instructed to be deployed before the Custom Script Extension who now also would be responsible for registering the OMS agent with Azure automation.

OMS

Generally speaking, people seems to be confused when it comes to OMS at its capabilities.

Out of the box you get an extreme amount of intel that you can leverage to act upon and become predictive in the way you do management of your resources, regardless of cloud, operating system and location.

This is brought to through Log Analytics, which now is a resource within the Azure Resource Manager API. Together with Log Analytics, you can use Azure Automation (tight integration) as well as Azure Site Recovery and Azure Backup – both who will reach the UX experience in the new portal in the near future.

Once you have connected sources to OMS, the data harvest can begin.

You can decide what type of data you will gather, and you can take advantage of existing solutions from a ‘Solution Gallery’ that gives you pre-defined searches, views and insight based on the solution it represent. Examples here are:

·         Change tracking

·         Security and Audit

·         System Update & Assessment

·         SQL Assessment

·         AD Assessment

·         Malware Assessment

These are just a few examples, and by using OMS – which is Management as a Service delivered from the cloud, you can expect the cloud cadence to be applied to these solutions, reducing Time-To-Market and Time-To-Value which is very good for your business.

The Solution

Azure Resource Manager template

The example Azure Resource Manager Template I will describe here is constructed so that it currently takes input parameters for:

·         Containerhost (name of the virtual machine that will host the container(s)

·         Containername (name of the container to instantiate)

·         vmSize (SKU)

·         adminaccount (administrator account for the container host vm)

·         adminpwd (password for the admin account)

·         vNetName (name of the virtual network to be created)

·         OMSWorkspaceID (the ID for your OMS Workspace)

·         OMSWorkspaceKey (the primary key for your OMS Workspace)

·         AAEndpoint (the endpoint to your Azure Automation account)

·         Token (the primary key for your Azure Automation account)

The resources that will be deployed (in this specific order) are:

·         Storage accounts, public IP address, network security group and availabilityset are deployed in parallel

·         Virtual network will start deployment as soon as the network security group has completed

·         Virtual network interface will start deploying when virtual network and public IP address has completed

·         Virtual machine will start deployment once storage accounts and virtual network interface has completed

·         Virtual machine extension (OMS agent) will start deployment when the virtual machine has completed

·         Virtual machine extension (Custom Script Extension) will start deployment once the OMS extension has completed

·         Once everything has deployed, we should receive an output from the template that will give us the URL to the deployed container, available on port 80

OMS Search

For OMS to find relevant information, the following search was used:

Type=SecurityEvent EventID=4608 OR EventID=1100 "4608 - Windows is starting up." contp4 | Select Computer, Activity, TimeGenerated

This search is targeting the specific virtual machine running the containers.

From this search, an alert was created that was linked to a runbook I had created to start any containers that had State –eq “Off”.

The runbook should then be executed by a Hybrid Worker, which would be the container host itself.

Testing

To test and verify that things are working, we would trigger a restart of the virtual machine in Azure.

Once the virtual machine has started, we can see that the following event has been logged to our OMS Workspace

This also results in an e-mail notification according to our configuration, and should also generate a webhook to invoke the remediation runbook that’s created in Azure Automation

By hitting the ULR to my container again, I can verify it is responding on port 80 and is brought up again just as expected.

Hopefully you found this blog post useful to show some of the capabilities by leveraging Microsoft OMS together with Azure services.

In the next blog post, I'll cover the ideal setup for Microsoft OMS for Service Providers.

(The templates, scripts and examples will be live on my github.com/krnese account as soon as they are polished a bit. Check in there later or follow me on twitter @KristiaNese to get the latest updates)

Azure Windows Server Container with IIS

A couple of months ago, Microsoft announced their plans for Azure and containers where they would provide you with a first class citizen resource provider in Azure so that you could build, run and manage scalable clusters of hosts machines onto which containerized applications would be running.

What you also probably have noticed is that Microsoft is having an open approach to container management. In fact, the container service is currently based and pre-configured with Docker and Apache Mesos, so any tools you would prefer for management “should just work”.

This is a new game for me to play so I am learning a lot. J

In the meantime, I am also working a lot with Windows Server Containers in Windows Server Technical Preview 4 – which is an image that is available in the Azure gallery.

However, I wanted to extend the experience a bit and decided to create my own ARM template that will ‘mimic’ some of the functionality in the Azure Container Resource Provider, to actually instantiate a new container running IIS Web-Server and be available for requests.

The template will deploy:

·         A Vnet

·         Network interface

·         Public IP address with DNS (the DNS will be based on the hostname.region.cloudapp.azure.com and provided as output once the deployment has completed)

·         Storage account

·         Network Security Group to allow RDP to the host – as well as http

·         Virtual machine (based on the TP4 image)

o   Custom Extension that will:

§  Spin up a new Windows Server Container based on the existing image (server core)

§  Install Web-Server within the newly created container

§  Stop the container – and create a new container image

§  Deploy a new container based on the newly created container image

§  Create a static NAT rule and a firewall rule to allow traffic on port 80 to the container from the host

This is a working experiment and I am planning to extend the template with more applicable tasks as we move forward.

The template can be explored and deployed from this GitHub repo: 

https://github.com/krnese/AzureDeploy/tree/master/AzureContainerWeb 

Getting started with Containers in Azure

Recently, I had a presentation/workshop in Norway at a Docker conference (http://www.code-conf.com/day-of-docker-osl15/program/#knese )

This was quite a new audience for me and it was great to be the person who showed them what Microsoft is doing in the era of container technologies, using both Microsoft Azure and Windows Server 2016 Technical Preview 4.

The big picture 

One of the key things to point out is that containers are “just” a part of the big picture that we are seeing in these days.

The following graphic shows where we are coming from – and also where we’re heading.

Starting at the bottom, the early generation in this industry used to have a lot of physical machines to run their business. We all know that having workloads and applications on physical machines is not where we want to be today, because that is not flexible, scalable and for sure want do any good for our demand for utilization.

Above physical machines we can find machine virtualization. This should all be quite common now and we have been very good at virtualizing servers for quite some time. In fact, we are now not only virtualizing servers – but also the other infra components too, such as networks and storage.

Machine virtualization in this context is showing us that we are abstracting the compute resources from the underlying physical machine – which introduces us to the first stepping stones towards flexibility, scalability and increase the utilization.

Further, we have infrastructure hosting which can be seen as the early days of cloud, although the exact service model here is not defined. This means that “someone” would do the investment and ensure the required amount of capacity for you as a customer, and you can have your workloads and applications hosted in the hosting datacenter. This was machine virtualization at scale.

The next step is the more familiar service models we can consume from a cloud, such as Infrastructure as a Service, Platform as a Service and Software as a Service. Although these service models are different, they share the same set of attributes such as elasticity, self-servicing, broad network access, chargeback/usage and resource pooling. Especially elasticity and resource pooling is a way to describe the level of flexibility, scalability and utilization we can achieve. I expect you as the reader to be quite comfortable with cloud computing in general, so I won’t dive deeper into the definition at this point.

Next, we are now facing an era where containers are lit up – regardless whether you are a developer or IT-pro. Containers builds on many of the same principals as machine virtualization, where abstraction is key. A container can easily be lifted – and shifted to other deployment environments without having the same cost, luggage and complexity as a virtual machine – as a comparison.

In the Microsoft world we have two different runtimes for containers.

Windows Server Containers that are sharing the kernel with the container host which is ideal for scalability, performance and resource utilization.

Hyper-V Containers gives you the exact same experience, only that the kernel in this case isn’t shared among the containers. This is something you need to specify during deployment time. Hyper-V Containers will give you the level of isolation you require and is ideal when the containers aren’t trusting each other nor the container host.

Microsoft has also announced that they will come with their own Azure Container Service in the future, as a first-class citizen resource provider managed by ARM.

Last but not least, we have something called “microservices” on the top in this graphic. In the context of Microsoft we are talking about Service Fabric – which is currently a preview feature in Microsoft Azure today.

Service Fabric is a distributed system platform where you can build scalable, reliable and easily managed applications for the cloud. This is where we are really seeing that the redundancy, high-availability, resiliency and flexibility isn’t built into the infrastructure – but handled at the application level instead.

Service Fabric represents the next-generation middleware platform for building and managing these enterprise class, tier-1 cloud scale services.

From a Microsoft Azure standpoint it is also important that you know that “VM Scale Sets” (http://kristiannese.blogspot.no/2015/11/getting-started-with-vm-scale-sets-with.html ) is the IaaS that enables these PaaS services (Azure Container Service + Service Fabric).

Also, as part of Windows Server 2016 Technical Preview 4, we will be able to leverage Nano Server for containers too, so you can get the optimal experience for your born-in-the-cloud applications.

So, that was me trying to put things into context and why I spent some time that day to have a workshop on Containers using Azure.

Getting started with Containers in Microsoft Azure

The material I used for this workshop can be found in this public GitHub repo: https://github.com/krnese/AzureDeploy/tree/master/AzureContainer

I created an ARM template that will:

·         Create a new storage account

·         Create a new Network Security Group

o   Create a new vNet and associate the new subnet with the NSG

·         Create a new network interface

o   Associate the vNic with a public IP address

o   Associate the vNic with the vNet

·         Create a new virtual machine

o   Associate the VM with the storage account

o   Associate the VM with the network interface

o   Use Custom Script Extension that will create x amount of Windows Server Containers based on the parameter (count) input

 

If you deploy this from GitHub and follow the ps1 examples you should be able to simulate the life-cycle of containers in Windows Server 2016 TP4.

Explaining Windows Server Containers - Part Three

In the last blog post, I talked about the architecture of container images and how to use them in a similar way like our kids are using Lego.

Today, I want to shift focus a bit and talk more about management of container life-cycle using Docker in the Windows Server Technical Preview 3.

If you have any challenges or problems in your IT business today and ask me for advice, I would most likely point you to something that adds more abstraction.

Abstraction is key, and is how we have solved big and common challenges so far in this industry.

When we covered the architecture of containers in part 1, we compared it with server virtualization.

Both technologies are solving the same challenges. However, they are doing it at different abstraction layer.

With cloud computing we have had the IaaS service model for a long time already, helping organization to speed up their processes and development by leveraging this service model either in a private cloud, public cloud or both – in a hybrid cloud.

However, being able to spin up new virtual machines isn’t necessarily the answer to all the problems in the world.

Sure it makes you more agile and let you utilize your resources far better compared to physical machines, but it is still a machine. A machine requires management at the OS level, such as patching, backup, configuration and more.  Since you also have access at the OS level you might end up in a situation where you have to take actions that involves networking as well.

This is very often where it get complex for organizations with a lot of developers.

They need to focus, learn and adopt new skillsets, just to be capable of doing testing of their applications.

Wouldn’t it be nice if they didn’t have to care about this jungle of complexity at all, knowing nothing about the environment they will be shipping software into?

Given the fact that there’s different peoples involved when it comes to software development and managing the environment of the software, the challenges grows together with the organization itself and scale becomes a problem.

This is where containers comes to the rescue – or do they?

Containers has a good approach since all applications within a container look the same on the outside from the host environment perspective.

We can now wrap our software together within a container and ship the container image to a shared repository and don’t deal with any of the complexity that a managed OS normally require from us.

I have seen this in action, and here’s an example that normally trigger people’s interest:

1)      A developer create something new – or simply commit some changes to their version control system (GitHub, VSO etc).

2)      A new image (Docker in this case) is built with the application.

3)      The new Docker image goes through the entire testing and approval process.

4)      The image is committed to a shared repo.

5)      The new Docker image is deployed into production.

This seems like a well-known story we all have heard in the IaaS world, right?

Please note that no infrastructure was touched from the developer perspective during these steps.

This was just one example of real world organizations are using containers today, and I will cover more good use cases as we move forward in this blog series.

It is important that we’re honest and admit that new technologies that gives us more and more capabilities, features and possibilities, will at the same time introduce us for some new challenges as well.

With containers, we can easily end up in a scenario where the situation can remind us a bit about the movie called “Inception” ( https://en.wikipedia.org/wiki/Inception ). It might be hard to know exactly where you are when you are working - and have access to all the different abstraction layers.

In Technical Preview 3 of Windows Server 2016, Windows Server containers can be managed both with PowerShell and Docker.

What exactly is Docker?

Docker has been around for years and ensures automated deployments into containers by providing an additional layer of abstraction and automation of OS virtualization on Linux, MAC OS and Windows.

Just as with Windows Server containers, Docker provides resource isolation by using namespaces to allow independent containers to run within a single Linux instance, instead of having the overhead of running and maintaining virtual machines.

Although Linux containers wasn’t something new, it had been around for years already, Docker made those Linux containers become available for the general IT guy by simplifying the tooling and workflows.

In Windows Server 2016 TP3, containers can be deployed by both Docker APIs and the Docker client, and Windows Server Containers. Later, Hyper-V containers will be available too.

They important thing to note is that Linux containers will (always) require Linux APIs from the host kernel itself, and Windows Server Containers will require Windows APIs from the host Windows kernel. So although you can’t run Linux on Windows or vice versa, you can manage all of these containers with the same Docker client.

So getting back to the topic here – how to do management of containers?

Since Docker was first, this blog post will focus on the management experience by using Docker in TP3.

Note: In TP3, we are not able to see nor manage the containers if they are created outside of our preferred management solution. Meaning that containers that are created with Docker can only be managed by using Docker, and containers created with PowerShell can only be managed by using PowerShell.

During my testing on TP3, I have run into many issues/bugs when testing management of containers.

In the following recipe, I would like to point out that the following has been done:

1)      I downloaded the image from Microsoft that contains the Server Core image with the running container feature in addition to Docker

2)      I joined the container host to my AD domain

3)      I enabled the server for remote management and opened some required firewall ports

4)      I learned that everything I would like to test regarding Docker, should be performed on the container host itself, logged on through RDP

Once I’ve logged into the container host, I run the following cmdlet to see my images:

Docker images

This shows two images.

Next, I run the following cmdlet:

Docker ps

This will list all the containers on the system (note that Docker is only able to see containers created by Docker).

The next thing I’d like to show off, was how to pull an image from the Docker hub and then run it from my container host. First I get an overview of all the Images that’s compatible with my system:

Docker search server

I see that Microsoft/iis seems like a good option in my case, so I run the following cmdlet to download it:

Docker pull Microsoft/iis

This will first download the image and then extract it.

In the screen shot below, you can see all the steps I have taken so far and the output. Obviously the last part didn’t work as expected and I wasn’t able to pull the image down to my TP3 container host.

So heading back to the basics then and create a new container based on an existing image.

Docker run –it –name krnesedemo windowsservercore powershell

This will:

1)      Create a new container based on the Windows Server Core image

2)      Name the container “krnesedemo”

3)      Start an interactive PowerShell session since –it was specified. Note that this is one of the reasons why you have to run this locally on the container host. The cmdlet doesn’t work remotely

This will literally take seconds, and then my new container is ready with a PowerShell prompt.

Below you can see that I am running some basic cmdlets to verify that I am actually in a container context and not in the container host.

Also note the error I get after installing the Web-Server feature. This is a known error in TP3 that you have to run some cmdlets several times in order to get the right result. Executing it the second time shows that it went as planned.

After exiting the session (exit), I will be back at the container host’s cmdline session.

I run the following cmdlet to see all the running containers:

Docker ps –a

This shows that the newly created container “krnesedemo” is running PowerShell in an interactive session, when it was started and when I exited it.

Now, I want to commit the changes I did (installed Web-Server) and create a new image with the following cmdlet:

Docker commit krnesedemo demoimage

In my environment, this cmdlet takes a few minutes to complete. I also experienced some issues when the container was running prior to executing this command. So my advice would be to run “Docker stop “container name” “ prior to committing it.

After verifying that the image has been created (see picture below), I run the following cmdlet to create a new container based on the newly created image:

Docker run –it –name demo02 demoimage powershell

We have now successfully created a new container based on our newly created image, and through the interactive session we can also verify that the Web-Server is present.

Next time I will dive more into the PowerShell experience and see how you can leverage your existing skillset to create a good management platform for your Windows Containers.

Explaining Windows Server Containers – Part Two

In Part One, I covered the concept of Containers, compared to server virtualization in a Microsoft context.

Today, I want to highlight the architecture of container images and how you can use them as building blocks to speed up deployment.

Before we start

If you have a background in Server Virtualization, you are probably very familiar with VM templates.

A VM template is a sysprep’d image that is generalized and can be deployed over and over again. It is normally configure with its required components and applications and kept up to date with the latest patches.

A VM template contains the complete operating system (and eventually its associated data disk(s)) and has been used by administrators and developers for years when they want do rapidly be able to test and deploy their applications on top of those VMs.

With Containers, this is a bit different. In the previous blog post I explained that Containers are basically what we call “OS Virtualization” and with Windows Server Containers the kernel is shared between the container host and its containers.

So, a container image is not the same as a VM image.

Container Image

Think of a container image as a snapshot/checkpoint of a running container that can be re-deployed many times, isolated in its own user mode with namespace virtualization.

Since the kernel is shared, it is no need for the container image to contain the OS partition

When you have a running container, you can either stop and discard the container once you are done with it, or you can stop and capture the state and modifications you have made by transforming it into a container image.

We have two types of container images. A Container OS image is the first layer in potentially many image layers that make up a container. This image contains the OS environment and is also immutable – which means it cannot be modified.

A container image is stored in its local repository so that you can re-use the images as many times you’d like on the container host. It is also possible to store the images in a remote repository, making them available for multiple container hosts.

Let us see how the image creation process works with Windows Server Containers

Working with Container Images

In the current release, Windows Server Containers can be managed by Docker client and PowerShell.

This blog post will focus on the PowerShell experience and show which cmdlets you need to run in order to build images, just as easy as you would do by playing with Lego J

First, we will explore the properties of a Container Image. An Image contains a Name, Publisher and a version 

We are executing - and storing the following cmdlet in a variable: $conimage = Get-ContainerImage -Name "WinSrvCore" 

Next, we create a new container based on this image by executing - and storing the following cmdlet in a variable: $con = New-Container -Name "Demo" -ContainerImage $conimage -SwitchName "VM". 

Once the container is deployed, we will start it and invoke a command that installs the Web-Server role within this container ( Invoke-Command -ContainerId $con.ContainerId -RunAsAdministrator { Install-WindowsFeature -Name Web-Server } ). You can see that the picture below shows that the blue Lego block is now on top of the brown one (as in layers). 

As described earlier in this blog post, we can stop the running container and create an image if we want to keep the state. We are doing that by executing New-ContainerImage -Container $con -Name Web -Publisher KRN -Version 1.0

If we now executes Get-ContainerImage, we have two images. One that has only the ServerCore, and another one that has ServerCore and the Web-Server Role installed. 

We will repeat the process and create a new container based on the newly created Container Image.

In this container, we will install a web application too. The grey Lego block on top of the blue shows that this is an additional layer.

We are then stopping the running container again and creates another container image, containing the web application too.

In the local repository, we have now three different container images in a layered architecture.

Hopefully you found this useful, and I will soon be back with part three of this blog series.

Perhaps you will see more Lego as well .... :-) 

-kn

Explaining Windows Server Containers – Part One

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.