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.
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.
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:
- Guest system
- 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, built from container images, 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. Now on version 19.x, Docker now offers native support for Window, streamlining the management of Docker hosts and containers on Windows development machines. Meanwhile, the Docker Enterprise business was acquired by Mirantis, the Kubernetes As A Service provider.
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.
Docker Vs VMware Side-By-Side
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.
Docker Vs VMware Frequently Asked Questions
What Are The Major Differences?
VMware emulates machine hardware whereas Docker emulates the operating system in which your application runs. Docker is a much more lightweight virtualization technology since it does not have to emulate server hardware resources. The focus is on abstracting the environment required by the app, rather than the physical server. VMware, just like actual machine hardware, lets you install operating systems and other tasks that require a full server.
Is Docker Just Hype Or An Improvement Over VMware?
The use cases for Docker are driven by advances in how applications are architectured and deployed. Rather than rely on monolithic applications, web scale enterprises have discovered the advantages of microservice architecture, which include scalability and high availability. Docker containers provide both agility and reliability for microservices. The ecosystem that has been built up around containers, including tools like Kubernetes and Apache Mesos make the benefits tangible for IT organizations. Docker’s tooling, including its CLI, Docker Compose, and Docker Swarm provide excellent support for cloud-native app deployment.
Is Docker Faster Than VMware?
Provisioning and starting a Docker container is of necessity faster than starting a VMware container. After all, a Docker container is a much more lightweight resource. The container has little overhead, compared to the RAM and other requirements of a virtual machine. However, that does not mean that when you run containers your apps will necessarily be faster than those run on a VMware virtual machine. Virtual machine platforms like VMware ESXi, Xen, and KVM have performance rivalling that of bare metal. The specific environment of the application will determine speed, including machine specs, RAM, and other factors.
Can You Run Docker In A Virtual Machine?
Since VMware and Docker deal with virtualization at different levels, they are not strictly competing technologies, but are complementary technologies as well. It is possible to use them in tandem, and many organizations do so. You can therefore run Docker in an OS such as Ubuntu or VMware’s Photon, running on a VMware ESXi virtual machine.
Combining Docker And VMware Together
Running Docker on VMware virtual machines is not only possible but many IT teams rely on this setup for deploying their applications. While a desktop product, VMware Workstation, is available for developers to use during development, it’s not the setup that works for production. Instead, you will want to use VMware products such as VMware vSphere and ESXi, which equip you with highly performant virtual machines for production workloads. VMware’s ESXi is a bare metal type 1 hypervisor purpose-built with security and efficiency in mind. It installs directly onto your server and has direct control of the physical server’s resources. ESXi has a light footprint, coming in at just 150 MB, with support for configuring virtual machines up to 6TB RAM, with 128 CPUs, and 120 devices.
You have numerous options for the actual OS you use on top of a VMware virtual machine for running containers. One powerful approach is to use VMware’s Photon, an operating system that is container-focused, lightweight, and is performance optimized for exactly this purpose. Another option is to run popular distros you might already be using, such as Ubuntu, CentOS, or Debian, which all work seamlessly with VMware products. In addition to these setups, it’s also straightforward for containerized apps to communicate with services running on VMware virtual machines or other types of virtual machines. This means that you can combine Docker hosts and VMware virtual servers in your data center. Your Docker apps can also be deployed on virtual machines in the cloud, such as AWS, Azure or Google Cloud.
Some common problems encountered when running Docker on VMware virtual machines include the following:
- VMotion virtual host migration disrupts physical resource access to a virtual machine, resulting in problems for the Dockerized applications running in the virtual machine.
- High CPU ready (a metric of the time when a virtual machine was ready but could not be run on a physical CPU) can lead to performance issues for applications in Docker containers.
- While VMware allows taking snapshots of virtual machines, during snapshots, I/O resources available on the machine are lowered, leading to problems or outages for Docker containers.
You should be aware of these issues when working with Docker and VMware together, and take steps to mitigate them.
Future Of Virtualization: Will Docker Displace VMware?
The future of virtualization likely includes much greater use of containers, and Docker is likely to benefit from this. There are powerful reasons behind the uptrends in Docker, and related technologies’ usage. For one, containers enable organizations to be more agile since they deploy so quickly. Spinning up containers is easier and faster for developers to test their code, while deploying is faster as well.
With Docker, you can deploy on bare metal, virtual machines, AWS, Azure, or other production environment. Not only are containers introducing greater efficiency in orchestration, but a significant proportion of container technology is open source as well. This fosters greater innovation community-wide, resulting in better solutions accessible to all, while lowering costs. Other trends like severless hosting also promote the general thesis of lighter weight application deployment, with containers facilitating a lot of this. In the future, more and more organizations are likely to follow the mantra “worry about your application, not the environment.”
These trends all suggest a future in which technologies like Docker and Kubernetes will have a bigger role to play. That said, virtual machines are likely to remain prevalent, at least for certain use cases. Containers achieve less isolation than virtual machines, and therefore tend to be seen as less secure. For use cases where greater security is required, virtual machines might remain a superior technology. In addition, persistent storage is harder with containers. These are problems that containers struggle with but might improve vastly in the future. If so, the need for virtual machines might diminish even more, but that remains to be seen.
VMware, for its part, could benefit from the move to the cloud by enterprises who are moving existing apps to the cloud. In such cases, many of these organizations are not ready for a full scale adoption of containers, but can benefit from VMware’s cloud products such as VMware Cloud or VMware Hybrid Cloud Platform.
How To Choose Between Docker And VMware
As we’ve seen, the complementarities of Docker and VMware mean that instead of asking “Should we use Docker vs VMware,” many such organizations should instead be asking “how do we use the two together.” Nevertheless, if your situation requires one and not both of these, these guidelines can help you make the selection. First, if you are migrating a monolithic application from on-premises hosting and porting the application to containers will require unacceptable developmental investment, then VMware virtual machines are an obvious fit. In addition, if you would like your application to have its own user space and persistent storage with isolation at the OS level, VMware, working with technology like Intel VT or AMD-V, is also the better fit for your needs. If your IT needs require running and managing multiple operating systems and access to the operating system’s full functionality and resources, again virtual machines will be the ideal solution.
On the other hand, for situations where the focus is on the application, with the specific operating system and its functionality irrelevant for your app, then Docker containers are ideal. If you are implementing a distributed architecture with each application run as a microservice, then Docker is ideal for deploying these kinds of applications. Each application is run in its own container, and platforms like Kubernetes help you manage clusters of containers which may be hosted on numerous servers in the cloud.
Regardless of which tool you end up going with, both Docker and VMware can improve server utilization and efficiency, as well as lower overall deployment costs.