Live data from Hacker News

CoreOS is building a container runtime, Rocket

coreos.com

31–40 of 295 posts

Re: CoreOS is building a container runtime, Rocket

#31

Great news. I'm not a fan of Docker's new monolithic approach to containerization. Things like orchestration and networking should not be included in docker, but rather pluggable.

I prefer the Unix model - many programs that work together. That might not be practical for networking (a natural plug-in, probably), but feels like it should be the way for orchestration.

The Docker image registry and image management should really be a separate program as well - that is a huge pain point that Rocket seems more likely to get right.

Re: CoreOS is building a container runtime, Rocket

#33

Earlier quoted context omitted.

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

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

Re: CoreOS is building a container runtime, Rocket

#34
post #26

I have been concerned that Docker's scope was expanding too far for a while now, so I'm glad to see an alternative that might work appear on the horizon. That said, I am somewhat concerned that CoreOS has a suspiciously similar business model to where Docker would probably like to be. It's in a business's best interest, and exceedingly common practice, to "land and expand" with something clear and compelling, and fol…

I had the same initial reaction, but I think there's good reason to trust the CoreOS folks to remain faithful to the project's goals. Containerization (although foundational) is one part of CoreOS's platform. It's easy to see where the boundaries fall, e.g. I expect systemd and fleetd to keep their respective functionality and not overlap with Rocket. It become pretty clear once dotCloud became Docker Inc. that they…

I think it's also crucial users have more than one viable container option.

Re: CoreOS is building a container runtime, Rocket

#35
post #9

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 operatin…

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

Re: CoreOS is building a container runtime, Rocket

#37

Great news. I'm not a fan of Docker's new monolithic approach to containerization. Things like orchestration and networking should not be included in docker, but rather pluggable.

This is exactly the model being proposed in Docker.

I think this was the original model proposed by Docker. What we have now is (as other posters have mentioned), a Docker organization reasonably bent towards creating value for their investors, which means they need to start building things that, you know, make money.

To clarify, I don't think there's anything inherently wrong with what Docker's doing, but it is at odds with an entirely open, pluggable system. It doesn't make any sense for their business model to truly make it easy to just use their containers and none of the revenue-generating offerings.

Re: CoreOS is building a container runtime, Rocket

#38
post #33

Earlier quoted context omitted.

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.

Re: CoreOS is building a container runtime, Rocket

#39
The post mentions not having a daemon running as root, but then you have to run `rkt` as root anyway. Won't this just mean that instead of having a single implementation of a Rocket daemon running as root, there is now one custom one every time it needs to be automated?

It's great to see this problem broken up into reusable pieces though. It totally makes sense to function without a daemon, especially out of the box.

Re: CoreOS is building a container runtime, Rocket

#40

Great news. I'm not a fan of Docker's new monolithic approach to containerization. Things like orchestration and networking should not be included in docker, but rather pluggable.

I prefer the Unix model - many programs that work together. That might not be practical for networking (a natural plug-in, probably), but feels like it should be the way for orchestration. The Docker image registry and image management should really be a separate program as well - that is a huge pain point that Rocket seems more likely to get right.

Interestingly enough, with flannel, docker's advanced networking capabilities become pretty trivial, and communication across hosts is also pretty trivial.

I think all in all, CoreOS has built out a ton of tools to make using Docker easier, and they're all very well defined, and compossible. I'd even say that a lot of docker's features could be completely removed by using some of these tools.

Links? Nah just use ips/dns + etcd for service discovery.

Networking? Need very basic bridged networking, and flannel will handle communication on a single host, or multihost.

Deployment? Use fleet.

Not that all these are 100% perfect like I've made them out to be, but any individual component could be swapped out if you want.

Post reply on HN