Kubernetes underpins Docker container technology dominance

At the start of 2017, IT expert and TechTarget contributor Tom Nolle predicted it would be an egregious mistake to use a Docker alternative for container technology.

These other technologies, such as CoreOS rkt or Apache Mesos, generally come into play when an organization deems a Docker feature insufficient, Nolle said. But IT admins need to carefully evaluate their environment and these container technologies' roadmaps before they commit.

In this Q&A, Nolle shares if his Docker prediction has held up two years later -- or if he's changed his mind.

Editor's note: Answers have been edited for brevity and clarity.

Do you still stand by your prediction?

Tom Nolle: Absolutely. The truth is that if you look at container technology today ... the alternatives to Docker have been so submerged by market trends that most people who adopt containers don't even know there is an alternative.

What I think confuses people is they conflate Docker as a container technology and Docker Swarm as an orchestration technology. We weren't talking about orchestration at that point, we were talking about containers and alternatives to Docker. Kubernetes has been adopted so enthusiastically and universally by the industry that people forget that, underneath, you're using Docker containers.

The mission for containers has evolved, and the evolution of that mission has taken containers from being kind of like static virtual hosts into dynamic pieces of componentized applications. It's that broader mission, which is much more cloud-centric -- even multi- and hybrid-cloud-centric -- that has radically changed the requirements for what I'll call the container ecosystem.

Kubernetes has stepped into the gap there and supported both the orchestration of containers, meaning their deployment and organization, but also the integration of other features and elements into that container ecosystem, which makes it almost like a cloud VM or server.

What is this mission for containers and why is it so different from the role of VMs?

Nolle: The big mission of containers turned out to be something totally different than that of VMs. As we evolve toward componentized applications that consist of synchronized, separately hosted components that work cooperatively to do something, these individual components are small, relative to the whole application.

VM overhead -- a different OS for every VM instance -- means that, in most cases, the software component you're trying to run uses significantly less resources than the system software that you're trying to run them with. You're wasting more than half of your total resources on multiple copies of an OS.

In componentized applications, the mission became, 'I need to do this really efficiently in terms of resources,' so container technology came to focus on these componentized applications.

VMs focus on IaaS and true multi-tenancy. And that's what changes the dynamic, because for containerization, there are other considerations that are so much more critical than the minimal potential differences in security. If the application can't be made to run efficiently in VMs, what difference does it make how secure they are, relative to containers?

How effectively has Docker addressed security issues that prompted organizations to use an alternative?

Nolle: There's always been a difference between a unique or new feature and a unique or new value proposition. When we started to move from physical hosts and physical hosting to virtual hosts and virtual hosting, the obvious concern ... was that there are places where the physical and virtual differ. And those places represent risk points.

When you consider two years ago, when most organizations had little or no container technology experience, the only way they had to assess risk was to assess the difference. In that intervening two years, there's been some evolution in Docker support for things like security. CoreOS rkt is still probably objectively a little more secure than Docker.

However, the fact that Docker is so universally adopted and deployed brings a set of community benefits that offset the small theoretical differences in security. Particularly because, unlike VMs, which are used to separate tenants in the cloud, containers are typically deployed on a host that is entirely owned by one company. That deployment has less security risk associated with it.

The little security details of the individual container hosting paradigms are inconsequential in comparison with the big question of the security in the container ecosystem. And that's what Kubernetes and its companion tools provide for.

So planners -- at least if they're rational -- always focus on the idea of dealing with the largest risks. It doesn't make any sense to address a minor risk if there exists a major risk that hasn't been addressed. The Kubernetes ecosystem is not only addressing the major value proposition for software today, which is componentization, but it's also addressing the major risk factors for software today, which is a failure in the distribution and connection of componentized applications.

Would you consider componentization a paradigm shift in IT?

Nolle: Componentization created a change in demand so profound that we had to think about app deployment differently to make it work.

Once we started to do things with the cloud and with virtualization, the potential out ran early conceptions. And so reality had to catch up. The thing that was best positioned to catch up was Kubernetes.

If we couldn't have done this with Kubernetes, something else would have evolved -- maybe Docker Swarm would've evolved. And because it is the critical element in creating that componentization ecosystem, it became everybody's focus. So now we don't talk about deploying Docker, we talk about deploying Kubernetes. All of the containers have subducted into Kubernetes.

People adopt Kubernetes today, deliberately, and kind of adopt Docker by accident. It goes along for the ride.

Today, I would say that Docker isn't even a choice: Docker is de facto. If organizations are going to do containers today, they're going to do Kubernetes and Docker. It is very doubtful that anybody is going to pick a different option -- particularly enterprises.

There may be some people in the web world or startups that are involved in consumer services that might look at something other than Docker. These are people who are way more technical developers than the average enterprise is.

You can use something other than Kubernetes and Docker, but ... in my last enterprise survey within the last year, one of the things that struck me as interesting was that in 277 companies, I had 206 who were actively using containers, and of that 206, 100% of them were using Docker-Kubernetes.

Given that Docker is the de facto backbone for containers in Kubernetes, will Docker alternatives survive long term?

Nolle: What has happened with Kubernetes is we've shifted focus from how we host a container to how we organize a container ecosystem. And hosting a container is such a small part of that, that what most people will do and are doing today is simply picking the container hosting option that is most popular on the theory that it will be the best supported, have the largest amount of documentation and tutorial material, and have the most qualified workforce.

So Docker already is that; it was that even two years ago, which is why I said it would be an egregious mistake to pick anything else. It's going to continue to be that in the future. There's not going to be anything that happens in the details of container hosting to create a worthwhile alternative to Docker because we don't need one. The focus is now elsewhere.

The key to Kubernetes is that it's an ecosystem for running componentized apps; that's what it has turned into. The fact that it happens to be based on containers is because containers are more efficient at running separately componentized pieces of something than individual VMs would be.

But the value of Kubernetes today is as much and, in some cases, even more the value of the total ecosystem that's been built around it. People adopt Kubernetes today, deliberately, and kind of adopt Docker by accident. It goes along for the ride.