''Docker Swarm or Kubernetes?'': Is It the Right Question to Ask?

DZone 's Guide to

''Docker Swarm or Kubernetes?'': Is It the Right Question to Ask?

If you're spending time arguing which of these is better, you might be missing the larger questions.

· Cloud Zone ·
Free Resource

Image title

First, let’s go to Google trends and see the trend for both the terms "Kubernetes" and "Docker Swarm." What do we see? Clearly, we could see that Kubernetes is beating Docker Swarm. But, is that a valid proof to say Kuberneytes is winning? No way.

Of course, the search volume and trend for "Kubernetes" might be higher, but still, this alone doesn’t prove that Docker Swarm is dead.

Docker adoption is still growing exponentially and more companies have started using it in production. It is important to use an orchestration platform to scale and manage your containers. Imagine a situation where you have been using Docker for a little while, and have deployed on a few different servers. Your application starts getting massive traffic, and you need to scale up fast; how will you go from three servers to the forty servers that you may require? And how will you decide which container should go where? How would you monitor all these containers and make sure they are restarted if they exit?

This is where Kubernetes comes in.

You might just think that you can just as easily achieve the same result with Docker Swarm, with far less complexity, too. Read on.

It’s Not that Easy to Compare Kubernetes and Docker Swarm. Why?

Docker Swarm is preferred in environments where simplicity and fast development is preferred, whereas Kubernetes is fit for the environments where medium to large clusters are running complex applications.

Unquestionably, Kubernetes gets a lot of attention given that it has a huge community out there (the Kubernetes project on GitHub has over 1,500 contributors and they actively release tons of tooling, extensions, etc.) and it easily rationalizes applications, particularly web-centric applications. But it may not always be the best choice for a given context. Therefore, Kubernetes or Swarm is not always the question to be asked; rather the kind of questions that need to be asked when considering container orchestration needs should center around the types of applications that need to run.

Along with all this, you also need to consider the facts and ease of

  • Installation and set-up
  • Logging and monitoring
  • Scalability
  • Availability
  • Networking

For example, when it comes to installation and setup, Kubernetes can be quite complex with steep learning curve whereas Docker Swarm is easy to install with a fast setup. Docker Swarm is excellent in its elegance, but Docker the company now officially backs both Swarm and Kubernetes. This has been widely interpreted as Kubernetes having “won.” In practical terms, we can expect Docker spends less energy on Swarm or promoting it as a preferred solution, and we would not be surprised to see it eventually disappear.

Let’s Talk About Some Stats

According to RightScale 2019 State of the Cloud Report, Docker and Kubernetes both are winning the game: Kubernetes usage rose from 27 percent to 48 percent.

A quarterly report on developer trends in the cloud by Digital Ocean shows this trend below when it comes to container orchestration platform usage. While Kubernetes was most popular overall, the smallest companies (1–5 employees) use Docker Swarm more often (41 percent use Swarm vs. 31 percent that use Kubernetes).

Is Docker Swarm Dead? It Is All About the Perspective

Docker again validates Swarm’s future at DockerCon 2018 EU and DockerCon 2019 with

1. New Swarm features

2. A vast majority of Docker’s 700+ customers use Swarm,

3. Swarm team is hiring, etc

4. Increasing usage of Swarm by startups

But, Seriously — Change Is the Only Constant in IT

If you don’t adapt and move fast, you will be moved out of the business fast.

But whatever the hype is, every tool gets replaced by another one with the time and technology advancement, so the focus should only be on what are we trying to achieve rather than what type of fancy tools are we using.

Take a look at the timeline and different tools below,

Every company is a software company today and every company will be a DevOps company by 2020.

I never thought the clothing company like Adidas can have so impressive cloud-native numbers. Such examples exist only to let us know that the whole world is moving rapidly towards a better digital transformational change.

We always tend to do fascinating things, and when it comes to engineering, the main idea is to become more agile, do experiments, fail fast, learn fast and release the software fast to the market compared to our competitors and once the culture is built, the tools enable us to do things in faster iteration.

Check out the example below.

Impressive CloudNative figures for a clothing company like Adidas.

At KubeCon 2019, Adidas presented these numbers. I am a bit amazed to see these numbers. Every company will be a DevOps company by 2020, where cloud-native technologies will drive the future of software development. 

Move fast and break things, so that you will always have an advantage over others who lag behind and still believe in their old, legacy, and traditional methodologies. You will have a first mover advantage in the market. With this approach, you will learn quickly and be able to foresee the future.

To conclude, we cannot really compare both Docker Swarm and Kubernetes because there will be many factors that affect this selection of technology. While the focus should not be on fancy and trending tools, the goal is to build something stable and required that customers love to use. No doubt, Kubernetes is winning the container orchestration game, but that doesn’t mean the Docker Swarm is useless. Every tool has its own advantages and disadvantages and we all know that no tool is forever.

comparison ,devops ,docker swarm ,kubernetes ,trends

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}