Hacker News Reader

Comment by otoburb | Hacker News Reader

Interesting takeaways from the post:

* Despite Brandon Philips (CoreOS CTO) serving on the Docker governance board, Docker has aggressively expanded their scope well beyond their original container manifesto.

* CoreOS believes the Docker runtime is now too unwieldy and "fundamentally flawed"; the unwritten word that really sprung to mind was that Docker was getting "greedy."

* CoreOS reaffirms their original operating model of being capable of running their infrastructure on and with Docker.

* Rocket is CoreOS's answer to stay true to the "simple composable building block" mantra.

View on HN

This is great news, particularly for Enterprise customers adopting containers. IMO, Docker's 'new' direction completely ignored the tremendous amount of support they had from the sysadmin and devops communities.

But crucially, they also crossed the business models of many startups (including CoreOS, Weave, Flocker, etc.) that rely on Docker maintaining an Open Platform. So this is an entirely logical response.

I'll be surprised if now Docker in response doesn't unveil an 'enterprise' Docker version that basically just strips away the unnecessary features and has more security by default. The enterprise market is just too valuable to let it just slip away like this. Your move...

What is Docker's 'new' direction? I don't see any related announcements on their blog besides adding support on new platforms.

I attended Docker Global Hack Day #2 on Oct 30 from Austin. A talk was given on an active Docker project for host clustering and container management, which was non-pluggable, and made no reference to and used none of the code from CoreOS's etcd/fleet/flannel projects.

This was where I first started worrying about CoreOS and Docker divergence.

But since the hack day there has been a pretty reasonable (IMO) GitHub discussion about the tradeoffs between out-of-box ease of use and customizability.

https://github.com/docker/docker/pull/8859

I saw that same presentation at the same event, but came away with a very different impression: the container management they showed was implemented completely outside of docker itself, with no patches to the docker codebase needed. Also, IIRC it actually did use significant code from etcd for coordination.

Are we talking about the same thing?: https://github.com/docker/docker/pull/8859 ???

It had no etcd in it and the POC was implemented as part of the Docker API/CLI, as best I recall. There were significant questions in the discussion about etcd not being there.

Docker's 'new' direction is to direct its attention towards solving the orchestration and management problems involved in actually running infrastructure on Docker.

A number of third parties had begun work on various (sometimes proprietary) orchestration and management systems for creating a reliable/scalable/easily manageable cluster with Docker as a building block. CoreOS is one. But Docker is pushing towards an official, open-source orchestration/management system that threatens to make all of those companies irrelevant.

I think it is a great stand for Docker. Very recently (IMHO in 1.3), it merged the functionality of Fig into Docker.

I think Docker orchestration and coreos can coexist - if I had to use COREOS to use the goodness of Docker, then systemd-nspawn would come and eat Docker's lunch.

I wish that Docker bless one of Ansible/Chef as the official orchestration base and take it forward. I really don't want to earn something Docker specific.

Fig functionality was not merged into Docker's 1.3 release.

Ansible/Chef orchestration IMHO solves a very different problem than container orchestration.

You're right - I was referencing this bug here (https://github.com/docker/docker/issues/8637), but seems it was not merged into mainline.

I agree that Chef and Ansible are different than container orchestration today - especially, when you look at low level stuff like networking, mounts, etc... But I guess what I was saying is that it is not hard to add these features to them.

They already have a specification format that works well and check for idempotency at its core. Unless you mean something like etcd is fundamental to container orchestration, which I don't believe it is (we run a couple of containers in production using Fig)

> Docker's 'new' direction is to direct its attention towards solving the orchestration and management problems involved in actually running infrastructure on Docker.

IME examining Docker, this is actually the hard problem.

I believe the two (Docker & CoreOS) might have rather similar strategies and / or product roadmaps.

What seemingly gets mixed up by quite a few commentators on this topic:

Docker is an orchestration, deployment, management, etc solution - the "container" is created by LXC, jails, libVirt or other OS features and now also libContainer.

This discussion also shows how far away / how early we are with "containerization" or container that are exchangeable / movable between different (OS) environment - we are discussing the companies that are building cranes to load and unload the boxes before we even have an understanding how the boxes will really look like.

CoreOS doesn't mind using systemd...

> CoreOS believes the Docker runtime is now too unwieldy and "fundamentally flawed"; the unwritten word that really sprung to mind was that Docker was getting "greedy."

I wonder if that comes from the partnership with Microsoft.

Regardless of whether your comment was lightly sarcastic or not, I agree that the Docker VMWare[1] & Microsoft partnership announcements may have been conditional upon a committed Docker roadmap outlining some or all of the features that others (such as CoreOS) may feel should be broken out. Typically larger ecosystem players want to be assured that your offering will have a clearly defined role within their existing ecosystem that plays to your core brand and technical competency.

[1] http://www.forbes.com/sites/benkepes/2014/08/25/vmware-gets-...

Wow, that is a random jump of logic. Answer: no.

They raised $55 million [1], so you have to believe their ambitions are to extract as much rent from the container ecosystem as possible. That's not a bad thing, but it's behind a lot of their moves.

[1] http://www.crunchbase.com/organization/docker

Docker's MO is to become "that thing that is on all servers" so that when they flip the switch and start monetizing off support and tertiary services, people will be more-or-less locked in.

It has indeed surprised me how quickly a normally-slow-to-accept-new-things community has adopted Docker (even well before it was considered "stable").

> how quickly a normally-slow-to-accept-new-things community

I think you're referring to the sysadmin community - but I think the driver for this has been the search for deployment nirvana. Deployment is a much more fragmented field, so it makes sense that a good solution would find fertile ground.

Absolutely. Not only does it simplify deployment, you also get the ability to quickly spin up a new development environment. That means it's easy to dip a toe in and slowly increase how much you use it.

There is no switch to flip.

You are not "locked in" by Docker Inc if you are using Docker just like you aren't locked in by Github if you are using git.

> You are not "locked in" by Docker Inc if you are using Docker just like you aren't locked in by Github if you are using git.

A much more accurate analogy would be you are not "locked in" by Oracle if you are using MySQL. It may be true today, but no guarantee that will always be the case.

Despite the attempt of some to move goal posts, you're still guaranteed that you won't be locked in by Oracle even tomorrow. You still have the source code for the version you're running right?

Sure...as long as I don't care about security patches, bug fixes, performance improvements, or new features.

If people think the software moves in the wrong direction it will be forked (see MariaDB). Nothing world changing will happen.

Docker Inc. seems to make a lot of effort to ensure Docker is a truely open project. I get the feeling that people think that handing your project to Apache is the only way to prevent vendor lock in these days.

" You still have the source code for the version you're running right?"

Yes but I don't have the skill, time, resources and will to maintain MySQL if and when Oracle goes evil (I mean more evil than now ;-)

This is why I choose carefully what companies / groups I depend on for my future computing needs.

Like mongodb hype?

Docker seems decent but I don't think I want them to do ochestration..

Reply on news.ycombinator.com