If 2014 was the year that Docker made application containers sexy, 2015 may be the year that Rocket, from CoreOS, makes them open, secure and composable. (Such containers offer a simple way of packaging and distributing software intended to run across a range of hardware and software platforms.)

See also: Why Docker Is Going To Dominate Your 2015

Alex Polvi

At least, that’s the plan CoreOS founder Alex Polvi laid out a month ago when his company announced a rival runtime that would compete with Docker itself. That plan, unsurprisingly, upset some within the Docker community.

Polvi, however, insists that he comes in peace. In a recent discussion with me, he stressed that while Rocket isn’t really meant to replace Docker, there’s a big demand for a standardized basic container technology—one that Docker itself isn’t providing.

See also: How Not To Manage An Open-Source Community, Courtesy Of Docker

After letting the dust settle for a few weeks, I connected with Polvi to learn how Docker and Rocket compete with—and complement—each other.

Rocket != Docker

ReadWrite: Before anything else, exactly who should be considering Rocket instead of Docker? Is it the same type of user/buyer for both?

Alex Polvi: There are really two buckets of users for Rocket and they could both be considered “platform builders.”

The first set of platform builders are companies like Cloud Foundry, Mesosphere, or cloud service providers (Amazon Web Services, Google, Rackspace) that are building a platform as their product. Rocket allows them to add containers to their platform while keeping the rest of what they do today.

The second set are enterprises that already have an existing environment and want to add containers to it. These would typically be large enterprises that have already invested in their own internal platform and want to layer in containers.

My understanding is that the Docker Platform will be a choice for companies that want vSphere for containers—that is, they want a whole platform off the shelf.

Lastly, I anticipate Rocket always being ahead on security, as that is one of the core design principles behind it. For enterprises that have rigorous security requirements, I think they will find Rocket a better choice over time.

Containers Are Components, Not A Platform

RWYou’ve talked about how Docker’s current direction, i.e., to build out a full container platform, doesn’t square with its original intent. Why does this matter?

AP: 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. Examples of this in action are Kubernetes or the EC2 Container service. These things use containers as part of a larger system. They have no need for clustering, or host provisioning, or any of that stuff, because they bring it themselves. 

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.

Now Docker is 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.

RW: What’s wrong with Docker becoming a platform? Is this just bad for CoreOS, or is it bad for potential enterprise customers, too?

AP: I think the Docker Platform needs to exist. It is not bad for CoreOS, and Docker users are free to run the Docker Platform on CoreOS, which we will continue to support.

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 Cloud Foundry. Companies like Cloud Foundry will use things like Rocket to build Cloud Foundry.

Walk Before You Run

RWNeil McAllister has criticized Rocket as being “not much,” that it’s “just a prototype.” Is that fair?

AP: When he came to our meet-up, the software was three weeks old. We openly called it a prototype. Please keep in mind Docker was at similar quality levels around March 2013.

RW: So when can we expect to see Rocket as a full-fledged container runtime? And how will it differ from Docker?

AP: It’ll take a little time, but it is moving a lot faster than the Docker project, although we have a lot of ground to catch up on.

Our primary focus is on these three areas:

  1. Security: Making sure we design it from the get-go for environments with the most rigorous security requirements; 
  2. Composability: Rocket can be easily layered into existing projects or environments. We found most of our users have existing environments they want to add containers to, versus swap them out wholesale.
  3. Open Standards: With the App Container spec, we are making a clear stance on our support of open standards around containers. The web is a better place if both Firefox and Chrome exist, because they share open standards. We want this world to exist for containers.

RW: But Docker founder Solomon Hykes keeps insisting that you haven’t actually solved these problems….

AP: I don’t know what he is talking about and I can’t get a response. (Maybe you can?)

If he is criticizing our current feature set, please do realize that Rocket was released a few weeks ago at prototype level. Once we call it 1.0 it will fulfill the goals outlined in the original post.

Where’s The Money In Containers?

RW: Part of Docker’s platform strategy may come down to money: adding functionality to Docker may make it easier to sell. How does CoreOS intend to make money?

AP: We make money today. We sell software. You can see some of the products on our website, like CoreUpdate and CoreOS Enterprise Registry.

We intend to build more products that cater to this emerging space. We build products that could be replaced by companies piecing it all together themselves, but decided to just buy our solution because we make it easier and better than they could have done on their own.

It’s worth nothing that, in general, open source is great at producing components, not products. We will continue to invest in our components—we have nearly 100 open source repos already—and have no intention of directly commercializing them. Examples of this are CoreOS itself (the OS), Rocket, and etcd. 

The components that we choose to build are the ones that do not exist today, but we see as a requirement for this new way of running infrastructure.

On the commercial side we will continue to build full solutions that take advantage of these new technologies. This means our competitors are the internal teams piecing everything together themselves. Very large companies will do this no matter what, as they have huge teams that just build systems to run infrastructure. 

However, we think we 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. 

Innovation vs. Cacophony 

RWGiven there is now at least Docker and Rocket, does this proliferation of competing container technologies pose a threat to enterprise adoption?

AP: Everyone in our emerging space wants customers to be successful with containers. We felt we had to do something—namely in the three areas of 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.

RW: But my sense is that mainstream users are already sitting on the fence, wondering what to do. Does it concern you that the industry noise could constrain the market? 

AP: Everyone running some sort of web service should definitely take a look at containers. This happens to be a lot of companies, because pretty much every company has some sort of web service now (which is often being developed for mobile apps).

Apps that on a single server and are scaled by throwing more hardware at it are not a good fit for containers.

The most concerning thing to me is if someone’s internal container project fails and they go back to the old way of doing things. This is not good for anyone in this space. 

Lead photo by wirrelwater