Can Docker replace VMware?

Is Docker, and for that matter containers in general full-on competition to VMware and other virtualization platforms? Docker has announced platform level features that include network virtualization and clustering. However, not every workload is suitable for containers. Containers lack much of the security, network features and management capability of full virtualization stacks. But, they are extremely efficient. Containers spin up in milliseconds instead of seconds or minutes. And just as not every workload is suitable for containers, not every workload is suitable for VM’s.

The questions of replacing VM’s with containers will come from CIO to architects and from architects to their vendors. OpenStack’s entrance into the landscape prompted similar questions. The frenzy of interest in OpenStack served as a reminder of how thirsty enterprises are for a true competitor to vSphere. XenServer, KVM and Hyper-V are all fine platforms. For whatever reasons, enterprises have not chosen to adopt these technologies at the same level as vSphere. Now we are hearing some of the same questions around Docker and containers.

It’s about use case

Containers have been around for years in both Linux and Windows. Packaging and management of containers in Linux has been a challenge. Docker helped solve that challenge by delivering a highly accepted format and management platform. The initial positioning of Docker containers was the ability to build applications that can be easily installed across Cloud infrastructures.

There’s tremendous appeal when you look at containers from a developer perspective. Docker enables a developer to create an application with a set of dependencies on their laptop. That container can then be deployed to a VM on VMware, AWS or Azure. The application could even be pushed to a Linux server running on bare metal hardware. The developer is assured that the application will run regardless of the underlying Linux distribution.

Overlap with virtualization

The overlap comes in the bare metal implementation. Container isolation occurs within a single OS instance. Multiple containers can run within a single OS. A simple example would be multiple MySQL instances running on the same OS. The ability to run on bare metal gives containers a slight bump in performance vs. VM’s. VMware has mentioned a 5% overhead to running containers within VM’s. Since there is no need to load a new kernel, containers are lighter than full VM’s. Regardless of VM or bare metal, one of the biggest advantages of containers is the ability to initiate new containers within milliseconds.

If you look at traditional application virtualization solutions such as Citrix XenApp you start to understand the performance benefits over full virtualization. If the use case requires you to serve 100 instances of Microsoft Office then application virtualization will much more efficient than full VDI. Some of the same advantages and challenges exist with Docker containers.

Challenges with containers

Some of the main advantages of full virtualization is security and support which both are direct benefits of OS isolation. Some applications just don’t play well with containers from both a memory and support perspective. If you need to isolate an application from either a memory space or network perspective, containers become a challenge. Another challenge is that most infrastructure tools work at the OS as the most granular level of control. Network control is a great example. If you want to create a rule that prevents one VM from communicating to another VM on the same host, this can be done with existing security tools. This isn’t possible today with containers. At best you can prevent a VM running a container from communicating with a VM running a different container.


Today, containers don’t compete directly with virtualization platforms. They target two different use cases. However, there is opportunity to talk about the potential integration between the two technologies. Just as desktop virtualization works best with application virtualization, containers and VM’s have the potential to work well together. In a future post, I’ll explore some of the integration I’d like to see.

Published by Keith Townsend

Now I'm @CTOAdvisor

9 thoughts on “Can Docker replace VMware?

  1. “If you want to create a rule that prevents one VM from communicating to another VM on the same host, this can be done with existing security tools. This isn’t possible today with containers.”

    – Shouldn’t this be possible by applying iptables rules on containers ? Of course it isn’t microsegmentation, but I think it can be achieved. Also, using Nuage Networks, ACL’s one can achieve the same result by applying ACLs to networks created

    1. Thanks for the comment Alex. IPtables would be a nightmare to manage at scale. And while you can do it through ACL’s to the networks it’s not container level filtering. You go back to the problems virtualization tries to solve.

  2. Hey Lennie,

    Yep, iptables will be nightmare to maintain, but it it is still possible. At least two companies comes to mind that uses iptables-based policy enforcement on massive scale. Yes, iptables is at L3 level filtering, unlike vShileld’s L2 and L3. You can still deny at L3 level all the ICMP requests to at least approximate L2 filtering.Nuage’s ACL’s based on policy templating (nope, I don’t work for Nuage 🙂 ) and it is pretty powerful. One can instantiate the network based on templates available where ACLs are applied already (yet again, at L3-level).

  3. Maybe I’m wrong, but I think you are still looking at the problem the wrong way.

    You are thinking about infrastructure, which is all very interesting from us infrastructure geeks, but nobody cares.

    It’s about the apps being deployed, not the machines or networks being deployed.

    Baremetal, VMs, containers, networks, storage are just tools or resources that you need to use. Even Docker is just a tool. Infrastructure is just an other hurtle on the way to get your application running in production or updating your application.

    I think you should first understand what type of applications people are now (working on) building:

    They are not monolithic applications, they are microservices.

    These are distributed applications.

    These applications don’t exist on a single machine or some failover model. They have the scale-out model. Because single machines or process fails and that is annoying. If you can just get a new one and start it everything is great.

    The developers of these applications don’t care about machines or networks.

    Each microservice is it’s own bubble, it has it’s own tiers. It’s own data store. It’s like a single tenant.

    This microservice/tenant really should just have one entry point (might be multiple REST-webservices or similar protocol) which other systems talk to so if you want something to manage/apply policy. Manage at that level what goes in and out of that entry point.

    You can micromanage your microservices if you like, but you are just making things more difficult for everyone.

    So does Docker replace VMware ? Not directly, I’m sure VMware will come out with a solution that works with container too.

    Does Docker shift the focus ? Yes, Docker abstracts the infrastructure and talks about applications, not machines.

    That is why you hear so much about orchestration, that is how your application actually gets deployed or how it can auto-scale.

    The other problem that needs to be solved is service discovery. If you have machines dying or being removed or added because of auto-scaling then nothing stays the same, so unless you optimize your DNS for this task it’s not gonne be a good experience.

    1. This post wasn’t for me or you it’s for most enterprise customers that still look at the VM as the most granular part of the environment. When a CIO looks at his budget and see hundreds of thousands of dollars in VMware licenses costs one thought crisses his mind, how cam he reduce those costs.

      The root of the question is can I reduce costs not can I run a better environment.

  4. Mainframes -> OpenSys -> Virtualization (SW defined conceptualization of Mainframes) -> Containers…This is an evolving path and inevitable! Its still fresh in memory to have dusted off my co-worker (in 2005) when he whispered VMware is going to invade DC’s..The very story applies here. Except the fact Micro Services Enabled application design and develop need to be container compliant which would pave the way to distribute the services across these minions who would consequently would rule the Clouds/formerly DC’s 🙂

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: