The underlying infrastructure for applications has been changing from servers to virtual machines and now to containers....
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
Along with this development, there are many changes to the entire process of building, deploying and managing applications. Let's explore how the lifecycle of a VM is very different from that of containers.
Containers vs. VMs: Creation
VMs are created by a hypervisor. For example, VMware's vSphere uses the ESXi hypervisor to create VMs. With VMs you need to make a lot of configuration decisions at the start. You need to decide the guest OS that will run the application, set the required storage, the memory, preferred network and a host of other settings. VMWare does have preset defaults as part of its VM creation wizard, but it still is a complex process that takes at least a couple of minutes on a public cloud platform.
Containers can be created much faster than VMs. This is because of the absence of a hypervisor and not needing to create an OS that can run the application. The startup time for containers is measured in milliseconds, and it takes a couple of seconds only if there is heavy load on the orchestration system like Kubernetes or Swarm.
Also, the process for creating a new container is very different from that of VMs. Container images are stored in a repository from where you can pull an image with as little as two commands. Containers are hosted by registries like Docker Hub, CoreOS Quay or Amazon Elastic Compute Cloud (EC2) Container Registry. Container registries require additional security measures as publicly available container images can contain vulnerabilities. To counter this, most registries come with security scanning features built in. While VMs are meant for use within an organization, registries make it easy to share container images within an organization or make them publicly available to the world.
This ease of creating and sharing containers makes them the preferred option to manage microservice applications. That's because services can be quickly launched, retired and replaced as needed, and this can be done at any scale with containers. The quick startup time of containers quickens every step of the software delivery chain and pushes Agile to its limits.
Containers vs. VMs: Storage
VMs have multiple options for storage, both locally and network-based. Whichever storage option you choose, there is a physical disk isolated from the VM. The operating system, program files and data are stored on the disk, and the disk itself can be copied and moved across multiple hosts or backed up. By default, VM storage is meant to be stateful.
Containers, on the other hand, are stateless by default. This means storage is created and discarded along with the container. A sandbox layer is created when a container image is edited. All data is stored in the sandbox layer, which is active only as part of the container. For persistent storage with containers, you have four options: data volumes, data containers, storage mounts or plug-ins. These options differ in where they store the data. Docker has detailed specifications for storage, but there are also third-party storage products like ClusterHQ Flocker and the NetApp plug-in.
The big difference is that storage with containers is tied to the application layer, not the infrastructure layer (as is the case with VMs). Each service of your microservices app can have its own storage, which can be managed differently from storage of other services. This provides more flexibility and control over storage.
Containers vs VMs: Deployment and management
The tool set to manage and deploy VMs is mature. VCenter Server is used to manage VMs in VMware. Configuration management tools like Chef and Puppet help with automated deployment of VMs in the cloud or in data centers. VMs hosted on infrastructure-as-a-service platforms are managed with tools specific to each cloud vendor. For example, Amazon Web Services has CloudFormation, which automates the creation of EC2 instances using templates. It also features CodeDeploy, a tool that makes deployment with VMs a breeze. VMs bring more control and have more options in the way they are managed.
Lots of these tools are quickly adding support for containers, but containers lag behind VMs when it comes to the options available for management. Container orchestrators are used to manage the creation and deployment of containers at scale. Kubernetes is leading the pack of container orchestration tools, but this space is still nascent, and Docker Swarm and Apache Mesos are equally capable offerings.
Containers have changed the software delivery pipeline, but for the better. Understanding the differences in the lifecycle of a container and VM will help you decide which to use for which workloads.
But when it comes to microservices, containers do have an edge. Yes, VMs have strong security defaults, more familiar stateful storage options and a mature ecosystem of management tools. However, containers are much easier to create and share, easier to bring more control over storage and are more nimble compared to VMs. This makes containers the preferred option for modern microservices applications.
Deciding whether to use VMs or containers for multi-tenant applications
Discover some top open source tools for Docker management
Discover why there doesn't always have to be a choice between VMs and containers