Hacker News new | comments | show | ask | jobs | submit login

Have to say, I don't see the value in being able to have Swarm and k8s in the same cluster.

"Docker: powered by Kubernetes" seems to be more of a marketing thing to move down the value chain, and not be seen as a basic piece of infrastructure.




Agreed, just seems like marketing vaporspeak. Not exactly a trustworthy source, too.

For example, containerd has been moved to the CNCF and made a broader project. Fine, but Docker runs a separate fork of containerd anyways. A neat marketing sleight-of-hand, but to what end?


You can disable Swarm or Kubernetes at will in each Docker EE cluster. Hybrid is very useful for enterprises who already have to manage both - it was a highly requested feature.


I think I can understand "We have both and need to manage them more easily" as a request, because it's about pain right now.

The thing I'm unsure about - and it would be really interesting to get your perspective on - is what this means for Swarm longer-term. Is there still going to be a reason why people will want hybrid? Is it a migration play?

In a hybrid, over time I'd want to two to behave the same, and getting k8s up and running is a one-time cost and likely decreasing maintenance. It seems like a point solution.


Swarm has a very special role, because it's custom-built to integrate in the Docker platform. Because it's so specific, it has a smaller standalone community than Kubernetes, but it makes up for it in focus and speed. You should expect a lot of bleeding edge features to ship in Swarm first, and a generalized version to land in kubernetes later. That's already been the case in the past: Windows support, secrets, node identity & promotion - those all shipped in Swarm first, then made their way to Kubernetes. Not because Swarm developers are smarter, but because they can focus on a narrower, more integrated problem set.

Longer term, I think all orchestrators will converge to look more and more the same. Orchestration will become a commodity, and it will matter less and less which orchestrator you use, especially to developers. But this process will take a long time, and in the meantime enterprises (our primary customers) need to deal with the situation on the ground, which is a lot of Swarm and Kubernetes living side by side because of historical decisions made in 2015-17.


> You should expect a lot of bleeding edge features to ship in Swarm first

The development of those bleeding edge features is well hidden. The contributions graphs seem to indicate that Swarm is at best a ghost town. Perhaps the action is happening somewhere else and/or Docker will start investing in Swarm once more.

https://github.com/docker/swarm/graphs/contributors


You may be looking for swarmkit https://github.com/docker/swarmkit


Correct :)


"which is a lot of Swarm"

I think that's an overstatement. I talk to a lot of professionals in this area and never seen Swarm deployed to production (from small to big corps). Anecdata warnings apply.

Could you share some numbers?


A good starting point is the archive of Dockercon talks, we've had quite a few enterprise customers come on stage to describe their production deployments.

Or check out the customers section on docker.com.


K8S is looking for all the world like it's becoming the One True Container Orchestration Platform. Obviously Docker can't admit that because it has investors, and one thing you can't afford to do with investors is be honest. But reading the runes, it sure looks like Docker are providing a migration path from Swarm to K8s.


Could be a nice bridge to move off docker :P




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: