Hyper-V Containers

Traditionally applications are installed directly onto an operating system, be it on a physical machine or in the guest OS of a virtual machine. This 1:1 relationship has led to stability, but it causes some other issues, including:

  • Virtual machine and licensing sprawl
  • Increased maintenance
  • More stuff that can break
  • Slower deployment (as in P.I.T.A. documentation and implementation)

It is that latter point that has caught Microsoft’s attention. Microsoft wishes IT to be able to operate “at the speed of business”.  Deploying a machine, even a virtual one, is slow:
  •  A machine must be created
  •  The virtual hard disk(s) must be copied to the storage
  •  A guest OS must be specialized
  •  Additional configurations and management systems must be installed

Microsoft formed an alliance with Docker last year to bring application containers to the Microsoft stack. Docker is a leading player in the open source market of application containerization. The concept of containers changes how applications are deployed on servers. Instead of one OS for every app install, containers allow applications to run in a semi-isolated manner on a shared operating system. You can deploy physical machines or virtual machines as container hosts; obviously the virtual option offers more elasticity.

The benefit is that containers require few operating systems (and all the associated benefits of that), and they are very quick to deploy. Microsoft’s Mark Russinovich demonstrated this at TechEd last year when he deployed a working WordPress installation in one second.
Microsoft’s partnership with Docker led to:
  •  A windows management platform for Docker
  •  Docker-enabled Ubuntu virtual machine images being released in the Azure marketplace
  •  Microsoft contributing code to application container management

Most importantly, it led to Microsoft announcing that they would release Windows Server containers in Windows Server vNext.



 
There is some level of isolation between application containers. The applications on a common operating system are able to work independently of each other. But they do share a common operating system, and containers with similar binary and library requirements also share those dependencies. This means that there is no security isolation between Docker or Windows Server application containers. Three is potential for a breakout to the host OS and to other containers if one application is successfully taken over by an attacker. This is why Microsoft is also including Hyper-V containers in Windows Server vNext.


Hyper-V is a secure hypervisor, using both software and hardware dependencies to isolate child partitions. Microsoft will be using this security boundary in the next version of Windows Server to give you the option of isolating application containers using Hyper-V instead of the normal semi-isolation that will be offered by Windows Server containers. Code that is deployed to one container type will be compatible with the other.

The exact means of how Hyper-V will be used has not yet been revealed. However, Microsoft will talk more about and demonstrate Windows Server containers at Build, which runs from April 29th until May 1st in San Francisco.

The Vision;

There will be many ways to deploy applications in the future; traditional installs into physical or virtual machines, PaaS in Azure, IaaS in Azure, and application containers. Containers will offer speed and flexibility, and we will be able to deploy these securely in Hyper-V or into densely packed and remotely managed headless Nano Server installations. Docker will not only continue to manage open source application containers but it will also manage Windows Server containers and Hyper-V containers. The next year or so should prove to be very interesting!

Back to Blog