Skip to content
Contino
  • About Us
  • Our Services
  • Case Studies
  • Content Hub
  • Events
  • Blog
  • Join Us
  • Contact Us
Jesse White

Containers vs. Virtual Machines: Which Is a Better Fit for You?

With the advent of virtualization, we’ve seen a number of new technologies emerge over time, each with different strengths and weaknesses. Given the complexity of choosing the right set of tools for your workload, you might find it hard to choose one or more visualization technologies to suit your needs. Some of the most prominent methods of virtualization are containers and virtual machines, each with their own strengths and weaknesses.

To help you understand the appropriate use case for these technologies, let’s have a look at their strengths and weaknesses and understand how either or both may fit into your development lifecycle. In this post, we will compare containers and virtual machines based on four key criteria—application portability, security and isolation, networking and management, and finally, DevOps adoption.

Application Portability

One of the main reasons for container adoption is the ability to make applications portable across the pipeline. Containers are much simpler than virtual machines when you need to run many instances of one app. Since containers provide an app with everything it requires to start and run, it can be used across a wide variety of environments, independently of the host OS, without Ops teams having to go through compatibility nightmares. Docker has also developed integrations with AWS and Microsoft Azure, making portability an even more viable option to go from on-premises to the cloud. But it’s a different story when it comes to running apps in production.

Security and Isolation

The ability of containers to share the host system’s OS also means they can have root permission to the host OS, which is a possible vulnerability that can be exploited. VMs on the other hand have always provided isolation from the host OS since they emulate a whole OS and the requirements of an app to run, offering tighter security. This can be fixed by setting up containers to have fewer permissions to mess around with. Another workaround certain users have found is to use containers inside VMs so that they get the benefits of containers with the security of VMs. But this adds to management overhead, and goes against the very purpose of using containers. If security is your prime concern, VMs are still the better bet.

Networking and Management

Today, Docker is used mostly in development, staging and test environments, but not so much to run apps in production. Along with security concerns, another reason for its restricted use is the lack of tools for networking and orchestrating Docker in production. Ops teams would rather not risk running apps on containers for fear of unreliability as they haven’t been around as long as VMs, and are not as stable. VMs, on the other hand, have a mature ecosystem of tools and are trusted to run apps in production. Having said that, Docker has been catching up fast with new tools like Kubernetes, and Docker Datacenter, which are closing the gap between containers and VMs. Companies like Spotify and Amazon have begun using Docker in production environments, but with the help of additional tools.

DevOps Adoption

Agile development methodologies like DevOps go hand in hand with container adoption. The rise of the DevOps culture has made many teams across various companies rush to adopt containers to revamp their app development. Using VMs to run multiple components of the same app causes major performance overheads compared to containers which share the OS with the host system. Containers are the sensible choice for microservices because they allow for quick delivery of new code from developers to the ops team. If that wasn’t enough, containers also can be spun up and terminated more quickly than VMs. Spotify offers various features on their website that requires them to use containers. To keep all of those tiny gears turning, each feature is packed into a container as a microservice, which allows them to quickly fix a feature if it breaks without ruining the experience for 30 million subscribers.

Based on these points, as well as their adoption by various companies, we can see that there’s an inclination towards containers. Using both for various purposes is not a barred option, and in fact, it may be better than just using one of the two. That’s why it’s important to see what your needs and requirements are and see where you can apply VMs and containers. That way, you can make your app development and delivery far more agile than it was before.

More Articles

Getting Started With Docker on Windows

9th June 2016 by Ryan Lockard and Hibri Marzook

Terraform: Cloud Made Easy (Part 1 Of 4)

6th May 2016 by Jordan Taylor

Why Microservices Require a DevOps Approach

15th January 2016 by Benjamin Wootton

Sign-up: Insights Directly to Your Inbox

Join tens of thousands of your peers and sign-up for our best content and industry commentary, curated by our experts.

You may unsubscribe from these communications at any time. For more information on how to unsubscribe, our privacy practices, and how we are committed to protecting and respecting your privacy, please review Privacy Policy.
Contino
  • Londonlondon@contino.io
  • New York newyork@contino.io
  • Atlantaatlanta@contino.io
  • Melbournemelbourne@contino.io
  • Sydneysydney@contino.io