patterndockerModerate
Combine Docker Swarm and Kubernetes
Viewed 0 times
swarmcombinedockerkubernetesand
Problem
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.
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.
Solution
Update: Docker just released support for 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 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 and mostly equivalent technologies. If your business had legitimate business reason to deploy in multiple Cloud providers for reliability for example and wanted to deploy into both AWS ECS (Elastic Container Service - based on Docker) and Google GKE (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, that would be something else, but doing it just because you want to play with a new technology is very irresponsible.
TL;DR: DON'T DO IT. Engineers always try 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 and mostly equivalent technologies. If your business had legitimate business reason to deploy in multiple Cloud providers for reliability for example and wanted to deploy into both AWS ECS (Elastic Container Service - based on Docker) and Google GKE (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, that would be something else, but doing it just because you want to play with a new technology is very irresponsible.
Context
StackExchange DevOps Q#845, answer score: 11
Revisions (0)
No revisions yet.