2014 saw the rise of Docker, and ended with appropriately inflated hype and hysteria around a related container technology: Rocket.
Immediately, discussions of uncertainty and doubt, and the familiar fear of forking unfolded. Would this be the end of Docker and a new beginning for container technology? Was this evidence that Docker and other containers are still the subject of open source community infighting and aren’t yet ready for the enterprise? Was it only a matter of time before some developers or organizations splintered off from the Docker community with their own container technology?
Some of these questions and assertions are valid and poignant, while others indicate a lack of understanding of the history of open source software. As I’ve written before, the negative connotations of a fork, or conflicts in open source communities tend to get widely discussed and highlighted, but the fact of the matter is that these discussions and disputes are also typically a sure sign of something else: vitality.
To understand the situation better, it is helpful to understand what Docker containerization is and why it has reached nearly unprecedented levels of hype and interest in enterprise IT.
Docker is an open source software tool that supports packaging of an application and its dependencies into a virtual container that can run on a variety of infrastructures — bare metal, traditional datacenter, virtual environment; and public, private, or hybrid clouds. Docker’s modern, lightweight design enables flexibility and portability on where applications can run and allows for faster, more efficient application development and deployment approaches, aka DevOps.
The level of interest and growing use of Docker centers on some key advantages of containerization — it is a more modern, lightweight form of virtualization that is generally viewed as a better fit for cloud computing and the movement of applications and workloads among different infrastructures, particularly clouds. Docker is also serving as an application release standard amid a lack of standards for faster, more agile IT and DevOps approaches.
We have also heard from both vendors and end users that Docker provides a welcome delineation of duties for large enterprises that are transforming to more agile DevOps processes that combine developer and IT operations teams. If an issue is inside of a Docker container, it is delegated to developers. If issues occur outside of the container, they belong to IT operations. While DevOps represents a confluence of these teams, there is still a need to define and assign duties, particularly for large enterprises. We’ve heard consistently this is a major driver of Docker.
While Docker has been lifted by integration and partnership with the largest vendors in the industry including Red Hat, IBM, VMware and Microsoft, the container ecosystem and market has also drawn the involvement and investment of a number of startups.
Rocket, another open source container technology, launched at the end of 2014 led by CoreOS, a provider of a lightweight Linux distro for running clusters and containers.
While CoreOS rightfully claims that it has always been, and continues to be, a contributor and participant in the Docker community, it also contends that with its work and announcements at DockerCon Europe last year, Docker as a company was steering the container technology toward becoming a platform, rather than another component within today’s modern infrastructure and application software stacks.
In my opinion Rocket marks a continuation of another adjacent trend that continues to impact and disrupt enterprise IT: polyglot programming. With the variety of needs among large enterprise and SP users, and the different advantages of different components, there is also a need for many different moving parts in today’s enterprise — from application development and deployment: languages and frameworks, databases, app servers, web servers — to infrastructure: including bare metal, traditional datacenter, virtual environments and the cloud … we now see the same for containers and container management frameworks.
It’s also worth noting that customers tend to like when there is not only one open source alternative that is credible, but multiple options. Examples include Xen and KVM, Chef and Puppet, CloudStack and OpenStack, and now perhaps Docker and Rocket.
No Hard Feelings
Having talked to both backers and community members of Docker and Rocket, it also seems clear there is less bad blood than many perceive or portray.
The story of Docker and Rocket also has some interesting meaning in terms of open source software and communities. The situation got a little personal and political, but it’s a healthy side effect of openness in airing grievances, differences and potential improvements. While many are quick to view these issues and conflicts negatively or as a sign of trouble, it is also a sign of a vital, working project and community.
Rocket will serve as a discipline on Docker to keep it more open and perhaps also will help drive features and functionality and use of other components (like systemd) and also vice-versa, similar to what we’ve seen with different Linux distributions, hypervisors and other technology.