The Hype and Mystery

Enterprise IT operations directors and solution architects continue to get asked, “Have you adopted a containerization strategy?” They have been hearing more about containerization but are reluctant to consider how they might benefit from them without clear evidence.  

The hype comes from all the DevOps engineers using containerization from Docker and doing agile and continuous development for new digital business opportunities. They’re using Docker containerization to run modular code for specific business needs that can be written and run in a testing environment without a lot of overhead and coordination with other development teams.

For folks in IT operations, they see containerization as yet another process change that might end up breaking things that are already running smoothly. When asked, they’ll typically say something like, “Sure, we’re looking at moving toward containers and I think some of our developers are using them now in testing.”

Here’s the issue. Most large enterprises have a lot of IT resources, applications, and services running in data centers just fine without containerization and they have some digital transformation objectives that require “moving to the cloud.” Instead of a “lift and shift” approach of one virtualized environment in a data center to the same set of resources architected in a public cloud, they’re considering re-architecting some of their application or service delivery with containerization as they go to the cloud.

The use of containerization for enterprise initiatives depends on what digital services are being offered as well as the development processes that are currently in place. It’s important to understand what containers are and what they are not before considering why enterprises would want to use them.

Containers Explained

Containers provide a way to architect application and service delivery with lighter footprints of isolated code that are generally easier to start or to stop running. They are not dependent on specific operating systems (OSs), whereas VMs in traditional data centers that host applications and services are tied to an OS.

These lighter-weight, portable versions of software code in containers make it easier to modularize development efforts. A very complex application or service delivery initiative can be broken up to run code in any programming language across the containers that make up the application or service. Teams can work independently of each other to update specific code in whatever language they prefer for their specific containerized development initiative.

Containers are not a replacement for VMs but rather a way to leverage VMs in a different way. A typical VM has any number of applications running on a specific operating system all in one “box,” so to speak. An enterprise IT architect might consider first having a one container per one VM relationship, and that would be fine. Each container could be running whatever code that is equivalent to the applications running on a dedicated VM.  

What is different is that each VM must have a dedicated OS environment for starting, stopping, or replicating to another environment whereas containers do not. That is why they are considered “lightweight.”

Taking it one step further, consider taking three typical VMs that you have running in three independent OS environments on a host server and make them into three containers running the equivalent code on another host server with one OS that is shared. Starting and stopping, and replicating those containers will occur much faster. The traditional VMs will start and stop the entire OS environment for each VM instance and can be replicated in timeframes that take several minutes, whereas containers doing the same starting and stopping or replicating can take only a few seconds.

Containers vs VMs for the Enterprise

With this understanding of containers, enterprise-level directors and architects must weigh the pros and cons of adopting containerization in their production environments. There are many factors to consider that include this basic understanding of the lightweight nature of containers that can typically be spun up or down faster than VMs.

Elastic Speed

Enterprises who want to have a fast-paced, more elastic environment where demand for computing environments needs to scale up or down quickly, might benefit from shifting to containerization because of their lightweight, modular design. If workloads are relatively static, then an existing approach with VMs can be suited just fine.

Hybrid Cloud

Enterprises who embrace a strategic, hybrid cloud approach will strive to implement a containerized strategy for the elastic portion of their application delivery in a public cloud environment while maintaining the virtualization of servers as traditional VMs either on-premises or in wherever the infrastructure platform works best.


Another distinction between VMs and containers is that VMs tend to have fewer security vulnerabilities because everything is “sealed” in the VM box whereas containers are sharing resources and vulnerabilities across an OS environment. Think of it this way, if one of the OSs on our three-VM scenario gets infected, it does not communicate across to the other VMs. If the OS of a containerized environment becomes infected or vulnerable, then potentially all the containers running on that OS could be compromised.


One of the biggest factors that sometimes gets overlooked when comparing VMs to containers is the development culture within an organization. It’s not easy to shift the mindset of developing in container environments vs. VMs with thousands of employees, compared to a more agile startup company that has a small team of developers who learned coding, to begin with using containerized environments.


And lastly, another caution for a containerized environment is that without proper orchestration and networking provided by a container management tool like Kubernetes, containerization can fail without adequate notice. VMs on the other hand, are considered as “monitor friendly” so you can have a fair warning and you can fix them before end users notice.  

CloudBolt for VMs or Containers

CloudBolt provides an enterprise hybrid cloud platform where you can manage the provisioning of both traditional VMs and Kubernetes orchestrated Docker containerized environments. We’re not playing favorites – we’re vendor-agnostic. We can help during any transition from one environment to another as you deploy infrastructure as VMs or as containers in a data center, in a private cloud, or with any popular public cloud provider like Amazon Web Services (AWS), Microsoft Azure, Google Compute Engine (GCE), and/or IBM Softlayer.


To learn more about how CloudBolt can help manage your containerized environment, check out our Solutions Overview

Recommended Reading