<p><strong>Update:</strong> Docker just released <a href="https://www.docker.com/kubernetes" rel="noreferrer">support for Kubernetes</a> as scheduler, which changes the situation and makes Kubernetes just an alternative scheduler to Docker Swarm. </p>

<p><strong>TL;DR: DON'T DO IT.</strong> Engineers <a href="https://github.com/docker/swarm-frontends" rel="noreferrer">always try</a> to create these dog-pigs. Every unnecessary technology you bring will bring another whole set of faults. If you can pick one, then pick one and be happy you don't have to do both. If you like to play with Kubernetes, just get a private account on Google Cloud and play with it as much as you like. But don't make everyone at your company suffer through unnecessary complications.</p>

<p>Those are two <a href="https://technologyconversations.com/2015/11/04/docker-clustering-tools-compared-kubernetes-vs-docker-swarm/" rel="noreferrer">parallel</a> and mostly equivalent <a href="https://insights.hpe.com/articles/the-basics-explaining-kubernetes-mesosphere-and-docker-swarm-1702.html" rel="noreferrer">technologies</a>. If your business had legitimate business reason to <a href="https://www.containership.io" rel="noreferrer">deploy</a> in <a href="https://thenewstack.io/containers-microservices-and-the-multi-cloud/" rel="noreferrer">multiple Cloud</a> providers <a href="http://www.stratoscale.com/blog/cloud/running-containers-multi-cloud-environment/" rel="noreferrer">for reliability</a> for example and wanted to deploy into both AWS <a href="https://aws.amazon.com/ecs/" rel="noreferrer">ECS</a> (Elastic Container Service - based on Docker) and Google <a href="https://cloud.google.com/container-engine/" rel="noreferrer">GKE</a> (Container Engine - based on Kubernetes) and you were asking how do you build a pipeline, which would build your software and package in containers for <a href="https://leanpub.com/the-devops-2-toolkit" rel="noreferrer">deployment in both</a>, that would be something else, but doing it just because you want to play with a new technology is very irresponsible.</p>

CC BY-SA 3.0
2017-04-12T11:38:05.800Z
I wouldn't say I want to 'play' with Kubernetes. There are business reasons why I prefer it over Swarm. One being the community and your assumption that I just want to do something is wrong. I don't disagree with your dog-pig comment, coming from a systems engineer position I have seen/prevented these many times, or at least tried. You haven't provided any indication that you have worked with either with lessons learned, nor any technical details as to why; I don't feel this addresses my question.
EvanM
CC BY-SA 3.0
2017-04-12T11:45:46.887Z
I use 'play with' instead of 'work with' sometimes  partly in the sense of work os fun and partly based on my mother's favorite: "You just play with computers all day and never do any real work." :)
Jiri Klouda
CC BY-SA 3.0
2017-04-12T11:49:20.127Z
Gotcha, I do the same. Just wanted to make it clear that this wasn't some half hazard attempt to force Kubernetes down the throats of my company. Hence the question. Gut feeling is that there is no 'good' reason but I couldn't simply ignore that article either.
EvanM
CC BY-SA 3.0
2017-04-12T11:53:17.517Z
Look, we have all been there. The business plans to go with one technology, when you think the other is better and you want to somehow still work with the other or at least both and show them down the line how your choice was so much better. It is a classic. No matter what you think, don't combine the two for the sake of doing it or to prove you are right. Even if you could justify it, your job is to design the solution to avoid doing so. KISS. Make it work with Swarm, convince everyone to use Kubernetes or quit and work in place where they will use Kubernetes.
Jiri Klouda
CC BY-SA 3.0
2017-04-12T03:35:43.343Z
2017-10-17T20:59:04.947Z
2017-10-17T20:59:04.947Z
Jiri Klouda
<p>One reason to with Kubernetes as a scheduler if you use or would consider Azure as a cloud provider is their relatively new AKS service (managed kubernetes). In this case you would not combine kubernetes with docker swarm though. </p>

<p>This to me is clear indication as to where the community is going. I would not want to learn something that I would later need to throw in the trash can.</p>

CC BY-SA 3.0
2018-03-26T22:27:12.303Z
2018-03-26T22:27:12.303Z
PussInBoots
<p>My company is trying to play a little catch-up in the DevOps space. I have been doing a lot of research on containerization of applications and the orchestration systems that go with it. I came across an article (one that I wish I had saved) where they were talking about combining Swarm with Kubernetes to get better functionality. In this article they did not define what they gained by doing that.</p>

<p>I wondered what benefits would this provide? Is adding the extra layer of complexity really going to give you much return?</p>

<p><strong>EDIT:</strong> I am looking for technical pro's/con's. KISS is a good motto but doesn't hold up in a debate with your CEO or Board. </p>

<p>I am almost positive that we will be selecting Docker for our containers and Swarm for an orchestration. I, however, would like to see Kubernetes in our space so the proposition that you could merge the technologies together for a more robust solution intrigues me.Thanks for any insight.</p>

CC BY-SA 3.0
2017-04-26T08:49:51.967Z
The operative words here are 'intrigues me'. You are part of a business. There should be a valid business reason for doing this. Not your interest, not technical wizardry, a solid business reason to combine those two. If there is no such business reason to start with, inventing it is simply unethical. What you are proposing is leading to wasting of the business resources for personal reasons and ethically it is akin to embezzlement.
Jiri Klouda
CC BY-SA 3.0
2017-04-26T12:47:17.867Z
I debated on whether to respond to this or not because frankly, I feel as though this conversation is a waste of time. Yes, I am part of business, yes it intrigues me, no I am not inventing anything and the attitude you have had from the get go is unwarranted. Intrigue is what drive technology forward, looking for reasons why/ why not is part of the job and simply asking questions of those who have gone before you is a best practice. This question was meant to get feedback from people who have actually done work on these platforms and have valid opinions on the subject.
EvanM
CC BY-SA 3.0
2017-04-26T12:48:22.330Z
Iam not looking fora philosophic debateon buzz words or cute acronyms Iam looking for technical benefits or short comings and where gaps can be filled if necessary. Everything postedhas been an opinion with no factual arguments. I would appreciate it if you could explain which technology you use to solve containerization and orchestration and the short comings you have found with it. At that point itis for me and my business to decidewhat is the best road for us to take. Research is not embezzlement or stealing, it is called duediligence and it is how goodtechnology turns into great solutions.
EvanM
CC BY-SA 3.0
2017-04-26T16:09:53.943Z
You might be asking in a wrong forum then. DevOps is a discipline about how to make business more efficient through culture, process and technical means. We do have a lively discussion of technology, but it is from this perspective. If you are looking for answer from strictly technical point of view, I am sure there are plenty of technical working groups for Kubernetes that can give you an answer you look for.
Jiri Klouda
<docker><containers><orchestration><kubernetes><docker-swarm>
Combine Docker Swarm and Kubernetes
EvanM
# Combine Docker Swarm and Kubernetes

(Asked by: username_0 on 2017-04-11)

My company is trying to play a little catch-up in the DevOps space. I have been doing a lot of research on containerization of applications and the orchestration systems that go with it. I came across an article (one that I wish I had saved) where they were talking about combining Swarm with Kubernetes to get better functionality. In this article they did not define what they gained by doing that.

I wondered what benefits would this provide? Is adding the extra layer of complexity really going to give you much return?

**EDIT:** I am looking for technical pro's/con's. KISS is a good motto but doesn't hold up in a debate with your CEO or Board.

I am almost positive that we will be selecting Docker for our containers and Swarm for an orchestration. I, however, would like to see Kubernetes in our space so the proposition that you could merge the technologies together for a more robust solution intrigues me.Thanks for any insight.

**Tags:** docker, containers, orchestration, kubernetes, docker-swarm

> **Comments:**
> **username_1**: The operative words here are 'intrigues me'. You are part of a business. There should be a valid business reason for doing this. Not your interest, not technical wizardry, a solid business reason to combine those two. If there is no such business reason to start with, inventing it is simply unethical. What you are proposing is leading to wasting of the business resources for personal reasons and ethically it is akin to embezzlement.  
> **username_0**: I debated on whether to respond to this or not because frankly, I feel as though this conversation is a waste of time. Yes, I am part of business, yes it intrigues me, no I am not inventing anything and the attitude you have had from the get go is unwarranted. Intrigue is what drive technology forward, looking for reasons why/ why not is part of the job and simply asking questions of those who have gone before you is a best practice. This question was meant to get feedback from people who have actually done work on these platforms and have valid opinions on the subject.  
> **username_0**: Iam not looking fora philosophic debateon buzz words or cute acronyms Iam looking for technical benefits or short comings and where gaps can be filled if necessary. Everything postedhas been an opinion with no factual arguments. I would appreciate it if you could explain which technology you use to solve containerization and orchestration and the short comings you have found with it. At that point itis for me and my business to decidewhat is the best road for us to take. Research is not embezzlement or stealing, it is called duediligence and it is how goodtechnology turns into great solutions.  
> **username_1**: You might be asking in a wrong forum then. DevOps is a discipline about how to make business more efficient through culture, process and technical means. We do have a lively discussion of technology, but it is from this perspective. If you are looking for answer from strictly technical point of view, I am sure there are plenty of technical working groups for Kubernetes that can give you an answer you look for.  

---

## 2 answers

### Answer by username_1 on 2017-04-12. Score: 11

**Update:** Docker just released [support for Kubernetes](https://www.docker.com/kubernetes) as scheduler, which changes the situation and makes Kubernetes just an alternative scheduler to Docker Swarm.

**TL;DR: DON'T DO IT.** Engineers [always try](https://github.com/docker/swarm-frontends) to create these dog-pigs. Every unnecessary technology you bring will bring another whole set of faults. If you can pick one, then pick one and be happy you don't have to do both. If you like to play with Kubernetes, just get a private account on Google Cloud and play with it as much as you like. But don't make everyone at your company suffer through unnecessary complications.

Those are two [parallel](https://technologyconversations.com/2015/11/04/docker-clustering-tools-compared-kubernetes-vs-docker-swarm/) and mostly equivalent [technologies](https://insights.hpe.com/articles/the-basics-explaining-kubernetes-mesosphere-and-docker-swarm-1702.html). If your business had legitimate business reason to [deploy](https://www.containership.io) in [multiple Cloud](https://thenewstack.io/containers-microservices-and-the-multi-cloud/) providers [for reliability](http://www.stratoscale.com/blog/cloud/running-containers-multi-cloud-environment/) for example and wanted to deploy into both AWS [ECS](https://aws.amazon.com/ecs/) (Elastic Container Service - based on Docker) and Google [GKE](https://cloud.google.com/container-engine/) (Container Engine - based on Kubernetes) and you were asking how do you build a pipeline, which would build your software and package in containers for [deployment in both](https://leanpub.com/the-devops-2-toolkit), that would be something else, but doing it just because you want to play with a new technology is very irresponsible.

> **Comments:**
> **username_0**: I wouldn't say I want to 'play' with Kubernetes. There are business reasons why I prefer it over Swarm. One being the community and your assumption that I just want to do something is wrong. I don't disagree with your dog-pig comment, coming from a systems engineer position I have seen/prevented these many times, or at least tried. You haven't provided any indication that you have worked with either with lessons learned, nor any technical details as to why; I don't feel this addresses my question.  
> **username_1**: I use 'play with' instead of 'work with' sometimes  partly in the sense of work os fun and partly based on my mother's favorite: "You just play with computers all day and never do any real work." :)  
> **username_0**: Gotcha, I do the same. Just wanted to make it clear that this wasn't some half hazard attempt to force Kubernetes down the throats of my company. Hence the question. Gut feeling is that there is no 'good' reason but I couldn't simply ignore that article either.  
> **username_1**: Look, we have all been there. The business plans to go with one technology, when you think the other is better and you want to somehow still work with the other or at least both and show them down the line how your choice was so much better. It is a classic. No matter what you think, don't combine the two for the sake of doing it or to prove you are right. Even if you could justify it, your job is to design the solution to avoid doing so. KISS. Make it work with Swarm, convince everyone to use Kubernetes or quit and work in place where they will use Kubernetes.  

---

### Answer by username_2 on 2018-03-26. Score: 0

One reason to with Kubernetes as a scheduler if you use or would consider Azure as a cloud provider is their relatively new AKS service (managed kubernetes). In this case you would not combine kubernetes with docker swarm though.

This to me is clear indication as to where the community is going. I would not want to learn something that I would later need to throw in the trash can.


---

