Recently I was giving a talk at a trade show on the basics of Docker, and how an application goes from an idea to being a production workload running on a Universal Control Plane managed Swarm cluster. As part of that talk, I spent a bit of time talking about how containers are not VMs . This was especially relevant as most of the attendees currently worked as virtualization sysadmins.
During the QA portion of the session one of the attendees asked me “When does my application go in a VM and when does it go in a container?”
Of course I started my answer the way I start my answer to these sorts of questions (those being questions to which there isn’t a pat answer). Questions like “How many containers can I run on my host?” or “ Should I deploy to physical or virtual ?”
I replied: “It depends” (insert audible groan from the audience and from you too I imagine)
Just like I wrote about in my last blog post regarding running Docker containers on physical vs. virtual servers , there are just too many variables.
However, like I did in that earlier post, I’m going to give you three different scenarios that you might want to consider when looking at where to deploy your application.
Before we go much deeper, let me reiterate that Docker isn’t the same as traditional virtualization. While there are similarities, at its core Docker is about delivering applications quickly and with the highest level of flexibility. Furthermore, in an ideal deployment container-based applications are delivered as a series of stateless microservices vs. the more traditional monolithic model found with virtual machines.
With that context here are three scenarios to consider when deciding where to deploy your application.
1) If you’re starting from scratch on a new application (or rewriting an existing app from the ground up), and you’re committed to writing it around a microservices-based architecture then containers are a no brainer.
Companies will leave their existing monolithic apps in place, while they develop the next version using Docker containers and microservices
By leveraging Docker, companies can accelerate application development and delivery efforts, while creating code that can be run across almost any infrastructure without modification.
2) You are committed to developing software based on microservices, but rather than wait until an app is completely rewritten, you want to begin gaining benefits of Docker immediately. In this scenario, customers will “lift and shift” an existing application from a VM into a Docker container.
With the monolithic application running in a container, the development teams can start breaking it down piece by piece. They can move some functions out of the monolith, and begin deploying them as loosely coupled services in Docker containers.
The new containers can interact with older, legacy applications as necessary, and over time the entire application is deconstructed, and deployed as a series of portable and scalable services inside Docker containers.
3) There are cases much like the second case, where companies want some benefits that Docker offers, and they move monolithic apps from VMs to containers with no intention of ever rewriting them.
Typically these customers are interested in the portability aspect that Docker containers offer out of the box. Imagine if your CIO came to you and said “Those 1,000 VMs we got running in the data center, I want those workloads up in the cloud by the end of next week.” That’s a daunting task even for the most hardcore VM ninja. There just isn’t good portability from the data center to the cloud, especially if you want to change vendors. Imagine you have vSphere in the datacenter and the cloud is Azure — VM converters be what they may.
However, with Docker containers, this becomes a pretty pedestrian effort. Docker containers are inherently portable and can run in a VM or in the cloud unmodified, the containers are portable from VM to VM to bare metal without a lot of heavy lifting to facilitate the transition.
If any of these scenarios resonate with you, then you’ve probably got a good case trying Docker.