Container technologies: Docker has gained widespread industry adoption and success since its release in 2014. As more people push to Dockerize everything, it’s important to realize that Docker is only the first wave of successful container technology. Here are just some of the reasons why what we’re seeing is only the beginning of mainstream container technologies adoption.
My Introduction to Docker course also covers container technologies. Control Groups (also known as “groups”), which are fundamental in the Docker engine, have been around for years. They provide a way to assign CPU, RAM, Disk I/O and Network I/O limits to a particular process. LXC came along later and provided a high-level abstraction by leveraging control groups and other kernel features. LXC is an operating system-level virtualization method for running multiple isolated Linux systems (containers) on a control host using a single Linux kernel. The goal is to create an environment that is as close as possible to a standard Linux installation but without the need for a separate kernel. LXC offers separate namespaces for users, mounts, processes and more.
LXC comprises a fantastic set of technologies. It just needed a killer app. Heroku came along and transformed the platform as a service industry by providing a containerized way to run Ruby applications. Their stack was built on LXC. Users pushed their app via git push to Heroku’s servers. Then, Heroku did the heavy lifting to build what they call a “slug”. This is essentially everything required to start a container on their internal system. Heroku has added support for other first party stacks (such as Python, Node.js, Go, Java, etc.) and allows users to contribute their own via build packs. You can even view the source for their official Ruby buildpack.
Given that Heroku and LXC were released nearly 10 years ago (even FreeBSD jail was available before LXC or control groups), why is it that our industry is focusing almost entirely on Docker? Perhaps it is because Docker achieved a critical mass among developers. They won by taking what Heroku was offering privately and internally and making it accessible to everyone.
Docker gave everyone a standard way to build images using the Dockerfile. It was astounding simple: List the commands required to configure your software and add the files. Then, more importantly, push that image to a public repository. Now, anyone could pull that image and run your software as a container—regardless of whatever language it was written in. The model took the industry by storm. It’s safe to say that for many people, container technologies and the wider ecosystem are basically Docker.
This view may be changing in the next few years. v. production deployments are a completely separate story and arguably the most important. But businesses don’t make their money during development. Software only matters once it’s in production. Getting Docker containers technologies into production is a complicated affair, and this is where other container technology companies want to compete with Docker Inc. New competitors in this space are already having an impact on the container technologies ecosystem.
The initial (and ever increasing) technical scope of Docker’s engine makes some weary. There are a few layers here. First, generally, it’s more difficult to integrate with projects of a larger scope because their implementation may overlap or conflict with existing systems (for example Docker vs Systemd). Second, a larger technical scope means that the project is more likely to overtake third-party projects (for better or worse). Third, and perhaps most importantly: Money and the wider impression of a for-profit company (Docker Inc.) trying to take over the world. These feelings came to a head when Docker added first-party orchestration via Docker Swarm in Docker 1.12. This made other vendors like RedHat (a huge player in enterprise-scale systems) cautious.
The New Stack recently posted an article on how RedHat is developing a way to support non-Docker backends in Kubernetes. This excerpt from the article sums it up:
“We don’t really need much from any container runtime, whether it’s Docker or [CoreOS’] rkt — they need to do very little,” said Kelsey Hightower, Google’s staff developer advocate, “mainly give us an API to the kernel. So this is not just about Linux. We could be on Windows systems… if that’s the direction the community wanted to go in, to support these ideas. Because it’s bigger than Docker Inc., at this point. This is about, how do you run a containerized application?”
He has a great point. Orchestration is about running containerized applications. The article, in addition to the recent rumors of a Docker fork, made me realize that as an industry we need to expand our horizons and focus on the wider container ecosystem. We cannot look at containers technologies only through the lens provided by Docker Inc. Here’s a quote from the Open Container Initiative (OCI) FAQ:
“In the past two years, there has been rapid growth in both interest in and usage of container technologies based solutions. Almost all major IT vendors and cloud providers have announced container technologies based solutions, and there has been a proliferation of start-ups founded in this area as well. While the proliferation of ideas in this space is welcome, the promise of containers as a source of application portability requires the establishment of certain standards around format and runtime. While the rapid growth of the Docker project has served to make the Docker image format a de facto standard for many purposes, there is widespread interest in a single, open container specification…”
OCI backs the runC project, which is a simple solution for starting containers compatible with the OCI standard. Docker donated a large amount of code to the initiative, and Docker Inc.’s libcontainer turned into runC. In fact, the libcontainer source repository redirects to the runC repo.
CoreOS is actively developing Rocket. Rocket is interesting because it’s somewhat of an independent container implementation (largely inspired by Docker). Rocket is built on the AppC standard. The AppC lists three stable implementations: rocket, jetpack, and kurma.
The point is that there are many different active projects in the container ecosystem. While each effort works to optimize for different technical use cases, they share a common goal: More defined boundaries. This makes orchestration easier.
DCOS (short for DataCenter Operating System) announced in a recent post, Who Wants to Run My Container, that they have decided to unify their support for AppC and Docker containers. The author calls out some implementation concerns later on in the post:“Another factor making it easier is the decision to focus on support for the Docker image spec, but not necessarily target all Docker runtime features such as storage or networking. We believe some of those runtime features should be part of a higher level API, since most people only actually use a subset of these runtime features.
Consider, for example, the networking stack: here we decided to use the Container Networking Interface (CNI) instead of Docker’s native Container Network Model (CNM). CNM has been designed specifically with the Docker container orchestration life-cycle in mind, which doesn’t play very well with other orchestration engines such as Mesos or Kubernetes. CNI plugins, on the other hand, are completely unaware of the lifecycle of the orchestration engine, making them much more platform independent.”
The key takeaway here is “platform independent.” Docker won phase one of the software pipeline by reaching a critical mass of developers. Bringing containers technologies to production is the next phase. Most people are not concerned with bringing one container into production, as this is simply too small a scale to care about. Organizations are increasingly building more and more distributed systems with smaller and smaller components (e.g. Microservices architecture). These systems require more robust orchestration systems like Kubernetes, Mesos or DCOS. Increasingly, these systems are less concerned with the implementation of particular components and more with how easy it is integrated with their scheduler. This where the tension begins.
Docker Inc. added Docker Swarm into its 1.12 Docker release. This created friction with downstream vendors who are upset with Docker Inc. for competing with their products and for shipping things that break their products. This is one reason behind the rumored Docker fork. Regardless, the industry wants to move to better orchestration tools that are decoupled from the underlying technologies.
Now, a question for you: If you were a maintainer on DCOS/Kubernetes/Mesos/Openshift, etc., would you rather integrate with decoupled tools or larger, more tightly coupled tools? I think you would choose the latter. I believe that we’ll see the industry shift away from Docker’s implementation and focus more on open standards such as AppC or those proposed by OCI. Again, this is backed by Kelsey Hightower:
This is more about leveling the playing field,” he said. “Right now, Docker is the most well-supported container runtime, because we at Google and the community have done the majority of the work to make Docker work as a first-class runtime. But now that we see that people want choice, and it has always been our vision to support multiple container runtimes, one step in doing that is creating this Container Runtime Interface. As part of that, we’re going to refactor our current code base to implement the [CRI].– Kelsey Hightower in Red Hat, Google engineers work on a way for Kubernetes to run containers without Docker
We are experiencing the first wave of mainstream container technologies adoption. Fast forward five years into the future: Do you think that Docker will be around, or will open source implementations have taken the lead? Do you think Docker Inc. will be targeting the same marketplace or will they have moved on to larger enterprises? Do you think that Kubernetes/Mesos/DCOS and friends will still be around, or will they have been beaten by other projects?
I’ll throw my hat into the ring: I think that in the next five years, the industry will have moved on from Docker as the primary player. Open source implementations will take center stage. Orchestration tools will have evolved significantly in their functionality and robustness. The focus will no longer be in container technologies because they are an implementation detail. Orchestration tools will continue to improve and will focus more on interfaces than on implementations. We’ll also see more new container implementations.
My advice to you is to stay informed about the container technologies ecosystem and watch these other implementations. At best, you will be more prepared to ride the waves of industrial change. At worst, you will have learned something new.
