Not sure why, but the tone of this post seems very antagonistic-- as I'm not involved in either community, I'm not sure why but it seems a bit off-putting to an outsider.
Is there some open source community beef I missed? Is forking/developing your own container product that evil? I somehow missed where Rocket equates directly to war on docker instead of pushing containers further into the mainstream by adding some differentiation to the space.
The tone is not so bad considering it was written by Bryan Cantrill, Joyent CTO. His blog post antics were discussed here a week ago https://news.ycombinator.com/item?id=8663197. At least this time he didn't fake fire anyone.
Joyent is building some way you can run Docker images on a Solaris kernel.
If anything, the cyclical hype/backlash Docker is getting proves that it is popular and that it works for some people. Consequently, the exposure it gets displeases the people for whom it doesn't work or whose philosophies differ. This feels like Politics 101 if you ask me (I know you didn't :) ), and I'm still surprised by how vehement some people get about this, and about software philosophies in general (particularly considering the average shelf-life of most software).
All of that aside, I really like Docker, for the API but also partly because of what the CoreOS people complain about, i.e. a relatively monolithic system.
I'm a big fan of modular systems myself and I completely get where CoreOS are coming from with Rocket. But sometimes, I just want to be able to use the tool. I don't want to screw around for hours/days/... to put all the pieces together.
The network overlay situation is a perfect example. I know there are different solutions out there, in fact I've been trying some of them out at home. But the truth is, I don't want to have/have time to deal with that stuff and I'd much rather get on with my original ideas.
Unfortunately in some situations, as beautiful as the theory and principles are, people justifiably simply want things to work out of the box. I find the criticisms on String Theory are a good example of that, whereby the theory is gorgeous, but in practice does not necessarily have the value it intends to. I digress.
I love the idea of a super-modular car I can put together myself, change pieces as and when I wish and so on, but most of the time, I just need to get to my destination.
> If anything, the cyclical hype/backlash Docker is getting proves that it is popular and that it works for some people. Consequently, the exposure it gets displeases the people for whom it doesn't work or whose philosophies differ. This feels like Politics 101 if you ask me (I know you didn't :) ), and I'm still surprised by how vehement some people get about this, and about software philosophies in general (particularly considering the average shelf-life of most software).
Frustration is palpable when there's so much marketing of a technology that genuine engineering discourse suffers.
Docker and Joyent are businesses, and they're selling an idea to make money. If how they're selling the idea runs contrary to someone's "software philosophies", that someone has to contend with countering not just an intellectual argument, but also considerable (and often emotive, not educational) marketing.
This article — written by the CTO at Joyent — is essentially just marketing linkbait:
- It's titled with the catchy "Docker's Killer Feature". Killer. Feature.
- The first paragraph includes the phrase "CoreOS ... declared war"! People love wars! See also: "War on Christmas", "War on the Family", and Fox News.
The rest of the article is marketing filler. There's no deep dive on the API — having read the article, I don't even know whether Docker's "Killer Feature" is:
> Docker and Joyent are businesses, and they're selling an idea to make money.
And how is it different for CoreOS, Inc? They depend on a external product and they want to remove the dependency. That's fine. Smearing their ex-vendor isn't.
I think Joyent's right here. Docker's open and progressively enhanced API is a godsend. Somewhere around 0.7x they basically enabled the entire existence of my business, just by virtue of having a good API.
I frankly don't even care about the rest of the orchestration vs bloat stuff - I want a good API and good performance. The rest is secondary.
https://coderpad.io/ - It's a realtime tool for conducting interviews, for programmers. Docker lets me do a wide variety of tricky stuff involving the execution of untrusted code, like provide REPLs with very low latency.
>The problem with this pair of assertions is that they neglect one essential aspect of Docker — one that is arguably its killer feature: its open API.
Yes, that Open API is great but it does not seem relevant to CoreOS's criticisms.
To me, Bryan Cantril's highlighting of "Open API" as a counterpoint would make sense if CoreOS specifically stated that they will create a "closed proprietary API". I didn't think they stated that as an architecture goal. CoreOS wants to create a non-monolithic container system -- and presumably, their alternative will also be an "Open API".
Docker's "Open API" for flexibility doesn't allow you to "undo" how Docker internals would run as a pid on Linux. I'm genuinely confused as to why this Open API was brought up. My current interpretation is that it is almost a non-sequitur.
Yeah. My understanding of Rocket from the original blog post is that they don't have an "API" in the sense the Docker one is described at all. Since Rocket is just a container format/runner, there's no client/server relationship to document. You're running an executable on your system just like any other.
I'm new to Docker, so maybe there are some big wins surrounding the docker client/server architecture that I'm not realizing. But I already have tools in place to run commands on a remote server -- that's not the problem that I'm looking to Docker to solve. So if Rocket is able to get the containerization aspect working smoothly with fewer moving pieces, I'll count that as a point in its favor.
In fairness to Docker, I haven't had too much trouble so far pretending that "docker run" commands without the "-d" flag are just running the process in that PID. So the extra hidden complexity of really running it in another process and piping stdout back hasn't affected me in any negative way either.
our team is running containers in boot2docker virtualboxes, rocket does not mention anything about being able to run on OS X visualization layer. so docker compatibility is paramount or a stable boot2docker alternative.
CoreOS runs on many VM platforms, Vagrant/Virtualbox being one of them. The current CoreOS kernel/userland (and most new kernels and Linux distros) is ready to run Rocket. Is that what you're looking for?
The cynical response is that "open" is a relatively popular buzzword in software development circles, and writing a long post describing something you like as "open" in some way is an easy method of promoting it.
As someone excited about Docker and mildly annoyed by the idea that there would be _two_ "standard" container implementations, this is reassuring to me.
I hope shykes & co see the light and break the "new" aspirations out from the core Docker container; having one binary is aesthetically pleasing but understandably bothersome to anyone who likes modularity (most devs & unix folks, afaict).
Docker is modular, actually. They've got a plugin system, stable RESTy API and packages to work with various parts of their stack (libcontainer, libchan, libswarm etc).
Am I the only person feeling disappointment at the statements and attitude towards this from Docker and Joyent. I guess it's natural when you get your first piece of criticism, in the way of "the healthy open source process".
Mmm... I would think the folks at CentOS know what they're doing.
If the problem is Docker parting from its original mission and becoming a bloated piece of software that aims to do everything for everyone, I don't understand why it's so important to talk about its API.
It's going to be interesting what other projects that use Docker extensively will do (I like Deis). If they migrate to Rocket or another technology, too, Docker should look at their strategy again.
In my opinion, Docker's killer feature is that installing and testing out Docker is dead-easy - the barrier is very low. People will make a lot of mistakes trying it out, not understanding it completely before they dive in. Hell - looking at most images pushed on the public docker repo makes me cringe and wonder if a lot of the people who get to that point actually understand what the strength of containers like Docker presents them is. But taking the first steps - even if they are wrong - is easy, it's the the first foot in the door.
But once you get familiar with Docker - yes the API is a killer feature.
Rocket on the other hand doesn't seems to be something someone might try out when he has 10 minutes spare time. Reading the specs and doc, makes me hesitant of trying it, creating an 'image' seems like a ton of work just to try it out. Yes there are some good ideas there, but it would be sad if there weren't.
26 comments
[ 4.6 ms ] story [ 61.8 ms ] threadIs there some open source community beef I missed? Is forking/developing your own container product that evil? I somehow missed where Rocket equates directly to war on docker instead of pushing containers further into the mainstream by adding some differentiation to the space.
Joyent is building some way you can run Docker images on a Solaris kernel.
All of that aside, I really like Docker, for the API but also partly because of what the CoreOS people complain about, i.e. a relatively monolithic system.
I'm a big fan of modular systems myself and I completely get where CoreOS are coming from with Rocket. But sometimes, I just want to be able to use the tool. I don't want to screw around for hours/days/... to put all the pieces together.
The network overlay situation is a perfect example. I know there are different solutions out there, in fact I've been trying some of them out at home. But the truth is, I don't want to have/have time to deal with that stuff and I'd much rather get on with my original ideas.
Unfortunately in some situations, as beautiful as the theory and principles are, people justifiably simply want things to work out of the box. I find the criticisms on String Theory are a good example of that, whereby the theory is gorgeous, but in practice does not necessarily have the value it intends to. I digress.
I love the idea of a super-modular car I can put together myself, change pieces as and when I wish and so on, but most of the time, I just need to get to my destination.
Frustration is palpable when there's so much marketing of a technology that genuine engineering discourse suffers.
Docker and Joyent are businesses, and they're selling an idea to make money. If how they're selling the idea runs contrary to someone's "software philosophies", that someone has to contend with countering not just an intellectual argument, but also considerable (and often emotive, not educational) marketing.
This article — written by the CTO at Joyent — is essentially just marketing linkbait:
- It's titled with the catchy "Docker's Killer Feature". Killer. Feature.
- The first paragraph includes the phrase "CoreOS ... declared war"! People love wars! See also: "War on Christmas", "War on the Family", and Fox News.
The rest of the article is marketing filler. There's no deep dive on the API — having read the article, I don't even know whether Docker's "Killer Feature" is:
1) Actually an API vended by a library.
2) Some sort of IPC protocol.
3) A network protocol, or
4) Underpants!
And how is it different for CoreOS, Inc? They depend on a external product and they want to remove the dependency. That's fine. Smearing their ex-vendor isn't.
I frankly don't even care about the rest of the orchestration vs bloat stuff - I want a good API and good performance. The rest is secondary.
In fact, every Perl program has already been written, it is just a 'use' away.
Yes, that Open API is great but it does not seem relevant to CoreOS's criticisms.
To me, Bryan Cantril's highlighting of "Open API" as a counterpoint would make sense if CoreOS specifically stated that they will create a "closed proprietary API". I didn't think they stated that as an architecture goal. CoreOS wants to create a non-monolithic container system -- and presumably, their alternative will also be an "Open API".
Docker's "Open API" for flexibility doesn't allow you to "undo" how Docker internals would run as a pid on Linux. I'm genuinely confused as to why this Open API was brought up. My current interpretation is that it is almost a non-sequitur.
I'm new to Docker, so maybe there are some big wins surrounding the docker client/server architecture that I'm not realizing. But I already have tools in place to run commands on a remote server -- that's not the problem that I'm looking to Docker to solve. So if Rocket is able to get the containerization aspect working smoothly with fewer moving pieces, I'll count that as a point in its favor.
In fairness to Docker, I haven't had too much trouble so far pretending that "docker run" commands without the "-d" flag are just running the process in that PID. So the extra hidden complexity of really running it in another process and piping stdout back hasn't affected me in any negative way either.
https://coreos.com/docs/running-coreos/platforms/vagrant/
(CoreOS employee)
I hope shykes & co see the light and break the "new" aspirations out from the core Docker container; having one binary is aesthetically pleasing but understandably bothersome to anyone who likes modularity (most devs & unix folks, afaict).
If the problem is Docker parting from its original mission and becoming a bloated piece of software that aims to do everything for everyone, I don't understand why it's so important to talk about its API.
It's going to be interesting what other projects that use Docker extensively will do (I like Deis). If they migrate to Rocket or another technology, too, Docker should look at their strategy again.
But once you get familiar with Docker - yes the API is a killer feature.
Rocket on the other hand doesn't seems to be something someone might try out when he has 10 minutes spare time. Reading the specs and doc, makes me hesitant of trying it, creating an 'image' seems like a ton of work just to try it out. Yes there are some good ideas there, but it would be sad if there weren't.