As 2014 drew to a close, CoreOS launched a Rocket at Docker, challenging Docker's process model as "fundamentally flawed." While CoreOS founder Alex Polvi has since softened his stance, he's sticking with his fundamental thesis that Docker is "no longer the ideal component for building systems."
The meteoric rise of containers is a recent phenomenon, so it's easy to see why Polvi is aggressively staking a claim. As the container wars get started, however, the larger concern is whether back-and-forth sparring between vendors will end up scaring off enterprises from adopting container technology, at least until the dust settles.
Platform vs. component
On one point both CoreOS's Polvi and Docker founder Solomon Hykes agree: Rocket and Docker aren't competitive -- not really. As Hykes told me, Rocket is "actually a libcontainer competitor," not a competitor to the overarching Docker platform. Libcontainer, a library that "specifies configuration options for what a container is," is essential to Docker, but it's also a true community effort that could help define the future of containers.
Libcontainer is, in other words, a really big deal, as InfoWorld's Serdar Yegulalp writes.
But Polvi apparently feels that Docker is neglecting its core in its aspirations to be more -- to be a platform. As Polvi told me:
Docker started out as a component for building platforms with. A building block. Something you could layer into your existing systems to take advantage of containers…. This was the original value prop of Docker, a simple tool to help you build things and why I think it has been so successful to date.
In some ways this feels like "we want to go back to the good old days," but Polvi insists it's not about being anti-Docker so much as it is a desire for Docker to remain an open component used to build other systems:
Docker is [now] a platform itself, not the building block. Is this bad? No, it is just no longer the ideal component for building systems. That includes our system, where we want to use containers to build an OS.
We think there is still a need for the component to exist for other systems to integrate with. We think the original premise of Docker is still a good one, so we want to make sure it exists. That's why we built Rocket.
In some ways, then, the problem is that in its quest to build a business, Docker may have purposefully or inadvertently made it harder to build other businesses upon it. Polvi continues:
Docker Platform and Rocket are distinctly different things. Docker Platform is a product. Rocket is a component. Companies will choose Docker Platform as an alternative to things like [Pivotal's] Cloud Foundry. Companies like Cloud Foundry will use things like Rocket to build Cloud Foundry.
Whether your company needs Docker or Rocket (or another container technology) may ultimately come down to what you want to build. But could companies get by with using Docker, the platform, then going with libcontainer as Polvi's composable component?
Definitely maybe. That's where it gets confusing.
Does Rocket need to exist?
The open source world has a long history of scratching itches no one knew needed scratching. Sometimes they pay off, but more often than not, they don't.
Docker replaces the Linux kernel's LXC, container technology that has been around for eons. But as Pivotal's Andrew Clay Shafer points out, "Docker addressed [LXC's] usability issues and made that tech accessible."
In like manner, CoreOS improves on Docker in significant ways. As Pivotal's Cloud Foundry executive James Watters stresses, Rocket "was [a] really important step that brought new thinking to the market, and kept the idea of multi-platform container at the center." It also promised to improve on Docker's security, among other things.
Not everyone agrees.
While Hykes acknowledges Rocket offers "some good ideas, which we will incorporate," he insists Rocket lacks the primary improvements sought by CoreOS, including improved security and composability.
Maybe, maybe not. Rocket's largely warm reception suggests it serves a deep industry need. Even as Docker expands functionality in pursuit of overall improved ease of use, many want a more discrete container library they can easily layer into existing projects or environments. Libcontainer might be the answer, but developers seem to appreciate Rocket's back-to-basics approach.
Clearing up the confusion
Which, again, leaves enterprises with the question: Do they need Docker or Rocket? Increasingly, the answer is probably both.
Then there's the fear that competing technologies end up confusing would-be customers more than it helps them. As Polvi told me, though, there's strong consensus, even between competitors, on the need to tell a common story of the value of containers:
Everyone in our emerging space wants customers to be successful with containers. We felt we had to do something [around security, composability, and open standards] to make sure that containers are enterprise ready. We think Rocket helps with this and encourages Docker to move in the right direction as well.
This is how competition works, and more pertinent, it's how open source works. As Polvi rightly argued to me, "In general, open source is great at producing components, not products." Enterprises looking to open source container technology, then, would do well to keep this in mind and expect open source to deliver far better building blocks than finished enterprise products.
It also means, as Polvi went on to tell me, that CoreOS's primary competitor is not Docker but rather "the internal teams piecing everything together themselves." While large companies will always have teams to build systems to run infrastructure, CoreOS (and Docker) believe they "can deliver solutions to companies that want the same level of sophistication of the big companies, but don't want to build it all themselves."
Rocket, in other words, is an open source component that can help enterprises build systems, while Docker, according to Polvi, seeks to be a system/platform unto itself. The two are very different approaches, both needed. Which one is right for you in a particular project largely depends on what you're hoping to build.