How can Docker claim that Rocket does not welcome the notion of portability? Portability and composability are at the center of the Rocket announcement.
From the Rocket announcement:
simple and open specifications for a portable container format...
fill the gap for companies that just want a way to securely and
portably run a container
From the Docker response:
these vendors want to create orchestration solution (sic) that are
tailored for their particular infrastructure or offerings, and do
not welcome the notion of portability
I think the rocket vs docker idea of open specifications are very different. Docker is fundamentally an API. In theory, you could create a C# version of docker that implements the docker api ontop of windows (when Microsoft adds namespacing support) and it would "just work TM". The same could be said for FreeBSD or anything else really.
Rocket looks very cool, and while it certainly does prevent some of the issues with docker security, it misses some of the benefits... like a remote API as there isn't a rktd, and many people will undoubtedly write them. So in that regard, I'd have to say rocket offers less openness.
With the current docker design, I see no reason why libcontainer couldn't add a rocket or lxd backend and be done with it however. As a sysadmin/developer to builds things, I see this as healthy for the container ecosystem even if it does certainly come off as a bit uncool from @phillips and the coreos crew. I'm kind of biased in that I think the only good multi-host docker / container manager will ultimately be mesos with kubernetes ontop.
Docker isn't claiming that Rocket doesn't welcome the notion of portability. They are saying that it would be a shame if portability was lost in the world of multiple container, distributed applications.
This comes off as overly defensive and entitled, like "we brought you containers and you stab us in the back!?"
I don't see why they need to view this as an opportunity to fight back and criticize another app container system, rather than enthusiasm about the continued spread of containers and expressing a desire to cooperate on building open, interoperable standards.
Where's the critic of Rocket ? All I see is that they disagree with the choices made by the team behind Rocket and they want to blog about it later. Other than that, Ben seems to only say that Docker was built by and for a community of developers and devops to make applications run consistently on different platforms. Ben says that expanding the scope of Docker is the right choice despite people being opposed to it, if I understand him right.
No, I'm not a Docker fanboy. Yes, I think Docker is pretty cool. Yes, I think the competition from Rocket is great and I can't wait to see how things go.
(This appears to be a case where the writer is so immersed in their own world, they forget readers might not be as up to speed as their own colleagues.)
For a post that according to the title is about Rocket, it's interesting that Rocket (and CoreOS) aren't even mentioned until paragraph 12. The previous 11 paragraphs are all "blah blah blah Docker". Seems like Docker is pretty full of themselves.
I see you got a recent copy. The original p12 follows follows:
A small number of vendors disagree with this direction. Some have expressed their concern that, as
Docker expands its scope, there may be less room for them to create differentiated, value-added
offerings. In some cases, these vendors want to create orchestration solution that are tailored for their
particular infrastructure or offerings, and do not welcome the notion of portability. In some cases, of
course, there are technical or philosophical differences. We hope to address some of the technical
arguments posed by the Rocket project in a subsequent post.
> These capabilities should not be monolithic. Individuals should be free to use, modify, or not use these services and their higher level APIs.
Let's hope they mean it.
> While we disagree with some of the arguments and questionable rhetoric and timing of the Rocket announcement, we hope that we can all continue to be guided by what is best for users and developers.
Interesting way to end their reply to the announcement of Rocket. The whole post reads like a typical PR response without real arguments. I'm looking forward to their followup post.
It's a strategy lifted directly from a page of "Producing OSS" about forking (in this case not a fork, but a competitor project, and still just as applicable): http://producingoss.com/en/forks.html
> While we disagree with some of the arguments and questionable rhetoric and timing of the Rocket announcement, we hope that we can all continue to be guided by what is best for users and developers.
What's he talking about regarding the timing of the announcement?
I read the Rocket announcement and then immediately read this response, and find myself very confused at what "mud-slinging" I missed in the Rocket post.
From a security and composability perspective, the Docker
process model - where everything runs through a central
daemon - is fundamentally flawed. To “fix” Docker would
essentially mean a rewrite of the project, while inheriting
all the baggage of the existing implementation.
From the Rocket announcement:
From the Docker response: Is this just FUD and sour grapes?