We will be happy if Docker talks about Swarm becoming a management UX for K8s - but we need visibility. These are production orchestration systems. The migration path is not easy.
And seeing what Docker Co is doing with Cloud, it is not very comforting to trust that they will do the right thing with Swarm.
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.
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=...).
Can you share some 1st person opinions on Mesos, and where K8s is a step forward, backward or aside?
TIA
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.
Stop spreading FUD please, it is not good for anyone.
Which is a pity because I really liked Swarm for its simplicity.
Side note: I am also concerned about Docker in general. CE/EE split, services shutting down, bugs seemingly not being fixed - I cannot point out a precise aspect, but I am concerned.
In our tests about a year ago, swarm started showing serious networking and cluster synchronization problems with cluster sizes over 30 nodes (physical servers), on a fast, reliable LAN.
I've heard similar stories from another big Docker customer- Docker support promised them that improving performance of Swarm and fixing scaling issues are the focus of "the next version", but they never came. This company is now moving to k8s.
Public statement on their blog after the K8s announcement in EU:
"But it’s equally important for us to note that Swarm orchestration is not going away. Swarm forms an integral cluster management component of the Docker EE platform; in addition, Swarm will operate side-by-side with Kubernetes in a Docker EE cluster, allowing customers to select, based on their needs, the most suitable orchestration tool at application deployment time."
https://blog.docker.com/2017/11/swarm-orchestration-in-docke...
There's still plenty of PR's and activity in the SwarmKit and Libnetwork repos:
https://github.com/docker/swarmkit/pulse/monthly https://github.com/docker/libnetwork/pulse/monthly
Then, they cancelled it, no more patches, no mention of it anywhere unless you know where to look.
Then they created Swarm Mode, and add the concept of "services" which sucks compared to regular run because it lacked so many options the run command had, it took more than 6 months to implement most of them.
To be fair docker cloud was never great and hopefully it doesn't have many big customers...
But the precedence of shutting down a paid service with 2 months notice is not nice. What would happen if this was docker hub? Panic!
Isn't docker hub relatively easy to replace, in comparison?
Otherwise, is this a wakeup call perhaps?
Traditional package managers have two distinct concepts: a repository and packages within those repositories.
For example, if ubuntu took down their apt repo server, I could run my own with all the same packages and change a single sources.list entry and all my servers, ansible roles installing packages, etc, would operate the same.
This is possible because the package name+version is an identifier everything else uses and the only thing that cares about the repository is apt itself; all other tooling doesn't need to know about the repository the package is sourced from.
Docker conflates those two things. Each client doesn't just send a package name, it sends a url + package name + version (e.g. foo.registryurl.com/image:version). Because every single client has the detail of "foo.registryurl.com" baked in, it's difficult to change that. I can't change a single "repository-mapping" file that the docker daemon reads to quickly update it.
Instead, I have to update every single client.
The idea of decoupling those is not new. In 2014 it was proposed [1], and various implementations that would help make it easier to migrate off the default registry have been proposed and rejected [2]
This doesn't even get into the lack of tooling for chasing down the transitive dependencies building my images has on various registries with each FROM.
[1]: https://github.com/moby/moby/issues/8329
[2]: https://github.com/moby/moby/pull/5821#issuecomment-49492924
People. People are up in arms.
Anyway, yeah, that's insane. Even Google, who constantly shuts stuff down, usually does so with way more heads up. For comparison, Google Reader, a completely free service, shut down with 3.5 months advance notice. Google Wave got almost 6 months notice.
Migrating off docker cloud will be a pain, but the service was already a pain to use, so maybe it's about time anyways.
But imagine being given 2 months to migrate off docker hub for image storage. Panic would ensue :)
edit: typos
The whole point of containers is that they are ephemeral and can be booted up quickly anywhere because you statically link the whole fucking OS?
Docker cloud is no loss (with apologies to those who are using it in production) and will hopefully free up your people to work on other important stuff.
Otherwise if we can continue to use the compose configuration api and the docker deploy/service api with k8s under the hood then I guess that's a reasonable compromise.
I imagine the service wasn't really making money, and to add GDPR compliance on top, could have been the last straw (or a contributing factor)
On a meta thought, I wonder what potentially caused this move. It is/was a pretty decent service.
They should have announced it earlier and should have given more time to paying customers. I am glad I migrated very early.
I played around with it a long while ago and really liked it, but felt like more moving parts (and particularly on MySQL, which wasn't in our stack) wasn't something I was too keen on. Having someone manage this for us could be worth paying for though.
And it always lost its ip sec connections and only a reboot helped.
I liked it though...
I think Microsoft still employs thousands of great engineers and have been early embracers of containerization among the large companies out there and because Satya was a large part of growing Azure into what it is (IMHO a pretty solid set of services) it could make a lot of sense
Tutum actually worked and I really liked it. Now I plan to use Rancher on top of kubernetes for my docker hosting
Docker Cloud was getting worse and worse. Tutum (they acquired, rebranded and killed it) was great. But docker team just destroyed it.
That is a shame. Tutum was great since it scaled up and down very well. Nobody thinks about scaling down, but this is important in many ways.
Right now IMO: - Docker swarm - scales up and down ok. Had too many bugs with even on stable. - Rancher - fine, very good for medium deployments. - k8 - winner for larger scale but scales down badly.
This is really sad.
I've been working on a Docker Cloud alternative for awhile now. I'm aiming for something that kind of balances the convenience of Heroku with the Docker experience.
It's still in beta but if anyone wants to check it out it's at: https://codemason.io/
Kubernetes “won” so now the competition has shifted from who can innovate to who can execute and operate.
Well, "won" in quotes. I am not a k8s fanboy or anything, I simply observe that all the major cloud providers are offering managed k8s services that have superseded their own proprietary container-type offerings. For better or worse that's where the momentum is. If you wanted to containerize your stack right now, k8s then pick one of the big 3, seems like a safe bet.
There's a reason why people and businesses hate vendor lock ins. There's a reason why we do not want AWS to reign supreme for long.
