Consul vs Docker Swarm: What are the differences?
Developers describe Consul as "A tool for service discovery, monitoring and configuration". Consul is a tool for service discovery and configuration. Consul is distributed, highly available, and extremely scalable. On the other hand, Docker Swarm is detailed as "Native clustering for Docker. Turn a pool of Docker hosts into a single, virtual host". Swarm serves the standard Docker API, so any tool which already communicates with a Docker daemon can use Swarm to transparently scale to multiple hosts: Dokku, Compose, Krane, Deis, DockerUI, Shipyard, Drone, Jenkins... and, of course, the Docker client itself.
Consul can be classified as a tool in the "Open Source Service Discovery" category, while Docker Swarm is grouped under "Container Tools".
"Great service discovery infrastructure" is the primary reason why developers consider Consul over the competitors, whereas "Docker friendly" was stated as the key factor in picking Docker Swarm.
Consul and Docker Swarm are both open source tools. Consul with 16.2K GitHub stars and 2.82K forks on GitHub appears to be more popular than Docker Swarm with 5.61K GitHub stars and 1.11K GitHub forks.
Slack, SendGrid, and Oscar Health are some of the popular companies that use Consul, whereas Docker Swarm is used by Bugsnag, Docker, and Dial Once. Consul has a broader approval, being mentioned in 131 company stacks & 52 developers stacks; compared to Docker Swarm, which is listed in 80 company stacks and 38 developer stacks.
Breaking a monolith into microservices and handling the scaling and health of new services as they come only. This should ideally help to reduce the overhead needed to get a service online. We have all of this being handled by custom URLs and health checks being done at the expense of infrastructure setup time and maintenance (VM sprawl). Initially, I am looking at Consul for the TLS proxy and security options as well as the KV store which may prove useful in cross datacenter environments.
Our whole DevOps stack consists of the following tools:
- GitHub (incl. GitHub Pages/Markdown for Documentation, GettingStarted and HowTo's) for collaborative review and code management tool
- Respectively Git as revision control system
- SourceTree as Git GUI
- Visual Studio Code as IDE
- CircleCI for continuous integration (automatize development process)
- Prettier / TSLint / ESLint as code linter
- SonarQube as quality gate
- Docker as container management (incl. Docker Compose for multi-container application management)
- VirtualBox for operating system simulation tests
- Kubernetes as cluster management for docker containers
- Heroku for deploying in test environments
- nginx as web server (preferably used as facade server in production environment)
- SSLMate (using OpenSSL) for certificate management
- Amazon EC2 (incl. Amazon S3) for deploying in stage (production-like) and production environments
- PostgreSQL as preferred database system
- Redis as preferred in-memory database/store (great for caching)
The main reason we have chosen Kubernetes over Docker Swarm is related to the following artifacts:
- Key features: Easy and flexible installation, Clear dashboard, Great scaling operations, Monitoring is an integral part, Great load balancing concepts, Monitors the condition and ensures compensation in the event of failure.
- Applications: An application can be deployed using a combination of pods, deployments, and services (or micro-services).
- Functionality: Kubernetes as a complex installation and setup process, but it not as limited as Docker Swarm.
- Monitoring: It supports multiple versions of logging and monitoring when the services are deployed within the cluster (Elasticsearch/Kibana (ELK), Heapster/Grafana, Sysdig cloud integration).
- Scalability: All-in-one framework for distributed systems.
- Other Benefits: Kubernetes is backed by the Cloud Native Computing Foundation (CNCF), huge community among container orchestration tools, it is an open source and modular tool that works with any OS.