Docker vs VM

There are a number of options for application hosting and development. If you are comparing the option of Docker vs VM, the answer to which one is right for your team depends on several factors. In the case of Docker, you will need to determine if your application is ready to run inside containers vs VMs. Cost and ease of adoption are also important factors.

Cloud and hybrid cloud automation have enabled more creative workflows for writing and deploying code. Container technology in conjunction with other advancements has shown to decrease reliance on requests for infrastructure from Ops. Here, we will discuss these and other aspects as they apply to Docker vs VM.

Virtual Machine Application Hosting

We have virtualization to thank for much of what we use in everyday software development. Using various types of hypervisor solutions, companies are able to take pools of resources to create machines that would normally be individual pieces of hardware. VMs allow for a fast and reliable way of creation by combining machine images with underlying automation.

By using existing hardware, users are able to create the pooled resources needed for an on-premise cloud environment. Many of today’s production systems use VMs to handle serving critical applications. Using virtualized machines is one way to allow for a mix of tried-and-true infrastructure with the benefits of more modern and centralized management.

Clustering this type of infrastructure is more likened to bare metal machines. Each VM is its own entity and can be sectioned off with virtual networking and storage. In the case of VMware, vSphere enables automation that brings the ability to create dynamic machines from scripts or via interfacing with 3rd party orchestration software. This is one reason a team may be using VMs vs Docker.

Recently, more focus is being put on containers and orchestration tools like Kubernetes (read more on Docker vs Kubernetes here). Those already using VMs in a VMware environment now have the option to start incorporating a hybrid approach. Meaning support for not only VMs, but also for container technology like Docker and Kubernetes.

A Quick Docker Primer

Docker is similar to a virtual machine. It is a representation of a full machine image all the way down to running and exposed services. Using this approach has taken the concept of hosting via VMs and extended it further to support a greater degree of management and flexibility. The positives of using a containerized approach to software development are abundant.

Developing applications using Docker allows for a more true representation of what will be run in production. This is because of how Docker images are designed, built, and deployed. Developers can help set direction on the environment used to serve their application. This allows for a lot of creative freedom that may be restricted in other areas when using a full VM image solution.

Automation is another key aspect where Docker shines. Within the Dockerfile are the instructions to install the base operating system, any prerequisite software, and patches. Developers can then use these images to have instant access to a fresh, local environment for testing their changes. This approach helps lessen the prevalence of the phrase “Works on my machine!”

Moving to a containerized application model has other positives that should be mentioned. In addition to the wins around standardization and automation comes the ability to run more with less. What does that mean? A virtual machine is typically used for each application that may be part of a larger environment. In contrast, Docker allows for abstraction at the application layer.

With each executing in its own, protected process, security is maintained while keeping the ability to use the underlying Docker image for multiple applications. Clearly, this has made way for much more efficient development workflows. Plus, it puts teams one step closer to more robust solutions using an orchestration tool to extend their built containers even further.

Those working in a cloud space such as Microsoft Azure also benefit from ready-made infrastructure to serve containers. This ability for the resultant Docker images to be run across multiple environments has allowed for much cleaner configuration and deployment methods for DevOps engineers. The approach is quickly becoming the norm as things move more towards containerization.

Docker vs VM – From Comparison to Complimentary

Although there are similarities between the usage of Docker vs VM, it is how they work together that can open up more ability for higher uptime and better use of resources. Using various orchestration and automation methods, Docker images and Virtual Machines can work in tandem to create stable services running on less infrastructure.

For example, an application may use MS SQL for the data layer. Since MS SQL is better executed on a VM vs Docker, a virtual machine would be created and configured with the appropriate setup and security. Alongside this server would be a Docker host that runs the containers holding the applications. This hybrid approach removes the need for a VM per application and may help with better resource optimization.

Another example is the integration of Docker containers with virtualization software such as VMware. As we discussed earlier, VMware vSphere now enables container support up to and including Kubernetes clusters. This is where a simple Docker application takes on a newfound ability for scaling, monitoring, and self-healing of the services it provides

Docker vs VM – A Comparison

When to Use Docker vs VM

It is clear that the options are readily available for your application’s infrastructure. A solid look at the architecture involved, uptime required, and security requirements are all factors in deciding whether you run your service via Docker vs VM. Both have pros and cons as well as situations where a combination may be the way to go.

Take for example a simple application whose only job is to display the current date, time, and temperature for geolocation. Looking at the factors above, we can determine what infrastructure would be best to run the service in production. Here are a few facts about the application:

• The application is created in Node.js.
• No login security is required.
• Uptime is not critical as this is a vanity application.
• Data persistence being warning level application logs is not necessary.

Looking at the above information, we can determine a few things:

1. Since the application is Node.js, a Docker base image exists that has the base requirements pre-installed. Building the application involves adding files to the image’s app directory.
2. Data is received from the system and an outside API that provides the temperature information. Logging for the calls to the external API should be added.
3. A clustered environment would not be necessary due to the low resource usage and low traffic.

In this situation, it would not make sense to run such a simple web service in a full-fledged environment like a virtual machine. Rather, a simple Docker image is created and populated with the built application files. The portable container can then be run on a number of hosts that support Docker. This takes advantage of the fast workflow that becomes available when using containers vs. a fully virtualized environment.

In contrast, another application example involves a web service that handles financial transactions for cryptocurrencies. In the same way, we examined the simple vanity service, we will look at this application in more detail:

• Application runs via .NET Core.
• It checks for an active login session.
• Uptime must be as close to 100% as possible excluding maintenance.
• Data persists via a connection to a MS SQL database.

As before, we can glean a few pertinent details from the information we have:

1. The application can be served using a Docker base image that builds and publishes the results to an application layer within the container.
2. The containers must persist the session even through application scaling.
3. An orchestration tool needs to be used such as Kubernetes to handle internal probes and ability to recreate a container in a stuck state.
4. The Docker host should be on the same VLAN as a MS SQL virtual machine to allow for secure data transit.

This is where a hybrid approach would be desirable. As stated earlier, MS SQL is better run on infrastructure like a virtual machine so that the necessary aspects can be properly configured and monitored. This is also where orchestration can help with the aspects of data persistence and security. In the case of Kubernetes, probing and self-healing capabilities allow the cluster to bring up applications in a manner to ensure they start properly and remain available.

There may also be situations where “containerizing” an application is not a viable option. In these cases, a virtual machine is likely the best choice. However, quick wins can still be realized by converting existing bare metal infrastructure to virtualized. Doing this frees up even more resources that can then be used for additional compute, memory and storage for virtualization.

Putting It All Together

There are various situations where Docker will be a helpful option for legacy and new application development. Knowing the benefits of each and how they may actually complement each other should help you make a decision on what direction to move forward. In either situation, virtualization has shown itself to be a great tool for the development and management of today’s applications.

Whether you are serving a simple date/time application or crunching thousands of transactions per minute, a solution exists to improve your services performance and stability. Take a look at each technology and take some time to see how different applications operate in both. The best approach is to do a true performance comparison. At the end of the day, the right solution will show through.

The Incredibuild Angle

When discussing Docker vs VM we couldn’t help bringing up the Incredibuild angle.

VMs and containers today are not used only in production but are an essential part of a mature CI/CD pipeline. When VMs or containers are used as build servers to run your CI/CD, Incredibuild can transform them into super containers with hundreds of cores that run faster builds, tests, and other compute-intensive processes. Try it free.