[zebra9978]

What do people generally think about Docker Swarm ? The new deployment using .yml files is pretty cool : https://www.infoq.com/news/2017/01/docker-1.13

In fact, IMHO kubernetes has tried to do something similar with .. but it is not engineered ground up for simplicity. Which is why it has MULTIPLE tools for this - minikube, kubeadm, kompose - but nothing matching the ease of use of docker and its yml files.

The last survey showed 32% of the polled used Docker Swarm versus Kubernetes' 40% - and this is back when Docker Swarm was highly unstable. https://clusterhq.com/2016/06/16/container-survey/#kubernete...

Are people here using Swarm ? what have your experiences been like.

[moondev]

Kubernetes deployments are done via yml (or json) files too. They are called manifests.

I think you are misunderstanding the tools listed. Minikube sets up a single-node local cluster. Kubeadm sets up a multi-node cluster. No matter how or where your cluster is set up, you still deploy with manifests.

[zebra9978]

I have deployed several clusters with kubernetes and with Swarm. I think my wording was hyphenated at the wrong place. Swarm has a new yml file format - the compose v3 which is pretty damn awesome. Kubernetes has had yml files for a while, but the gap in simplicity/usability is massive.

Which is what my point was with minkube and kubeadm and kompose - for swarm, you use a single tool for either a single node cluster.. or a multi node cluster. Even more, kompose was invented to read from the same Docker Swarm compose file format - because it is so intuitive.

I'll go one step further - kubeadm does not actually have high availability support, so you actually have to use kargo or kops to reasonably deploy in production.

Kubernetes introduces a lot of upfront complexity with little benefit sometimes. For example, kargo is failing with Flannel, but works with Calico (and so on and so forth). Bare metal deployments with kubernetes are a big pain because the load balancer setups have not been built for it - most kubernetes configs depend on cloud based load balancers (like ELB). In fact, the code for bare metal load balancer integration has not been fully written for kubernetes.

Now, my point is not that kubernetes sucks - I think its a great piece of tech. But its around why do people think Docker Swarm will die.. or that it sucks? Because, relatively speaking, while kubernetes NEEDS all kinds of complicated orchestration tools (and consultants!) to set it up .. Swarm on the other hand is damn easy to setup by a developer building his first stack.

Is Docker Swarm the heroku to Kubernetes AWS ?

[predakanga]

The issue that I have with the newly imagined Docker Swarm is that it continues Docker's trend of trying to be a jack of all trades.

I have no specific examples for Docker Swarm, but using this approach in other areas has led to some pretty major deficiencies in Docker's design that they have been slow to fix, and I'm not keen on seeing that happen again.

For a concrete example, see https://github.com/docker/docker/issues/19474 - in a minor release, they completely changed how DNS worked and broke previously working systems (i.e. https://github.com/weaveworks/weave/issues/2157), all in the name of service discovery

[zebra9978]

I see.

incidentally the embedded DNS feature is fairly extensively leveraged by kubernetes - it takes of the situations where you dont want to muck around with underlying /etc/hosts (on the actual metal) and do your changes only on the containers.

But I'm hearing what you are saying more and more - Docker Inc is having a huge PR problem. Docker Swarm may actually be good, but people are generally disliking the organization itself.

You dont see these kind of answers with Fleet, Mesos..even Openstack. Docker Swarm is a genuinely sweet piece of tech.. so this is rather unfortunate.

[mentat]

They have a PR problem because they break interfaces in minor releases and have actively pushed back on criticism for doing so as "they need to be agile" and "can't be boxed in by competitors".

[vidarh]

My biggest issue with swarm is when you have clusters that also needs scheduling of non-Docker workloads.

[EtienneK]

I would also like to know the answer to this question. Every time I try setting up a Kubernetes cluster, it's an exercise in frustration. Docker Swarm is much easier in comparison.

Add to the fact that Docker Swarm is adding Enterprise features (such as Secrets in 1.13) and that is has an Enterprisey version (Docker Datacenter) which supports multiple teams, why would I - an Enterprise developer and architect - look at Kubernetes over Docker Swarm?

[orf]

My £0.02 is that Kubernetes has the backing of Google who have a tremendous amount of experience with container orchestration. And while using Kubernetes it really shows, things are pretty well thought out, lots of features out of the box etc.

With docker swarm it's taken them this long to get simple secrets integrated, and as with all of my experiences with first party docker tools: they seem ok at first, but the devil (and problems) are in the details.

I trust Google more to get this right, and I highly doubt Kubernetes is going anywhere.

[nul_byte]

Red Hat are doubling down on Kubernetes too (second biggest contributor to Kubernetes), and if there is anyone who is good at taking parts of an opensource eco system and supporting them for an enterprise, its Red Hat.

[gnur]

Because Kubernetes, even though it is still young, is a lot more mature then Docker Swarm.

Kubernetes is also based on years of running containers with Google itself, it solves real problems. Allowing containers to run in the same pod allows for much nicer composability than running multiprocess containers.

Have you tried setting up a k8s cluster recently, I believe they added kubeadm for much easier setup in 1.5, which was released a few weeks ago.

[nollbit]

The other responses to your posts are great, but I'd like to add one thing to them;

Why are you equating low barrier of entry with quality? I think MongoDB ought to have taught everybody in this field that you can have a low barrier of entry and still be a crap product.

[raesene6]

I didn't see any mention of quality in GP's post... For me Docker swarm is a simpler implementation than Kubernetes and likely more suitable for simpler deployments.

Kubernetes whilst a cool product still has a lot of rough edges even now. One I encountered recently was that to upgrade a locally deployed cluster from 1.4 to 1.5 the answer appears to be "re-install from scratch" as the upgrade script is still "experimental" (https://kubernetes.io/docs/admin/cluster-management/#upgradi...)

[Axsuul]

I've tried both. Kubernetes is targeted really towards large production clusters -- even kubernetes itself requires quite a bit of resources. A single non-HA cluster initialized by kubeadm for example couldn't even schedule itself on a n1-standard-1 machine on GCE.

For a MVP or a small production stack that runs on one server, I would go with Docker Swarm for its simplicity and small footprint. And even if you do end up scaling across many nodes, you still won't need k8s (kubernetes).