In-Depth
Containers vs. Virtual Machines
The release of Windows Server 2016 will bring a new option of building apps based on micro-services that run in Docker and other standard containers. Does that portend the end of the VM?
- By Michael Otey
- 09/06/2016
The rise of containers that run small components known as micro-services has generated a lot of buzz in the trenches of enterprise IT over the past two years because of the potential model for how organizations architect infrastructure and build applications. Containers make it easier to help accelerate the move to the DevOps model. Although containers have been around for a while in the Linux world, they're new to Windows, set to debut with this fall's Windows Server 2016 release. Many organizations are looking at embracing containers, especially those with business imperatives that require a more agile approach to responding to the whims of customers, partners, suppliers and even employees. Nearly every major IT player has latched onto the open source container movement driven by Docker Inc.
At the recent DockerCon 16 conference in Seattle, Wash., 4,000 clearly eager attendees learned how containerized micro-services will set the stage for how the generation of applications are designed, built, deployed, and managed, ideal for serving the needs of organizations and ISVs alike who want to build cloud-native apps or bridge legacy software into this new world.
These emerging micro-services applications are often referred to as Mode 2 apps, which consist of lightweight containers running small apps or networked micro-services. This new style of application is expected to replace the heavyweight monolithic apps that today run in virtual machines (VMs). Does that mean containers will replace VMs? After attending the two-day DockerCon in late June, I can explore how containers and containerized applications compare to VMs running traditional applications and how Windows Server 2016 and a revamped Hyper-V will raise this question.
Windows Container Types
First, let's take a quick look at the forthcoming Windows Server Containers. Basically, a container is an isolated space where an application can run without affecting the rest of the system or other containers. Unlike VMs, which are all essentially the same, there are two types of containers in Windows Server 2016:
- Windows Server Containers: Running directly on top of the Window Server OS, Windows Server Containers provide application isolation through process and namespace abstraction. All Windows Server Containers share the same kernel network connection and base file system with the container host.
- Hyper-V Containers: More secure than Windows Server Containers, Hyper-V Containers each run in a highly optimized VM. With Hyper-V Containers the kernel of the container host isn't shared with the Hyper-V Containers. Instead, the container uses the VM's base OS. This provides a more secure environment as the containers are isolated from the underlying host, but have more overhead.
The Windows Server Containers themselves are compatible with Hyper-V Containers and other Windows Server Containers. The new Nano deployment option for Windows Server is intended as a platform for running containers.
Container and VM Architecture
Containers have been called the next generation of virtualization because they provide application abstraction in much the same way that VMs provide hardware abstraction. Instead of virtualizing the hardware like a VM, a container virtualizes at the OS level. Containers run at a layer on top of the host OS and they share the OS kernel. Containers have much lower overhead than VMs and a much smaller footprint. You can see the Windows Server Container and Hyper-V Container architecture in Figure 1.
[Click on image for larger view.]
Figure 1. The Windows Container Architecture
As illustrated, the VMs run on top of a hypervisor that's installed directly on the bare-metal system hardware. Each VM has its own emulated hardware, OS and applications. VMs can be paused, stopped and started. They can be moved between virtualization hosts without any end-user downtime by using technologies such as live migration or vMotion.
Containers are quite different. The container runtime is installed on top of the host OS and every containerized appliÂcation shares the same base underlying OS. Each container is isolated from the other containers. Unlike VMs where each VM has its own individual kernel and OS, containers share the same kernel, network connection and base file system as the underlying OS. You don't need a whole new and separate OS, memory and storage as you would for a VM. Because containers don't have to emulate physical hardware and the entire OS, they're far smaller and more resource-efficient than VMs.
Container and VM Storage
By now most people are familiar with VM storage. With VMs one or more virtual disks provide the storage for the VM. There are different types of fixed virtual disks. VMs have dynamic, fixed and differential virtual disks. In each case they're stored as a file on the virtualization host or on a shared storage location. The VM sees virtual disks as different OS drives.
Container storage is quite different. Containers don't use virtual hard drives. They're designed to be stateless, easily created and discarded. Containers use a concept commonly called sandboxing to isolate any disk writes from the underlying host. Once a container has been started, all write actions such as file system modifications, registry modifications or software installations are captured in this sandbox layer (see Figure 2).
[Click on image for larger view.]
Figure 2. Container Storage Overview
In the center of Figure 2 you can see a running container built from two separate container images. The container would see these as separate directories. These images are unchanged when the container runs. All of the container changes are captured in the sandbox and by default would be discarded when the container is stopped.
That all sounds great, but what if you want to persist the changes made from a container? There are a couple of ways that storage changes are persisted using containers. You can save your container with its changes as a new image or you can mount an existing directory from the host on the container.
You can mount a volume using the -v parameter of the Docker run command. This will enable all files from the host directory to be available in the container. Any files created by the container or changes to files in the mounted volume will be stored on the host. You can mount the same host volume to multiple containers using: docker run -it -v c:\source:c:\containerdir windowsservercore cmd.
A single file can be mounted by specifying the file name instead of the directory name.
Container and VM Deployment
The way containers are created is also quite different from VMs. VMs are composed much like physical machines. You create the VM virtual hardware, install an OS on the VM and then install the applications. Changes to the virtual disk files are typically persistent.
In contrast, containers are deployed from images that are stored in the container repository. The container repository can be local or it can be a public host like DockerHub. These images can be reused to create new containers multiple times. DockerHub, the public containerized application registry that Docker maintains, is currently publishing more than 180,000 applications in the public community repository. Figure 2 illustrates how images are stored in a local repository.
Containers typically consist of a container OS image, an application image and the sandbox. The container OS image is the first layer in potentially many image layers that make up a container. This image provides the OS environment and is a subset of the host OS. The container OS image is never changed by the container. It's possible to create as many containers as necessary from the images. Multiple containers can share the same image. Because the container has everything it needs to run your application, it's very portable and can run on any machine that has the same host OS. This enables Windows Server Containers to be easily deployed to any Windows Server 2016 host. The host can be in a VM or it can be bare metal.
Unlike VMs, containers are intended to be stateless and disposable. If you power off of the host, then the contents of the container are gone. Containers don't have live migration or failover and because a container isn't an individual server, you don't log into a container.