[adamtulinius]

Why did you pick Swarm for production?

We followed Swarm from the beginning, but after a few releases at v0.4 it was clear not to ever use Swarm, and that it mostly was the Docker PR machine that made it sound nice, and not the actual features.

Maybe it got better later on, but the first several Swarm announcements seemed really off-putting to me.

We ended up on Mesos/Marathon, not that that has a bright future either, but it was at least capable of restarting containers from the beginning..

Just migrate to Kubernetes. It has won.

[smoyer]

When we started looking for a container orchestration system, we naturally used Google Trends (https://trends.google.com/trends/explore?date=today%205-y&q=...). Kubernetes reached their 1.0 release shortly before we were ready to start using the system and a lot of the features added since then eliminated so of our other problems (e.g. configmaps/secrets combined with the existing service discovery pretty much eliminated our plans to use Consul).

I've been taking a second look at Mesos recently and found that I didn't really grok it the first time I looked at it. In any case, I think your assessment is correct ("Just migrate to Kubernetes" - https://trends.google.com/trends/explore?date=today%205-y&q=...).

[eecc]

Hmm, that k8s “has won” might make me a bit sad - not that I’ve ever gasped some fresh air out of the stranglehold of AWS - as I was impressed with Mesos.

Can you share some 1st person opinions on Mesos, and where K8s is a step forward, backward or aside?

TIA

[tveita]

Having moved from Mesos to Kubernetes, Kubernetes just felt more mature. Working solutions for stateful sets, service discovery with DNS, flexible scheduling with affinity and tolerance, saner resource limits, a good CLI tool.

It's not a completely fair comparison since we also were able to offload persistent storage to Google Cloud, which is one of the harder problems IMO.

I think Mesos has improved since then, but it always felt like they were a bit behind.

In general Kubernetes feels like it is designed by people with relevant experience. Especially compared to our earlier experiments with Docker Compose files. People are praising their simplicity, but they left us solving a lot of hard problems that Kubernetes solves for us better than we could have done.

[manigandham]

Why is it sad? It's great that we can finally standardize and use a single powerful system that is very capable but also improving quickly.

[sandGorgon]

i would encourage you to try Swarm. Its brilliant in its simplicity. I think Docker product marketing and customer success basically sucks. But Swarm as a product has been really, really nice. And yes I continuously evaluate kubernetes and swarm side by side.

You can get a swarm cluster running in less than 10 minutes on your local laptop after "apt-get install docker-ce". To run k8s, you will need to first muck about ingress and overlays and everything else.

I know its because of "flexibility" - its like Sinatra vs Rails. They are both great in their spaces.

[pacala]

    $ brew cask install minikube
    $ minikube start

[sandGorgon]

minikube is a specific version/distro/packaging of kubernetes meant for testing on local laptop.

Docker Swarm runs exactly the same way with exactly the same components and with the same ease on laptop as well as the cloud.

TL;DR - you cant run minikube in production.

[pacala]

I see your point. For k8s production, you'd have to use a solution provided by the cloud operator, GoogleKE / AzureKS / AmazonKS / etc. Which leaves the on-prem cluster and/or baremetal hosted cluster uncovered. Not that I'm convinced it's worth running baremetal anything, you're likely to be less efficient than large cloud operators because of economies of scale.

Nit: $ minikube get-k8s-versions The following Kubernetes versions are available when using the localkube bootstrapper: - v1.9.4 - v1.9.0 - v1.8.0 - v1.7.5 - v1.7.4 - v1.7.3 - v1.7.2 - v1.7.0 - v1.7.0-rc.1 - v1.7.0-alpha.2 - v1.6.4 - v1.6.3 - v1.6.0 - v1.6.0-rc.1 - v1.6.0-beta.4 - v1.6.0-beta.3 - v1.6.0-beta.2 - v1.6.0-alpha.1 - v1.6.0-alpha.0 - v1.5.3 - v1.5.2 - v1.5.1 - v1.4.5 - v1.4.3 - v1.4.2 - v1.4.1 - v1.4.0 - v1.3.7 - v1.3.6 - v1.3.5 - v1.3.4 - v1.3.3 - v1.3.0

[rmetzler]

I used this for baremetal: https://github.com/kubernetes-incubator/kubespray

[rmetzler]

I used kubespray to set up a Kubernetes cluster on our own hardware. I have Ansible and Docker knowledge and ran into a few issues, but it didn't take much time to set up a custom cluster. It's still different as I had issues accessing the UI, but I think it'll become even more easier in the next month.

[wstrange]

Creating a k8s cluster on GKE is just as easy (a single gcloud command, or use the GUI if that is your preference).

With hosted Kubernetes as a service (GKE, AKS and soon EKS), there is little reason to roll your own cluster.

[Axsuul]

But you see with Docker Swarm, you don't need "Docker Swarm as a service". That's why Docker Swarm wins in simplicity.

[orf]

It's just Kubernetes in a VM, like Docker on Mac is just docker in a VM.

You can run Kubernetes on your Linux device machine as-is.

[Axsuul]

It's what's in the VM that counts.

[dahidahi1]

What about HA / clustering, security mTLS?

[pacala]

Why would you want any of those on your laptop?

[dahidahi1]

Because that is how I will deploy on production. At least the security pieces. Any difference & I am not sure if I can be assured of preventing the "works on my machine" kind of issues.

[jrs95]

Is HashiCorp’s Nomad in a similar position at this point? I really enjoy it’s (relative) simplicity.

[jacksonnic]

Nomad is very much alive and HashiCorp is committed to delivering a scheduler which concentrates on operational simplicity so teams can concentrate on building applications. It also gives the capability for running workloads other than Docker such as isolated fork for binaries, non containerised Java, etc. We have a great release with 0.8 and many features planned for the rest of the year.

Integrating Nomad with Vault and Consul is super easy and allows you to provide secrets, configuration and service discovery to the application with the right layer of abstraction, the application should not be aware of the scheduler it is running on. Cloud auto join allows super easy cluster config. Job files are declarative.

Yes, Nomad does not have all the features of Kubernetes, but we take a different approach believing in workflows and the unix phillosophy of a single tool for a single job. A fairer comaprison would be to comapare the HashiCorp suite of OSS tools to K8s, Nomad, Vault, Consul, Terraform, this gives you capabilities to manage your workload both legacy and modern.

[hosh]

I don't know about Nomad, though Hashicorp's Vault is going to do just fine I think. It fills in a gap in secrets management that K8S doesn't do out of the box.

Looking at doing Vault in HA leads people to look at Consul, which leads to Nomad. (Consul uses a consensus protocol for service discovery and I think that will be interesting for the next generation).

Last year, K8S had already captured the center of gravity, and it took a while for the rest of the dev community to catch up.

I think this year ia a lot of shuffling as the survivors settles into orbit around K8S. There is a lot of interesting innovations up the stack once orchestration is de facto standardized.

K8S still hasn't solved the stateful workloads, though it is introducing a lot of primitives to support those: controller hooks, third part resources, on top of which Operators can function.

I think we will see a lot more innovations as people create Operators. That can include anything from stateful loads for specific distributed stateful loads, to things like intrusion detection, ML-driven autoscaling, and so forth.

[wmf]

I get the impression that Nomad was never particularly alive to begin with, which is a shame since it seems better designed. But it doesn't have that "ZOMG Google has blessed us with the secrets of the borg" that DevOps crave.

[rmetzler]

Nomad was my choice for queue centric workloads, but it doesn't seem to fit the webserver / long living services as good as Kubernetes. I'm not sure, but I would think you could run Nomad and Kubernetes on the same servers, sharing the Docker runtime.

[wmf]

If you run two schedulers they don't have a correct view of available capacity. You can use Mesos as a meta-scheduler but that introduces more complexity.

[fapjacks]

I, too, was sad to see similar things with Nomad. HashiCorp really does write generally excellent software.

[sz4kerto]

The actual features are very nice. I don't know what else makes you say 'migrate' apart from the fact that there's a growing support for k8s. The advantages of Swarm (very easy setup in private clouds, docker-compose format descriptors,etc.) don't go away just because k8s is popular.

Stop spreading FUD please, it is not good for anyone.

[dahidahi1]

There were two swarm's, the swarm classic — which was okayy, & then the newer swarm Mode, introduced in docker 1.12. I'm not sure which one you refer to when you say v0.4. But swarm mode was good, extremely simple & worked well for the right workloads. Like most solutions it is not a silver bullet for every orchestration need, but worked very well in microservices, new-ish architectures. K8s is great too, but it seems like an overkill for a handful of services. Also setup of K8s used to be hard, especially HA. The learning curve is also quite steep. One of the features in swarm mode that makes docker swarm extremely intuitive — IPVS, is being incorporated in K8s. So I guess there has been some cross pollination on both sides. But I do not think the swarm mode is going to die anytime soon.