What's next for VMs vs. containers as isolation, performance evolve?
With advances from Docker, Kubernetes and other container technologies, an ecosystem is emerging that threatens the existence -- or at least importance -- of VMs in enterprise IT orgs.
The VMs vs. containers debate becomes more one-sided with every containerization improvement: Containers have the capacity to displace both VMs and bare-metal hosting into obsolescence.
Containers have always had a built-in efficiency advantage over VMs because containers share the host OS and VMs each require their own OS. Recent developments in container orchestration and operations have expanded that advantage considerably. There's no technical reason to run a container in a VM. Has the VMs vs. containers battle been won, and should we all plan for a VM-free future?
Server virtualization's basic goal has always been to create a hosting platform wherein VMs behave as independent physical servers, such that they are equally as secure and as immune to one application affecting the performance of another. While modern VM implementations don't perfectly achieve that goal, they come very close.
Servers are flexible platforms that can host almost any workload in almost any possible network-connected configuration. VMs share those properties, and their flexibility works against them in a VMs vs. containers hosting decision. For many users, VM operational costs are of greater concern than server capital costs; the ongoing management of VM-hosted applications is a problem both in terms of cost and in the necessary staff skill levels.
Containers are not designed to be VMs -- or even servers. Instead, they lie between a VM and a simple OS multiprogramming feature. Containers are more efficient than VMs in memory use and, perhaps even more importantly, simpler to deploy and maintain. In a user survey by CIMI Corporation, more respondents said they had adopted or were considering containers because of deployment and management simplicity than due to improved workload density per server versus VMs. VMs are more flexible, more secure -- and more complicated.
Advances to containers, both within Docker and through Kubernetes, create an ecosystem or distributed platform: Not only is there a simple OS-linked container, there is a presumptive model for distributed deployment and networking of those containers. The deployment models are more restrictive than for VMs or servers, but users appreciate the IT operational advantages. It is easier to manage applications if they are all built and deployed the same way.
Containers and cloud deployment
The big challenge to container dominance is the cloud. Container hosting isn't as secure or insulated with respect to cross-user contamination as VMs, which means that cloud-hosted containers run on a layer of standard IaaS VMs. VMs are required, but subject to subduction as part of the cloud service; they are hidden from the user's view. This setup seems to guarantee a future filled with -- perhaps invisible -- VMs.
Is a world of invisible VMs different from one with no VMs at all?
The cloud isn't the only source of VM subduction. The ecosystem features of Docker, Kubernetes, Apache Mesos as well as Mesosphere DC/OS and Marathon -- along with other container systems -- coalesce into an orchestration layer running above an abstract resource pool. AWS and Microsoft Azure are among the public cloud vendors that use this layered orchestration approach in their container hosting services. This makes the ecosystem-based vision of container systems, with networking features, application structuring and lifecycle management benefits, highly portable. Users and applications interact through this new layer, which makes what's underneath unimportant. Is a world of invisible VMs different from one with no VMs at all?
Future directions
The pure no-VM outcome of VMs vs. containers is equally possible. An orchestration layer acts as an adapter, such that a variety of underlying hosting components look the same to users above. It's possible to build lower-layer hosting features to fit directly into that orchestration layer. VMs could evolve away from generalized server-like hosting platforms into something much more container-like. Rather than having a VM emulate a server, it would emulate the ideal abstract container host. Whether the result was called a VM or something else, it wouldn't resemble what we use today.
A second possibility in workload hosting evolution is the convergence of an optimal container host with an optimal function or lambda host. Cloud providers have adopted the same notion of an orchestration layer to create their function or lambda services. This structure hides the actual hosting platform from cloud customers, and in turn the cloud provider can evolve this underlying platform without disrupting users. Function hosting and container hosting have many similar requirements, so it's possible that cloud providers will combine these missions and even the orchestration layers to create one seamless platform.
Native enhancements to container ecosystem support are advancing in a unified way based on Kubernetes -- Docker added Kubernetes native integration alongside its own cluster support feature. The Cloud Native Computing Foundation's (CNCF) charter focuses on the kind of container-universalism that created the threat to VMs and includes better security and isolation. CNCF principles have established the character of the standardized manifest for Kubernetes applications that Docker recommends. Because of container universalism, cloud providers are under pressure to do more to differentiate their direct container hosting products.
Kubernetes supports deployment via VMs in the cloud, so doesn't that factor limit the damage of containers' rise to VMs? In the end, everything comes back to the ecosystem. A VM's value lies in its generality: You can do anything with it. Container value lies in the ecosystem that standardizes and limits how applications are deployed and connected. There are dozens of Kubernetes-related container tools that expand the scope of the ecosystem, and that expansion further limits the value of the generalized deployment options VMs offer.
Organizations can support an ecosystem -- even a container-like ecosystem -- with VMs. However, that approach makes most of the differentiating features of containers vs. VMs irrelevant. The only remaining features where VMs excel over containers, namely security and isolation, are targets for bodies such as the CNCF and companies such as AWS, Google and Microsoft.
Security options for containers
Security and isolation concerns have been a top priority for container industry vendors, and while strides have been made, the work is not yet done. For example, Kubernetes integrated Istio service mesh in early 2018, and many container security-focused startups still lead the pack of container vendors -- although the skepticism on startup longevity still leaves many users in limbo while major vendors catch up.
Serverless and functional computing require secure and isolated hosting and cannot exist economically without a new hosting model. That model will be more akin to containerization than server virtualization.
Enterprise architects and IT directors should begin the process to migrate applications to the container ecosystem model and plan to shift the organization's hosting focus to containers. Meanwhile, keep tabs on the evolution of serverless and functional computing.
