Containers & Comparisons: Shovel Or Spoon?

IT professionals are, I think, infamous for creating comparisons where comparisons should not exist. It's true that comparing products, platforms, solutions, and technologies can sometimes be helpful in better understanding their advantages and disadvantages, but it's also true that creating incorrect comparisons can be equally harmful. In thinking about this tendency to create incorrect comparisons, I came across this quote (attributed to Israelmore Ayivor, an author and leadership/motivational speaker):

"The shovel is bigger than the spoon, but it can never do the work the spoon does."

This might seem a bit of an odd quote to use when discussing IT comparisons. Bear with me and let's dig a bit deeper:

• Shovels and spoons have similar shapes.
• Shovels and spoons are used for a similar purpose (to move stuff from one place to another nearby place).
• Shovels and spoons are both typically made from metal.

As a result, one might look at a shovel and a spoon and conclude that these two items should be compared because they have similar shapes, similar functions, and are made from similar materials.

Of course, we know this to be an absurd comparison because it's obvious to us that shovels and spoons were built for very different purposes. They evolved to have the shapes they have and use the materials they use, because this made them more effective at performing their functions.

Join Scott Lowe when he presents a session on containers, orchestration, and virtualization, and get a deep dive in everything container-related at the Container Summit at Interop Las Vegas, May 2-6. Register now!

Yet we as IT professionals often end up making similarly absurd comparisons because we haven't taken the time to fully understand the purpose of the technologies, products, projects, or solutions in a particular space. Let's take, for example, the white-hot area of containers. How many of these phrases have you heard recently?

"Containers are going to replace VMs because we can achieve higher density!"

This is the equivalent, in my opinion, of saying that shovels will replace spoons because they will help us eat faster. Density isn't, can't, and shouldn't be the only metric by which you create comparisons. Is it an importance metric? Perhaps. The only metric? Certainly not.

"Containers will never replace VMs because they lack the strong security controls that VMs can provide."

This is like saying we should use spoons to dig holes in the ground because it will give us more control over the dirt we are digging up. Is security important? Of course it is! But should security be the only metric by which you architect your system? (For those of you that answering "Yes," I would in turn ask if your network is connected to the Internet. After all, last time I checked most folks agree the Internet is insecure.)

You may have seen the recent noise made over the comparison between Docker Swarm and Kubernetes, in which a study was conducted to compare the speed of scheduling workloads between Docker Swarm and Kubernetes. The TL;DR from the results of that evaluation was that Swarm performed better than Kubernetes at workload placement when the cluster was fully loaded. (Be sure to read the link above for the full details.)

To me, this comparison feels like a "shovel vs. spoon" comparison. Swarm and Kubernetes were evaluated for only two metrics (container start time and container list time). This is like comparing a shovel and a spoon only on the basis of weight, or only on the basis of volume moved in a given time period. In my mind, Docker Swarm and Kubernetes are fundamentally different and aim to solve different problems:

• Docker Swarm is focused on scheduling containers.
• Kubernetes is focused on scheduling applications.

You can see this in the architecture of two solutions. Kubernetes has this idea of a service, which abstracts a network endpoint away from the IP addresses assigned to the containers providing that service. Kubernetes also has the idea of a replication controller, which ensures that the appropriate number of containers is running on the back end of a service (side note: the comparison study calls out the outstanding performance of Kubernetes' replication controller). Docker Swarm currently doesn't offer these additional services, which makes it potentially leaner and faster. This isn't to say that Kubernetes is better or worse than Docker Swarm, or vice versa, just that they have different strengths and weaknesses.

So what am I trying to say? If I had to write a TL;DR for this article, I'd say it is: Don't create unnecessary comparisons. Instead, try to understand the architectural decisions behind the solutions you're evaluating. See where it makes the most sense for your particular problem or challenge, and recognize that every solution has its own strengths and its own weaknesses. Use the right tool for the right job!

Get more insight from Scott at Interop Las Vegas, when he discusses Containers, Orchestrators and Platforms: The Impact on Virtualization.