7 ms·

A shame, really, but not a huge surprise that products like Swarm fell by the wayside. I feel it could've occupied a nice middleground for teams that didn't nee

A shame, really, but not a huge surprise that products like Swarm fell by the wayside. I feel it could've occupied a nice middleground for teams that didn't need the full capabilities (or overhead of supporting) Kubernetes, even though I think K8s is an exceptional project. I chose Swarm as a pragmatic choice in an enterprise environment that didn't have any prior experience with Docker at all, really, at the operational level. We had to support financial models, often many different versions of the code at the same time, on top of the usual stack of applications to go with that. The choice was a "success", albeit one muted by the wacky networking layer they use. Compound that with RHEL's older kernels, and we had to deal with oddball issues like iptables/arp table getting out of sync with what's actually running, resulting in connectivity issues. And don't get me started on removing and redeploying a stack; that would occasionally wedge things so badly we had to cycle the docker daemon. Still, a shame. The gap between "Look, I wrote a compose file" and running something on a small cluster is tiny, and that was its main strength, even if it did suffer from some serious heisenbugs. Why they decided to add and remove features between versions and do their damndest not to make a compose file 100% "forwards compatible" with Swarm is another mystery.

usgroup 8y ago
Swarm was a pretty big mistake. I think based on just relative resource investment compared to Kube, it ought to have been obvious that it’d never be relevant if it wasn’t extremely specialised.
- mickeyp 8y ago
  That's true. However, consider this environment: - The ops team are in a different country, and are wedded to very old-fashioned views of administration ("Automation? But I like manually running commands from a runbook!") - You work with a team of people who are quants/actuaries/scientists/engineers but not professional developers, but you want them to have a turn-key environment so they can Get On With It. When they need new python packages or god forbid upgrade pandas or something else, there's a full CI chain that'll make sure that what they do here also works there. - Swarm is (from personal experience) easy enough to teach people who don't know anything about Docker. You can show them how to query the state, modify it, look at logs, etc. all without the hassle and overhead of configuring and running K8s, even though it will always be my #1 choice for tech-literate orgs. Swarm, for many, including myself, was a pragmatic choice -- 80% of the immediate benefit of container orchestration with 20% of the cognitive overhead for the chaps in another country who had to maintain it if things went south.
  - usgroup 8y ago
    Sure and then google release “kubelite” or some guy writes a convenience script and there goes your competitive advantage for the use case :) Docker didn’t have enough of an advantage even though Swarm game shipped with it, so de facto if you had Kube you would have had Swarm first...
    - mickeyp 8y ago
      I made a tradeoff; keep in mind, it's not always the case that the best technology wins. Running <Technology X> is all well and good, but if you cannot keep it running perfectly, or it results in unacceptable downtime due to operator error, then that reflects poorly on the architect/lead in charge of picking the tools. I am more of a mind to make sure that I can solve the task(s) that I am given, such as it is, with the resources available (people, knowledge, time, etc.). That inevitably means tradeoffs. In a parallel universe I would have used K8s instead, as I think it's exceptional and far superior to Swarm. However, with the limited resources available, I chose Swarm, and for all its faults it's running fine.
      - fatherlinnux 8y ago
        I agree with your pragmatism (and admire it). I would only urge you to add a couple of tools to your toolbelt for analysis: 1. Open source politics aka is the project viable? 2. Where's the money coming from? Aka, what products/companies build solutions off the tech? 3. Look for growth, not survival. If a company is not growing, it is dying. These extra three test "gates" help me select what technology I will use, learn, and bet my career on....
        mickeyp 8y ago
        Keep in mind, when this solution was adopted Docker were still wedded to Swarm. Even if they stop caring about it -- as they pretty much have now -- we have a system that works at rest. Two years on, the team(s) that handle the production support and operations are more comfortable with Docker & co, because of this. Not to forget, this is a very large (and risk-averse) enterprise. You don't always get to pick whatever you like!
- drdaeman 8y ago
  Smarm had and still has a huge advantage over Kubernetes - it's its simplicity. I wouldn't call Swarm "simple" but it's "tolerably complex". Unlike Kubernetes, Swarm deployments are actually maintainable by a small team (or even a solo sysadmin). If there is a bug (there always are), you can actually diagnose or even debug it without the feeling that you're wrestling with a 800-lb gorilla.
_shadi 8y ago
Not a containers expert and I never used docker swarm, but I will still go with Nomad for container orchestration over Kubernetes anytime I can, gets the job done with minimal fuss.
- tedmiston 8y ago
  Would you still do this even if you had K8s available as a managed service?
- fatherlinnux 8y ago
  See my three rules above. Engineering is a zero sum game, even in open source. Nomad has a very dark future. Single vendor, no community, very little usage, no competitors adopting the tech. If your competitors don't adopt your tech is dead (basic open source 101)...
user5994461 8y ago
Was it RHEL 6 by any chance? RHEL 6 was never supported by Docker.
- mickeyp 8y ago
  Nope - RHEL 7.x. Various incarnations, too.
encloser 8y ago
Similar story for me. Pretty much the only time I am disappointed with Docker Swarm is during monthly host OS patching and the networking gets messed up and we have to restart daemons and undeploy/redeploy stacks.
pmontra 8y ago
I've got a customer that uses docker to make binary distribution easier. All runs on a single machine and a docker-compose file is all they need. I don't think they'll ever need kubernetes unless they change the way they sell their products. Docker is useful for developers because we pull containers and run on Ubuntu and OSX them without having to install anything. Much easier than Vagrant.
GordonS 8y ago
I use Docker Compose for running all the things for my dev environment (RabbitMQ, Postgres, a few others), and it works really well. We'll, now it does - I had no end of networking troubles with it in the past, on both Linux and Windows. I love how easy it is to spin up something new with a simple YAML file, but I've no idea what it would be like in production - how are rolling updates handled, for example?
fatherlinnux 8y ago
I agree, there was a gap, especially for about 2 years. But, even when that gap existed, it was pretty clear that the cloud providers (and other software companies) would build/enable a one click Kube distros. As the cloud providers adopted Kube, I knew Swarm would loose. Now, the answer is, "use an API" don't run it local if you don't have to.

usgroup 8y ago

Swarm was a pretty big mistake. I think based on just relative resource investment compared to Kube, it ought to have been obvious that it’d never be relevant if it wasn’t extremely specialised.

mickeyp 8y ago
That's true. However, consider this environment: - The ops team are in a different country, and are wedded to very old-fashioned views of administration ("Automation? But I like manually running commands from a runbook!") - You work with a team of people who are quants/actuaries/scientists/engineers but not professional developers, but you want them to have a turn-key environment so they can Get On With It. When they need new python packages or god forbid upgrade pandas or something else, there's a full CI chain that'll make sure that what they do here also works there. - Swarm is (from personal experience) easy enough to teach people who don't know anything about Docker. You can show them how to query the state, modify it, look at logs, etc. all without the hassle and overhead of configuring and running K8s, even though it will always be my #1 choice for tech-literate orgs. Swarm, for many, including myself, was a pragmatic choice -- 80% of the immediate benefit of container orchestration with 20% of the cognitive overhead for the chaps in another country who had to maintain it if things went south.
- usgroup 8y ago
  Sure and then google release “kubelite” or some guy writes a convenience script and there goes your competitive advantage for the use case :) Docker didn’t have enough of an advantage even though Swarm game shipped with it, so de facto if you had Kube you would have had Swarm first...
  - mickeyp 8y ago
    I made a tradeoff; keep in mind, it's not always the case that the best technology wins. Running <Technology X> is all well and good, but if you cannot keep it running perfectly, or it results in unacceptable downtime due to operator error, then that reflects poorly on the architect/lead in charge of picking the tools. I am more of a mind to make sure that I can solve the task(s) that I am given, such as it is, with the resources available (people, knowledge, time, etc.). That inevitably means tradeoffs. In a parallel universe I would have used K8s instead, as I think it's exceptional and far superior to Swarm. However, with the limited resources available, I chose Swarm, and for all its faults it's running fine.
    - fatherlinnux 8y ago
      I agree with your pragmatism (and admire it). I would only urge you to add a couple of tools to your toolbelt for analysis: 1. Open source politics aka is the project viable? 2. Where's the money coming from? Aka, what products/companies build solutions off the tech? 3. Look for growth, not survival. If a company is not growing, it is dying. These extra three test "gates" help me select what technology I will use, learn, and bet my career on....
      - mickeyp 8y ago
        Keep in mind, when this solution was adopted Docker were still wedded to Swarm. Even if they stop caring about it -- as they pretty much have now -- we have a system that works at rest. Two years on, the team(s) that handle the production support and operations are more comfortable with Docker & co, because of this. Not to forget, this is a very large (and risk-averse) enterprise. You don't always get to pick whatever you like!
drdaeman 8y ago
Smarm had and still has a huge advantage over Kubernetes - it's its simplicity. I wouldn't call Swarm "simple" but it's "tolerably complex". Unlike Kubernetes, Swarm deployments are actually maintainable by a small team (or even a solo sysadmin). If there is a bug (there always are), you can actually diagnose or even debug it without the feeling that you're wrestling with a 800-lb gorilla.

_shadi 8y ago

Not a containers expert and I never used docker swarm, but I will still go with Nomad for container orchestration over Kubernetes anytime I can, gets the job done with minimal fuss.

tedmiston 8y ago
Would you still do this even if you had K8s available as a managed service?
fatherlinnux 8y ago
See my three rules above. Engineering is a zero sum game, even in open source. Nomad has a very dark future. Single vendor, no community, very little usage, no competitors adopting the tech. If your competitors don't adopt your tech is dead (basic open source 101)...

user5994461 8y ago

Was it RHEL 6 by any chance? RHEL 6 was never supported by Docker.

mickeyp 8y ago
Nope - RHEL 7.x. Various incarnations, too.

encloser 8y ago

Similar story for me. Pretty much the only time I am disappointed with Docker Swarm is during monthly host OS patching and the networking gets messed up and we have to restart daemons and undeploy/redeploy stacks.

pmontra 8y ago

I've got a customer that uses docker to make binary distribution easier. All runs on a single machine and a docker-compose file is all they need. I don't think they'll ever need kubernetes unless they change the way they sell their products. Docker is useful for developers because we pull containers and run on Ubuntu and OSX them without having to install anything. Much easier than Vagrant.

GordonS 8y ago

I use Docker Compose for running all the things for my dev environment (RabbitMQ, Postgres, a few others), and it works really well. We'll, now it does - I had no end of networking troubles with it in the past, on both Linux and Windows. I love how easy it is to spin up something new with a simple YAML file, but I've no idea what it would be like in production - how are rolling updates handled, for example?

fatherlinnux 8y ago

I agree, there was a gap, especially for about 2 years. But, even when that gap existed, it was pretty clear that the cloud providers (and other software companies) would build/enable a one click Kube distros. As the cloud providers adopted Kube, I knew Swarm would loose. Now, the answer is, "use an API" don't run it local if you don't have to.