This is a clash of virtualization titans: one virtual machine, the other a containerization technology. In reality, both are complementary technologies—as hardware virtualization and containerization each have their distinct qualities and can be used in tandem for combinatorial benefits. Let’s take a look at each to find out how they stack up against each other, as well as how the two can be used in tandem for achieving maximum agility.
Containers vs. Virtual Machines
Simply put, containers provide OS-level process isolation whereas virtual machines offer isolation at the hardware abstraction layer (i.e., hardware virtualization). So in IaaS use cases machine virtualization is an ideal fit, while containers are best suited for packaging/shipping portable and modular software. Again, the two technologies can be used in conjunction with each other for added benefits—for example, Docker containers can be created inside VMs to make a solution ultra-portable.
Containers vs. VMs. Source: Docker.
This industry-leading virtualization software provider needs little introduction, as its products and solutions have paved the way for a generation of virtualization technologies. vSphere is VMware’s flagship virtualization suite consisting of a myriad of tools and services such as ESXi, vCenter Server, vSphere Client, VMFS, SDKs and more. The suite functions as a cloud computing virtualization OS of sorts, proving a virtual operating platform to guest operating systems such as Windows, *nix, and so forth.
VMware architecture. Source: VMware.
At the heart of the vSphere suite is ESXi: the main hypervisor technology that makes hardware virtualization possible. Hypervisors allow for multiple operating systems to live on a single host with their own set of dedicated resources, so each guest OS appears to have CPU, memory, and other system resources dedicated to its own use. ESXi runs directly on bare-metal server hardware—no pre-existing underlying operating system is required. Once installed, it creates and runs its own microkernel consisting of 3 interfaces:
Console operating system/service console
Though an early virtualization pioneer, VMware is not the only show in town anymore: Microsoft Hyper-V, Citrix XenServer, and Oracle VirtualBox are also popular hypervisor technologies. Increasingly, enterprises are also embracing Docker as a potential VMware disrupter, but as we shall soon see— it doesn’t compete directly with VMware, despite taking the virtualization space by storm.
The Docker project’s main intent is to allow developers to create, deploy, and run applications easier through the use of containers. Clearly—for DevOps and CI/CD initiatives—application portability and consistency are crucial needs that Docker fulfills quite nicely. Containers make it possible to bundle an application up with all the required libraries, dependencies, and resources for easy deployment. By using Linux kernel features such as namespacing and control groups to create containers on top of the host OS, application deployment can be automated and streamlined from development all the way to production.
Docker architecture. Source: Docker.
In the 0.9 release, Docker replaced LXC with its own libcontainer library written in Go, allowing for broader native support for different vendors. Additionally, Docker now offers native support for Window, streamlining the management of Docker hosts and containers on Windows development machines.
Native Docker support for Windows is now available. Source: Microsoft.
For both developers and operators, Docker offers the following high-level benefits, among others:
Deployment Speed/Agility – Docker containers house the minimal requirements for running the application, enabling quick and lightweight deployment.
Portability – Because containers are essentially independent self-sufficient application bundles, they can be run across machines without compatibility issues.
Reuse – Containers can be versioned, archived, shared, and used for rolling back previous versions of an application. Platform configurations can essentially be managed as code.
Though both VMware and Docker can be categorized as virtualization technologies, optimal use cases for each can be quite different. For example, VMware emulates virtual hardware and must account for all the underlying system requirements— subsequently, virtual machine images are significantly larger than containers. That said, it’s also possible to run many discreet OS instances in parallel on a single host with VMware—allowing organizations to build true IaaS solutions in-house.
Because Docker containers are executed by the Docker engine (as opposed to a hypervisor), they are not fully isolated. However, the tradeoff is a small footprint: unlike VMware, Docker does not create an entire virtual operating system— instead, all required components not already running on the host machine are packaged up inside the container with the application. Since the host kernel is shared amongst Docker containers, applications only ship with what they need to run—no more, no less. This makes Docker applications easier and more lightweight to deploy and faster to start up than virtual machines.
Docker containers are generally faster and less resource-intensive than virtual machines, but full VMware virtualization still has its unique core benefits—namely, security and isolation. Since virtual machines enable true hardware-level isolation, the chance for interference and/or exploitation less likely than with Docker containers. So for application/software portability, Docker is your safest bet. For machine portability and greater isolation, go with VMware. And regardless of which virtualization technology you select, UpGuard can automatically validate the integrity and security of your virtual machines, Docker containers, web apps, and more.