At vendor conferences, you're usually overwhelmed with talks, keynote sessions, workshops, and training. There's a large amount of new information, product announcements, technical deep-dives and customer stories from which to choose. I'm always interested in that last category, and I try to pick the most "technical" ones in that track. I like the stories, listen to technical people at a company explain why they opted for product A, method B, or tool C to solve a particular business problem they had.
So when I noticed the DockerCon San Francisco schedule listed a talk "From Swarm to Kubernetes … and back again", I highlighted that one immediately to see what we could learn from their journey and to see how we can use their knowledge when helping our Docker CE to EE enablement customers who are facing that same choice.
During the presentation, two of the DevOps Engineers at Citizens Bank told us about their journey to a containerized environment: from Docker Swarm to Kubernetes and back again. They started by explaining the four pillars they identified in 2016 to be the core values of their DevOps culture: Visibility, Experiment, Standardize, and Simplify.
These four foundations helped serve as guidelines to every decision and allowed them to move from relying 100% on legacy applications in 2016, to where they are today, mid-2019, where every new application runs in production in a containerized environment. They worked with a team of legacy application builders to build an entire application from brainstorm to production in only six weeks, including integration with a 3rd party vendor.
FROM SWARM
When Citizens Bank started out experimenting with containers and designing their new architecture, they picked Docker Swarm because it ticked all the boxes for them.
First of all, it's simple, incredibly simple! It allowed them to use the same single file to spin up the application in production, as the developer used to spin up the early versions of the app on her workstation.
As a financial institution, Citizens Bank is working in a highly regulated environment, but using Swarm as an orchestrator made it very easy to segregate environments and define comprehensive network- and host-isolation where needed.
They loved Swarm, the developers loved Swarm, and even the security team was convinced that all the compliance requirements could be met easily.
TO KUBERNETES
Towards the end of 2017 and the good part of 2018, Kubernetes gained a lot of traction. It seemed like everyone was doing Kubernetes in production, without any issues at all. While this is certainly not the case, Kubernetes comes with a few great functions that didn't exist in Swarm.
The main thing the customer was missing in their Swarm setup was the ability to package and deploy applications easily. Yes, you can re-use Docker Compose files, but a Kubernetes Helm chart is much more powerful. Kubernetes also introduced Operator Patterns, which allow you to manage startup, service discovery, scaling, and basic maintenance tasks in an automated fashion.
As everybody and their cat seemed to be using Kubernetes, there is a lot of community involvement and vendor support for it.
The company was using Docker Enterprise, which allowed them to "turn on" Kubernetes on their existing infrastructure without having to spin up new clusters and reconfigure everything again.
So by 2018, they shifted from Swarm to Kubernetes as their preferred orchestrator.
KUBERNETES EXPERIENCES
Quickly the company learned that Kubernetes could be hard. Even though Citizens Bank isn't a small organization with 1200 branches across the states and about 18000 employees, the team that manages the Docker Enterprise install is just four people. As Kubernetes has a different security approach, certain things that are easy in Swarm, are hard in Kubernetes.
For instance, when you want to grant users access to only a subset of worker nodes, when you want to be sure the network segregation and isolation is guaranteed, more or less the only solution you have, is to run multiple clusters. This adds a lot of complexity to the setup and increases the cost. More clusters mean more of everything (user databases, storage, networking, …)
While the Swarm workflow resembles the developer's Docker install on her/his laptop, a Kubernetes cluster is a different beast. This required additional training and resources, both for the devs and the operational support team.
Kubernetes has more moving parts, so it is a lot more complex to configure. For an example of the complexity, compare the YAML file needed to configure the Instana monitoring agent on a Kubernetes cluster (https://docs.instana.io/quick_start/agent_setup/container/kubernetes/#example-yaml-file) with the instructions for Swarm, which are a lot easier (https://docs.instana.io/quick_start/agent_setup/container/docker/).
As explained in "The Phoenix Project" (the DevOps Bible) which is based on Ely Goldratt's "The Goal," we should aim to maximize the performance of the entire system ("The First Way"). Are we doing that by spending a lot of time configuring and tweaking Kubernetes? Isn't Swarm's simplicity more in line with this principle?
BACK TO SWARM?
When Docker announced the Docker App packaging tool, based on the open CNAB format in December 2018 (https://blog.docker.com/2018/12/docker-app-and-cnab/), they went back to the drawing board. This solved their most significant issue with Swarm.
Returning to Swarm allowed them to get back to a simple, stable, and proven solution. They realized the lack of a comprehensive packaging tool was what kept them from using Swarm. They found a suitable replacement for Kubernetes Operators in the Autopilot Pattern described by http://AutopilotPattern.io.
Quickly they regained the simplicity and ease of mind that made companies choose Swarm in the first place.
WHAT CAN WE LEARN FROM THEIR JOURNEY?
Swarm and Kubernetes are both great orchestrators, and both have a bright future ahead of them. They aim to solve the same problem but with entirely different philosophies.
Swarm aims to offer high-impact solutions while prioritizing simplicity and security.
Kubernetes aims to offer a solution for every conceivable problem.
Both are great solutions and orchestrators but solve similar problems. It's essential to choose the one that matches your philosophy, culture, and environment. In this case, Citizens Bank went back to Swarm because they loved the simplicity, ease of management, built-in security features it offers, and it allows them to manage everything with a small team.
When our clients ask me when they should pick one or the other, I give them the same advice: look at what you need. Are you trying to solve a problem that Kubernetes is great at? Then choose Kubernetes, by all means. However, if you have a smaller team and like single, secure, and stable solutions, then Swarm is a great orchestrator.
One of the great things about Docker Enterprise Edition is that it gives you the option to run both Swarm and Kubernetes workloads on the same cluster, manage it from the same UCP control plane, and threat both as first class citizens.
The most crucial factor that determines the success or failure of any IT project is the human factor. The smile you'll get from a project manager when you can show them they can deploy an app to production with the push of a button, will make her an important advocate. That's why it's essential to look at your company culture when selecting your orchestrator.
ABOUT THE AUTHOR
Ken Archer is a Docker Certified Associate and Accredited Instructor for Stone Door Group, a DevOps and Cloud consulting company. If you are looking for DevOps consulting for your next project, take a look at our CI/CD Accelerator Solutions or drop us a line at letsdothis@stonedoorgroup.com.