Hacker News Reader

Comment by kelseyhightower | Hacker News Reader

This is a great question.

CoreOS is currently working on adding support for Rocket[0] to Kubernetes. There is still a lot of work to do here, but things are progressing nicely. Kubernetes is a true opensource project and accepts contributions that makes sense. Supporting another container runtime engine makes sense in terms of choice for the community and forces clean separation between Kubernetes, the cluster manager, and the underlying container runtime engine.

When it comes to Rocket vs Docker I think the competition will be good for both projects and the community as a whole. At the end of the day, both projects and the communities behind them want people to be successful with containers.

[0] https://github.com/GoogleCloudPlatform/kubernetes/pull/5518

View on HN

> both projects and the communities behind them want people to be successful with containers.

I think it's better said, Docker wants people to be successful with containers, so long as it's Docker containers.[1][2][3]

We've seen a lot of very open work coming from the CoreOS team with Rocket and the ACI... unfortunately we've only seen negativity and mud slinging coming from the other camp.[2][4][5][6][7]

Docker is more interested in having an "open" implementation, rather than an open specification. The things is... an Open Specification is far more important for industry changing technology like containers.

[1] https://news.ycombinator.com/item?id=8683705

[2] https://news.ycombinator.com/item?id=8938409

[3] https://news.ycombinator.com/item?id=8789181

[4] https://news.ycombinator.com/item?id=8938066

[5] https://news.ycombinator.com/item?id=8938176

[6] https://github.com/docker/docker/issues/10643

[7] https://github.com/docker/docker/issues/9538

Don't kid yourself...it's been negative on both sides. CoreOS called Docker fundamentally flawed, though they've backed away from that a bit.

From what I can tell, CoreOS was happy to let Docker, Inc control the container platform and build orchestration tools on top of Docker, since it's pretty clear that no one is willing to pay for the base containerization layer and the only money to be made is in orchestration. But then Docker released their own orchestration strategy and that started the current period we're in where both companies have come off as being very unprofessional and concerned only with their own future success.

Between Docker trying to build almost everything into the actual Docker executable (it's a container runner, API server, build tool, process monitor, cloud provisioner and orchestration tool...those last two are only not the case because they got called on the strategy) and CoreOS's pointless pushing of rkt (rkt itself isn't pointless, but the PR to add rkt support to Docker was, as was implementing Docker support in rkt). Both sides have foolishly put their own interests ahead of the container ecosystem.

To say that either of the two companies has been the bad actor in all the drama would be biased. They've both come across like spoiled little children trying to get their way. As someone who has been pushing my company (~8000 employees) to consider implementing a containerized deployment strategy, it's been hugely inconvenient to have to concede to people arguing against containerization all the points around how unprofessional the companies in the space have been, both in behavior and coding practices.

+1, This has been my interpretation too, I feel like a lot of the rkt PR was subtly aimed at Docker, it was very much "this is why it's better" rather than "this is why it's good".

Honestly, as a consumer of both projects, I'm happy that rkt exists because it provides a working demonstration of a solution where container images are orthogonal to other concepts such as orchestration. If it went the other way, our vendors would be swearing up and down that the only way for this container thing to work is if we install their complete solution.

I love my Apple MacBook Pro and its soldered components, but I need my data center to be meaningfully upgradable.

I love Docker, but it feels a lot like the days of incompatible VM images, where you got super locked in, and if you tried anything that wasn't what they had designed for, then you got screwed.

Can you point to specific examples of the CoreOS team dealing low blows?

Frankly, CoreOS started the ACI and Rocket because there was no open specification. Docker had started off with somewhat of a specification, then deleted it. A year later, CoreOS launches ACI as a public open spec, and suddenly Docker whips one of their own up over a weekend.

The entire point of ACI is nobody owns the specification. Docker wants to own the spec, govern the spec, and be the spec.

With something as critical as this technology -- we need an open specification -- far more than an open implementation.

The three examples in my first post, combined with their timing in releasing Rocket. Their initial press release was filled with vitriolic rhetoric...so much so that they had to recant most of it. And coming so soon after Docker started talking about their orchestration plans, it's pretty transparent that CoreOS doesn't feel that the community needs and open specification. They feel that CoreOS needs an open specification to prevent Docker, Inc from leveraging the common implementation to gain an unfair advantage in the Docker orchestration market.

After announcing Rocket, they embarked on a campaign of subtly trying to show people how uncooperative Docker, Inc was being, first by implementing Docker support in Rocket and then that sham of PR (the first ever PR PR) where they implemented Rocket support in Docker. It was so much code and, with no warning that it was coming, there was no chance that it would ever get merged. The only point of that was to try to argue that they'll support Docker and Docker won't support Rocket. It's so transparently passive aggressive to anyone that understands the underlying dynamic expressed in my earlier post.

> With something as critical as this technology -- we need an open specification

That's fine. But there's a right way and a wrong way to get there. They should have started by documenting the existing Docker implementation. It's open source and implemented by many Docker partners (Amazon, Google, etc). Once the community has accepted the specification, as the authors, they would have license to go to the community and push for changes they feel are necessary. Docker isn't fundamentally flawed, but it is flawed and I think even Docker, Inc admits that. There are changes that are necessary and they need to happen out in the open rather than behind closed doors at Docker, Inc.

Starting their own format was an attempted power move designed to fracture the community. And I see it as largely having failed. There are a lot of things that I like better about Rocket, but the ecosystem around it is way too nascent to even consider using it. There's no collection of images that I, as a developer, can leverage to avoid building everything from scratch. Docker Hub is a big part of the reason to use Docker. And there's no third-party integrations for Rocket. I can use Docker through AWS ECS and have the piece of mind to know that I can migrate to GCE and my Docker images will basically just work. With Rocket, I basically have to use CoreOS (a design I'm not thrilled with) or roll my own.

If either company seemed like it was trying to put the community first, I'd be 100% behind that company. But CoreOS's rhetoric around trying to position themselves that way is simply indicative of them not having first-mover advantage. Both companies need to grow up and realize that this is a nascent market and there is room for both to succeed if they're only willing to cooperate. But if they continue to squabble like little children fighting over a ball, the parents are going to take that ball away. Google and Amazon will roll their own proprietary containerization or, worse yet (for Docker and CoreOS), they'll cooperate on an open standard. But the community is what's important. If they can continue to grow the community, profits will follow. If they continue to try to corner the market and push each other out, the community will go elsewhere and both companies will fail.

You seem to not understand what ACI is... or haven't bothered to do some research on it.

> With Rocket, I basically have to use CoreOS (a design I'm not thrilled with) or roll my own.

Rocket works on any Linux platform. Other implementations are working on more and more platforms, including BSD's.

They all adhere to the ACI open specification.

ACI is an open specification that anyone/everyone can contribute to (including Docker if they wanted). To date, there are more than 4 completely different implementations of ACI (one of which is Rocket), all written by different organizations. Apache Mesos is working on a 5th, and more are coming.

That makes the ACI have 400% more implementations that Docker's "specification" which was written after-the-fact and is more-or-less a documentation of how Docker was implemented rather than an open specification in-which the community helped form.

ACI belongs to the community. It's being contributed to by a large userbase and is growing rapidly.

This was the entire driving force behind ACI from CoreOS -- to get a standardized specification that anyone could implement. CoreOS saw the need for there to be more than a single container technology -- but they must be inter-operable.

It's a lot like virtiualization before the OVF format came along. ie. If you made a VMware guest, you were stuck with VMware. After the OVF format, you could export your VM to an OVF image and import it into any other standardized virtualization platform -- you were not locked into a single for-profit company and carried at their whims.

You seem to think it's about a "money grab"... well, sure if users adopt Rocket maybe CoreOS gets support fees etc... but if users adopt one of the many other implementations of ACI, CoreOS doesn't get anything except a diverse ecosystem of inter-operable container platforms.

That's a win for everyone.

CoreOS still supports Docker -- and I've seen nothing but praise come from the CoreOS camp. That doesn't mean Docker is doing the right thing for the community at large -- instead, they are doing the right thing for Docker, the for-profit company.

> You seem to not understand what ACI is

I know exactly what the app container spec is...stop being patronizing. My point was that I have to use CoreOS FOR ORCHESTRATION because my normal options for orchestration don't (yet) work with Rocket or any of its implementations. I know CoreOS has publicly announced that they'll make Kubernetes work with Rocket, but that's not yet reality. And the orchestration option that we're currently pursuing, ECS, isn't likely to support Rocket any time soon.

And CoreOS doesn't exactly have a great history of being interoperable...the tools that make up CoreOS have hard dependencies on each other. For example, I find Consul to be better than etcd in almost every conceivable way and yet CoreOS forces me to run etcd. I'm not going to believe that CoreOS cares about interoperability until they're willing to take the same "batteries included but removable" stance that Docker has professed.

You seem to have a very pro-CoreOS bias. I'm not going to try to change that. Let me be clear on my biases. I like the design of Rocket far more than Docker. I don't want a single executable to build, run, monitor processes and be a REST API. But I also disagree with almost every decision that's gone into CoreOS. Fleet is cumbersome, systemd is a train wreck (the one thing an init system cannot be is non-deterministic and I've seen too many systemd boot sequences be that) and etcd is inferior to other options. So while I respect that Rocket can be used elsewhere, there's still little-to-no support outside of CoreOS when it comes to everything that goes into running containerization in a production environment.

My company has serious dev-test-prod workflow issues that can be solved by containerization. We're publicly tied to running in AWS. CoreOS is simply a non-starter. While I completely agree with all the negative things that have been said about Docker, I can still advocate Docker-based solutions in the meetings I attend on this subject because everything I need from the ecosystem is there, today, ready to use. Rocket simply isn't there yet and it could have been if they'd started with the existing Docker implementation as the basis for their specification. And you're not going to convince me that that NIH decision is in the best interests of the community.

> Rocket simply isn't there yet and it could have been if they'd started with the existing Docker implementation as the basis for their specification

It's not "their" specification. You really don't get what the ACI is. Nobody owns or controls the ACI -- it's a community specification being worked on and developed by a community, ie. no one entity dictates what it looks like.

> I find Consul to be better than etcd in almost every conceivable way and yet CoreOS forces me to run etcd

This is out of the scope of this discussion. Rocket runs on any Linux. ACI implementation run on any 'nix currently. There is not interoperability issues here. etcd is part of CoreOS the Operating System. However, you can use etcd outside of CoreOS the Operating System.

This complaint is like saying your don't like iptables in RHEL 6.x and since it's not easy to change out, you refuse to use Wayland. It makes no sense.

> I can still advocate Docker-based solutions in the meetings I attend on this subject because everything I need from the ecosystem is there, today, ready to use.

Perhaps this is a sign that contanerization is simply not ready for mainstream enterprise use yet. Sure, Docker stamped the big "1.0" to impress investors and Red Hat, but that doesn't mean it's actually really ready for the big time. Especially since other offerings are rapidly brewing. You've gone this long without containers, you can definitely wait another 6 months (or switch to BSD and use jail containers which have been mature for 15+ years).

> I'm not going to believe that CoreOS cares about interoperability until they're willing to take the same "batteries included but removable" stance that Docker has professed

Again -- you don't seem to understand what the ACI is. It's a community thing -- CoreOS doesn't own it. That guarantees interoperability. The ACI specifies what a container should look like to be "standards compliant". It's up to the specific implementation to make a system that works with that standard container format. The system can be implemented in any language, work any way they want, do anything they want, etc... so long as it can read and understand the standard container format. If that is not "interoperability", I don't know what is.

> You seem to have a very pro-CoreOS bias

No, I don't. I have a very pro-Open Standard bias.

The world does not need another vmdk.

Reply on news.ycombinator.com