New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Swarm vs. Kubernetes #6

Open
guy-matz-mfp opened this Issue Feb 1, 2018 · 7 comments

Comments

2 participants
@guy-matz-mfp
Copy link

guy-matz-mfp commented Feb 1, 2018

Brett,
You seem to prefer swarm. Why is that, and do you think it makes sense - career-wise - to learn swarm rather than kubernetes?

Thanks!
Guy

@BretFisher BretFisher changed the title Swarn vs. Kubernetes Swarm vs. Kubernetes Feb 1, 2018

@BretFisher

This comment has been minimized.

Copy link
Owner

BretFisher commented Feb 7, 2018

Good question Guy,

  • First, I don't fundamentally think one is universally better than the other for all people.
  • Just like all other IT tools and frameworks, as we see the market for that tool's problem space mature, we usually end up with a few solid solutions to the problem. An unhealthy space is when there's only one opinion of solving a problem. Swarm and K8s are two solid solutions in a healthy space.
  • There is a growing list of container orchestrators that are all doing 75%+ the same thing, but that focus on certain areas of the problem space or ecosystem.

I think Swarms advantage is in its simplicity. It's built from open source libraries just like K8s, but is delivered in a single binary that is "batteries included, but removable". It grows as you grow, and only takes a few commands to have a production-ready cluster. It's the free open source "core" that drives the cluster features of Docker Enterprise Edition, so it has great support from the Docker team and community in the SwarmKit repo, which is part of the Moby Project. I have consulting clients using it for real production work for well over a year. They can maintain it with a single person's part-time efforts for a dozen or more servers.

They both do 90% of the same stuff if you're going to build a cluster yourself. Because K8s has a larger community, dedicated conference, and is a media darling, it gets a higher percentage of chatter on the internet then what is representative than the actual number of people doing real work on clusters... and there are lots of people using Swarm, Mesos/DCOS, and Nomad to get work done too, but they don't get all the attention that K8s currently gets.

I'm a fan of tools that are easy to get started for new people and solve problems. Swarm does that very well.

For your "career" you should dabble in lots of tools and then dive deep on 1-2 in each problem space, IMO. If I had to pick two orchestrators to know, Kubernetes and Swarm would be it.

@BretFisher

This comment has been minimized.

Copy link
Owner

BretFisher commented May 22, 2018

For those that are reading the Fake News that Docker is replacing Swarm with Kubernetes, I wrote up an article detailing all the facts around Docker adopting a 2nd orchestrator in their Docker EE and docker CLI platforms. "Is Swarm Dead"

@BretFisher

This comment has been minimized.

Copy link
Owner

BretFisher commented May 22, 2018

I've been getting asked "Swarm vs. Kubernetes" questions since 2016, and my answer has stayed the same based on my "worldview" and typical client or student. Every opinion should have some context, so here's my worldview first:

  • I help teams who are new or young in container operations.
  • I teach students who are new or young in containers and never used an orchestrator.
  • My consulting clients build and manage their own software (PHP, Node.js, Java, .NET, etc.), in datacenters and the cloud, typically web apps and web services, and have teams up to 50 developers and DevOps staff. Usually the DevOps/Ops teams are under-staffed and lack the decades of ops expirence that the dev's have. Those ops people need tools that will free up their time, and replace existing tools. They can't afford to implement a new system that will add to their workload.
  • Their companies may be big or small, but the projects I help with are small enough to finish in under 6 months.
  • I do not typically consult for the largest 10% of teams and infrastructures. I don't help people grow from 1,000 to 10,000 node clusters. I help teams build and manage clusters of 10-100 in infrastructures of < 1,000 nodes. Teams that manage 1,000 servers and have run containers for years don't usually need me. Those people already know what they are doing in container ops and automation.
  • I am not a fan of overly-complex infrastructures. I'm also good at seeing how what you think is easy now, will become overly-complex in the future. These are "infrastructure smells", the ops version of "code smells" I will pick a simple-to-use and well-maintained tool first, even if it's not the most popular because I know that most teams are very limited on time to learn new things, and often we under-estimate how hard implementing a new technology abstraction (like a container orchestrator) is.
  • My goal is that the team is successful quickly, rather than worry about what they might need in 3-5 years (because those needs will change by then).

Now that you know that, here's my advice for you if you fit in my worldview:

  • Learn Swarm first. It is an extension of the Docker Engine, is easy to learn, and nearly all features can be understood in a full day class. Many of its concepts and management concerns will directly translate to the more-complex Kubernetes, if you ever need to go there.
  • Keep your infrastructure agile. Use only infrastructure-as-code, and expect/test nodes being replaced. This will help prevent your Swarm from becoming fragle.
  • Solve your app problems first and leave databases where they are. You often don't need to containerize your databases to start with, and you tend to get far less benifit of database containerization vs. doing something like database clusters to increase uptime, or just using cloud database SaaS.
  • See my Docker Production DockerCon Session. It's full of advice on simple cluster designs and dos-and-dont's on going production Docker.
  • If you ever find a problem that you just can't fix with Swarm, only then consider Kubernetes by learning it and setting up a duplicate environment to see if it's "better overall". Don't just assume "Swarm can't do this so we must go Kubernetes". This may end in tears with the assumption that "Kubernetes fixes all the imperfect things in Swarm". Sometimes problems are hard to fix, no matter the tool. One common problem I see with students is they jump on Kubernetes too early because they see some cool feature they think they need, but the cost of implementation/management of Kubernetes weighs against that preceived benefit they thought they would get. On further discussion with them, I often show that there's a non-obvious way to do it in Swarm, or just not do it as all (e.g. someone thinks they must provide volume replication between nodes, when usually they don't).
  • Go into your container production project knowing that this will be a huge learning curve for your team, and to plan for tools to be replaced in the coming years as the market changes and matures. This mindset, when communicated properly to your team and management, will help save you when you've learned a specific tool needs replaced in your org and people had the false expectation that you'd "get everything right the first time".
  • Finally, realize that all these "infrastructure abstractions" are very new, and will change greatly over the next 5 years. Assume everything is harder then you expect, and much harder then the internet tells you. We (the container community) tend to over-sell benifits and under-communicate the complexity of learning and mantaining these new types of systems.
  • As the next bullet states, if you have to go Kubernetes, don't deploy raw Kubernetes. Use a higher level deployment and management tool, unless you have a whole team of dedicated cluster admins. The tools listed below will save you lots of time, and also help prevent you from deploying a insecure or unreliable cluster.
  • Stay away from "Not Implemented Here Syndrome" which is the DevOps version of Not Invented Here. If you're short on time and need the safe-path to container orchestration, BUY SOMETHING. Pick a vendor and use them to offset the risk of doing it all yourself. Open source is awesome, but it doesn't mean you should use only open source to run a business. There are lots of tools to make parts of your infrasturcture easier that are worth the money. Many are listed in the CNCF landscape and the Awesome Docker list. Docker EE is a great tool to deploy and manage both Swarm and Kubernetes in a non-cloud-specific way, with a list of exclusive features that "just work" out of the box. However, if you are "all in" on a cloud vendor, you should use their container orchestration tools before building your own solution on their servers! There's also OpenShift and Rancher for managing Kubernetes. The point is that doing-it-yourself in small teams is often the wrong choice. Getting a small budget for a tool to save you time is often the best choice when you can't hire more staff or magically free up your own time.

Good Luck!

@BretFisher

This comment has been minimized.

Copy link
Owner

BretFisher commented Dec 14, 2018

I've written an updated article on the past, present, and future of Swarm. Lots of people are using it (they keep finding me at conferences to talk about it), and some have even deployed both Swarm and Kubernetes... Swarm by default, and then moving workloads to Kubernetes when required.

The Future of Docker Swarm

@BretFisher

This comment has been minimized.

Copy link
Owner

BretFisher commented Dec 14, 2018

My DockerCon 2017 talk helps you make Swarm infrastructure decisions for building out your clusters.

Taking Docker Swarm to Production: What You Need to Know and Decide

My DockerCon 2018 session builds on top of the 2017 one, and was about using Swarm to build up your production cluster, with all the tools and bells and whistles needed in smaller environments, and how to layer/change your approach as your infrastructure grows

Building Your Production Tech Stack for Docker Container Platform

@BretFisher

This comment has been minimized.

Copy link
Owner

BretFisher commented Dec 14, 2018

From DockerCon 2018 EU, Swarm’s future is solid:

  • PayPal and Visa ran their biggest two days of the year, Black Friday and cyber Monday, on Swarm
  • Vast majority of Docker’s Enterprise customers use Swarm, and optionally Kubernetes, when needed. Over time more people default in new deployments to Kubernetes.
  • Customers are choosing Docker Enterprise over other enterprise container platforms due to choice of orchestrator inside the system. DE is the only platform to currently offer orchestrator choice.
  • Customers are finding Swarm so easy to use, they default to it, and only use Kubernetes when the workload requires it.
  • Swarm secure out of box with no exposed endpoints unauthenicated or unencrypted, and that resonates well with security-focused teams.
@BretFisher

This comment has been minimized.

Copy link
Owner

BretFisher commented Dec 14, 2018

Swarm grows in usage in 2018, surpassing Mesos to be 2nd place in popularity with Sysdig usage report: https://sysdig.com/blog/2018-docker-usage-report/

Digital Ocean survey shows that smaller teams prefer Swarm https://www.digitalocean.com/currents/june-2018/

@BretFisher BretFisher pinned this issue Dec 14, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment