4 ms·

Seems that people think Docker has gave in, but I am not that sure. If you can switch between Swarm/Kubernetes transparently, then why wouldn't you start with S

Seems that people think Docker has gave in, but I am not that sure. If you can switch between Swarm/Kubernetes transparently, then why wouldn't you start with Swarm? (I'm talking about small companies who're just starting with containers.)

grabcocque 9y ago
Why wouldn't you start with the one with the strongest mindshare and reputation? Even a cursory amount of googling shows there's a strong sentiment bias towards K8S over Swarm, it's not surprising that's what most people pick.
- sz4kerto 9y ago
  But the thing is that as a developer, it doesn't matter what you start with - you have both and you're using compose files, etc. So Docker is trying to make the orchestrator less relevant now, and says that 'don't worry about the orchestrator'. You, as a developer, are using Docker and Compose. (Or at least that's what Docker is trying to do here, I think.)
  - grabcocque 9y ago
    I don't think having support for multiple orchestrators is valuable except as a transitional thing. In this case, presumably, transitioning from Swarm to K8S. Nobody is gonna want the hassle of supporting both outside a transition.
    - shykes 9y ago
      It's extremely valuable for large IT organizations. Most of them have at least one deployment of each orchestrator, because of the proliferation of container projects in their various teams. They are very eager to adopt a single platform to manage it all. Now Docker EE can be that platform. In general enterprises don't like to be told "throw away your existing system to adopt my platform".
mrmondo 9y ago
Why wouldn’t you start with Kubes? Less vendor lock in and a much bigger community.
- drdaeman 9y ago
  Because K8s adds large amount of potentially unnecessary complexity? - Setting up Swarm is trivial, setting up Kubernetes is not so much (kubeadm is still not recommended for production, and there are valid reasons for this). I guess the only thing that's probably easier on K8s is (totally unsupported) multiarch cluster - it's somewhat messy with Swarm[1]. Although my experiments with multiarch K8s had failed (got issues with CNI stuff and postponed research for later). - Compose file format is significantly simpler and concise. Less code to write is good. - Debugging failing Swarm is significantly easier than debugging failing Kubernetes. Well, that's probably subjective and I haven't truly deeply debugged either, but at least I believe so - on occasions I was able to find my way through moby, swarmkit & libnetwork source, and K8s feels a very different beast. ____ Update[1]: I re-checked multiarch status for Swarm and found out that now `docker service create --name test --placement-pref 'spread=node.id' --replicas 2 --no-resolve-image ubuntu sh -c 'while true; do uname -a; sleep 1; done'` just works on a freshy set up mixed x86_64+armhf Swarm cluster (no multiarch alpine images yet, though - promised to come next week). Guess, Swarm had beaten K8s here.
- m3adow 9y ago
  Because K8s has quite some overhead, a steeper learning curve and is more difficult to set up and to maintain. I don't see this as a problem in bigger companies, but in companies with less than 10 IT people and no prior knowledge I'd take Swarm over K8s every day.
  - hosh 9y ago
    We have less than 10 people, 5 of them engineers. We are overbooked getting features out. We are using K8S in both dev and production, not Swarm. A big part of that is because I have had experience running Docker (not Swarm), ECS, K8S, and building developer tooling (Vagrant), in addition to being a regular developer. The flip side: I had to opportunity to try out these different tech in production and saw where the pain points are. The overhead of K8S exists to solve those pain points, though that is probably not that obvious to a small team without prior knowledge. For example, I had set up a prod k8s by hand. I will never do that again. On the other hand, I know roughly what is going on when something breaks in our Google GKE cluster.

grabcocque 9y ago

Why wouldn't you start with the one with the strongest mindshare and reputation? Even a cursory amount of googling shows there's a strong sentiment bias towards K8S over Swarm, it's not surprising that's what most people pick.

sz4kerto 9y ago
But the thing is that as a developer, it doesn't matter what you start with - you have both and you're using compose files, etc. So Docker is trying to make the orchestrator less relevant now, and says that 'don't worry about the orchestrator'. You, as a developer, are using Docker and Compose. (Or at least that's what Docker is trying to do here, I think.)
- grabcocque 9y ago
  I don't think having support for multiple orchestrators is valuable except as a transitional thing. In this case, presumably, transitioning from Swarm to K8S. Nobody is gonna want the hassle of supporting both outside a transition.
  - shykes 9y ago
    It's extremely valuable for large IT organizations. Most of them have at least one deployment of each orchestrator, because of the proliferation of container projects in their various teams. They are very eager to adopt a single platform to manage it all. Now Docker EE can be that platform. In general enterprises don't like to be told "throw away your existing system to adopt my platform".

mrmondo 9y ago

Why wouldn’t you start with Kubes? Less vendor lock in and a much bigger community.

drdaeman 9y ago
Because K8s adds large amount of potentially unnecessary complexity? - Setting up Swarm is trivial, setting up Kubernetes is not so much (kubeadm is still not recommended for production, and there are valid reasons for this). I guess the only thing that's probably easier on K8s is (totally unsupported) multiarch cluster - it's somewhat messy with Swarm[1]. Although my experiments with multiarch K8s had failed (got issues with CNI stuff and postponed research for later). - Compose file format is significantly simpler and concise. Less code to write is good. - Debugging failing Swarm is significantly easier than debugging failing Kubernetes. Well, that's probably subjective and I haven't truly deeply debugged either, but at least I believe so - on occasions I was able to find my way through moby, swarmkit & libnetwork source, and K8s feels a very different beast. ____ Update[1]: I re-checked multiarch status for Swarm and found out that now `docker service create --name test --placement-pref 'spread=node.id' --replicas 2 --no-resolve-image ubuntu sh -c 'while true; do uname -a; sleep 1; done'` just works on a freshy set up mixed x86_64+armhf Swarm cluster (no multiarch alpine images yet, though - promised to come next week). Guess, Swarm had beaten K8s here.
m3adow 9y ago
Because K8s has quite some overhead, a steeper learning curve and is more difficult to set up and to maintain. I don't see this as a problem in bigger companies, but in companies with less than 10 IT people and no prior knowledge I'd take Swarm over K8s every day.
- hosh 9y ago
  We have less than 10 people, 5 of them engineers. We are overbooked getting features out. We are using K8S in both dev and production, not Swarm. A big part of that is because I have had experience running Docker (not Swarm), ECS, K8S, and building developer tooling (Vagrant), in addition to being a regular developer. The flip side: I had to opportunity to try out these different tech in production and saw where the pain points are. The overhead of K8S exists to solve those pain points, though that is probably not that obvious to a small team without prior knowledge. For example, I had set up a prod k8s by hand. I will never do that again. On the other hand, I know roughly what is going on when something breaks in our Google GKE cluster.