Initial thoughts on the Rocket announcement

Initial thoughts on the Rocket announcement(blog.docker.com)

108 points by yannisp 11 years ago | 24 comments

panarky 11 years ago |

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

Is this just FUD and sour grapes?

SEJeff 11 years ago | |

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.

mrisse 11 years ago | |

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.

themgt 11 years ago |

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.

conradk 11 years ago | |

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.

mmahemoff 11 years ago |

Some context, since the article contains neither explanation nor link about "the Rocket announcement":

CoreOS is building a container runtime, Rocket https://coreos.com/blog/rocket/ https://news.ycombinator.com/item?id=8682525

(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.)

orand 11 years ago |

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.

thebeardisred 11 years ago | |

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.

Titanous 11 years ago | | |

Here's the original: https://web.archive.org/web/20141201195306/https://blog.dock...

Touche 11 years ago | |

Yes, this is not HN worthy. There is very little talk about Rocket at all. This is just a quick PR piece.

andruby 11 years ago |

> 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.

norcimo5 11 years ago |

Why the heck are they being so defensive? I honestly don't get it.

vezzy-fnord 11 years ago | |

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

bastijn 11 years ago |

"We of docker, advise docker. "

Despite their arguments being valid or not, I cannot help but hearing this message over and over in my head.

ryduh 11 years ago |

> 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?

zwily 11 years ago | |

DockerCon is this week.

ryduh 11 years ago | | |

Makes more sense. Thanks!

brown9-2 11 years ago |

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.

mrisse 11 years ago | |

They called Docker broken.

  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.

CoconutPilot 11 years ago |

I see a parallel with what Docker did with LXC and the libcontainer debacle. What comes around goes around ...

That said, I like this announcement. Docker was focusing on becoming an App store. I like that Rocket brings the focus back to technology.

pron 11 years ago |

> While we disagree with some of the arguments and questionable rhetoric and timing of the Rocket announcement

Does anyone care to explain what's suspicious about the timing?

marcc 11 years ago | |

DockerCon Amsterdam is later this week. Docker plans to make some announcements during this event.

darkarmani 11 years ago | | |

Wouldn't it be better (for coreos) to make the announcement after DockerCon, so it if it was FUD docker couldn't counter it all week?

jafaku 11 years ago |

"They are free to use Docker as a single container format."

Yes please, that's my preferred format.

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.

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.