How to Understand Virtual Machines Versus Containers

Table of Contents: Select a Link to be Taken to That Section

Executive Summary

Containers are becoming more popular and, in some cases supplanting virtual machines.
This article covers the distinctions between virtual machines and containers.

Introduction

A container may run within a virtual machine or on “bare metal.” And they can be ported between virtual machines (say on different IaaS providers) or between a virtual machine and bare metal. But in most cases, they are run from within virtual machines. The container can address any resource within its host virtual machine. And containers are, while newer than virtual machines, considered to provide similar benefits to virtual machines, but to have even more advantages as containers “virtualize the operating system rather than the hardware.” Because of this, they use far fewer resources, and containers are more portable than virtual machines.

This diagram is from the book Docker Deep Dive. Moreover, this diagram does one of the best jobs in explaining virtual machines. Notice that each virtual machine has what is emulated hardware for each VM. This provides much flexibility as each VM can be a different OS, but it also uses many resources. The use of VMs made sense when containers had not arrived yet on the scene. However, due to its resource consumption, it makes more sense to limit the number of VMs on a server, and let containers do more of the work. We are now seeing fewer VMs and more containers. VMs are still critical components, but there will be fewer of them used.

Reducing the Number of VMs

This reduction of VMs is an essential change in infrastructure as it is widely considered that VMs have been over implemented, which is a problem considering how much in the way of hardware resources VMs consume versus bare metal or the traditional server stack. Moreover, this is combined with the human overhead in managing the VMs.

These are all Docker containers that are available for me to open on my local computer. These containers can be ported from my operating system to any server, to either the bare metal or to a VM on premises in the cloud. If one were to have a VM on a local computer instead and then port that VM to a different location, it would be a much more involved affair. Notice that some of these containers are databases. In the past, the database was a resource that ran on a VM, which was addressed from within a container. Now databases (some of them) are themselves within containers.[i]

Porting Containers Between VMs

Containers can and are often ported between virtual machines, or between virtual machines and bare metal. Moreover, when Docker is used, it can be migrated between virtually any operating system. They also separate the data from the container, as is covered in the following quotation from Docker.

“So, how does a sysadmin backup a Docker container? They don’t. The application data doesn’t live in the container, it lives in a Docker volume that is shared between 1-N containers as defined by the application architecture. Sysadmins backup the data volume, and forget about the container. Optimally Docker containers are completely stateless and immutable.”[ii]

Containers can be managed by Kubernetes. Kubernetes is an open source orchestration project begun by Google for managing containers.

Kubernetes

The Kubernetes Engine is a primary service offered in Google Cloud (as well as AWS, called EC2 Container Service. Kubernetes has been a primary factor in Google Cloud’s growth.

This graphic is from the Cloud Native Computing Foundation. Even though Google Cloud is substantially smaller than AWS, notice how prevalent the use of containers is on Google Cloud. In total, the usage of containers on Google Cloud is close to that of on-premises; the second most common place containers are implemented.

This graphic shows the frequency with which containers are run on various infrastructures.

PaaS with Heroku

Another way of improving the management of microservices is through the use of a PaaS. This is covered in the following quotation from the PaaS provider Heroku.

“That said, microservices are not a free lunch. Each service has its own overhead, and though that cost is reduced by an order of magnitude by running in a PaaS environment, you still need to configure monitoring and alerting and similar services for each microservice. Microservices also make testing and releases easier for individual components, but incur a cost at the system integration level. Plan for how will your system behave if one of the services goes offline.”

AWS and Google Cloud are offering this not as virtualization have been attempted in the past on a limited number of servers but against an ocean of servers. Essentially, Oracle is arguing for bare metal or dedicated servers (as usually is the case with Oracle), but this will always have a price, and lacks the sophistication of cloud, as it puts one right back into hosting.

Oracle does not have the same ability to either have AWS’s cloud capacity, nor do they have AWS’s sophistication in containerization. Therefore they have to argue that dedicated servers are the way to go because this is what Oracle has to offer.

References

[i] An interesting comment on the benefits of running databases from within containers. “Want to move the MySQL instance to a different server? No problem, just mount the same volume and go for it. Is the image for your minor version of MySQL updated? Update it with a single command. Did your server restart, albeit on purpose? Docker will start your container automatically for you. Do you want to use the server you’re using now for something else? Stop and remove the MySQL container; your system is now clean and can run anything else. Or run your containers alongside your MySQL instance if you want to, without worrying about any other process conflicting with others.” – https://myopsblog.wordpress.com/2017/02/06/why-databases-is-not-for-containers/

[ii] https://goto.docker.com/rs/929-FJL-178/images/Docker-for-Virtualization-Admin-eBook.pdf