Web Apps and Microservices

With the container ‘revolution’ apps has grown much more than being just a database and a frontend. Applications are split into various microservices and they typically communicate with one another via a REST API (typically JSON formatted payloads over HTTP). Docker containers are ideal for this kind of architecture. You can package your frontend ‘microservice’ into a Docker container, the database goes into another, and so on and so forth. Each service talk to another over a predefined REST API instead of being a monolith written as a single piece of software.

If you need to implement a new functionality or a feature, e.g, an analytics engine, you can simply write a new microservice for that and it would consume data via the REST API exposed by the various microservices of your web app. And as your functionality grows over time, this list of microservices will grow along with it as well.

You don’t want to deploy each individual container, configure it and then configure everything else to talk to it as well. That will get tedious with even three containers. Docker-Compose lets you automate the deployment of multiple containers.

Docker-Compose is one of the simplest tools that helps you transform the abstract idea of microservices into a functional set of Docker container.

Distributed Systems

Now that we have split open the web app into multiple containers, it makes little sense to keep them all on a single server (worse still on a single virtual machine!) that’s where services like Docker Swarm and Kubernetes come into play.

Docker Swarm allows you to run multiple replicas of your application across multiple servers. If your microservice is written in a way that it can scale ‘horizontally’ then you can use Docker Swarm to deploy your web app across multiple data centers and multiple regions. This offers resilience against the failure of one or more data centers or network links. This is typically done using a subcommand in Docker, that is, Docker Stack.

The Docker Stack subcommand behaves a lot more like the Docker-Compose command and that can lead to misconceptions to someone using either of the technologies.

Source of Confusion

In terms of usage and workflow, both the technologies work very similar to one another, and this causes confusion. The way you deploy your app using either Docker Swarm or Docker-Compose is very similar. You define your application in a YAML file, this file will contain  the image name, the configuration for each image and also the scale (number of replicas) that each microservice will be required to meet in deployment.

The difference lies mostly in the backend, where docker-compose deploys container on a single Docker host, Docker Swarm deploys it across multiple nodes. Loosely speaking, it can still do most things that docker-compose can but it scales it across multiple Docker hosts.

Similarities

Both Docker Swarm and Docker-Compose have the following similarities:

1. They both take YAML formatted definitions of your application stack.
2. They are both meant to deal with multi-container applications (microservices)
3. They both have a scale parameter that allows you to run multiple containers of the same image allowing your microservice to scale horizontally.
4. They are both maintained by the same company, i.e, Docker, Inc.

Differences

The few differences between Docker Swarm and Docker-Compose:

1. Docker Swarm is used to scale your web app across one or more servers. Where as Docker-compose will simply run your web app on a single Docker host.
2. Scaling your web app Docker Swarm offers serious high availability and fault tolerance. Scaling your web app using Docker-Compose on a single host is useful only for testing and development.
3. Docker Swarm and related subcommands like Docker Swarm and Docker Stack are built into the Docker CLI itself. They are all part of the Docker binary that you call via your terminal. Docker-Compose is standalone binary in and of itself.

A Use Case for Docker-Compose

As described above, they are both completely different tools and each solves a completely different problem so it is not like one is an alternative for the other. However, to give new comers a sense of what I am talking about, here’s a use case for Docker Compose.

Suppose you want to self-host a WordPress Blog on a single server. Setting it up or maintaining it not something you want to do, manually, so what you would do instead is install Docker and Docker-compose on your VPS, create a simple YAML file defining all the various aspects of your WordPress stack, like below, :

Note: If you are using the below to deploy a WordPress site, please change all the passwords to something secure. Better yet, use Docker Secrets to store sensitive data like passwords, instead of having it in a plain text file.

Once the file is created and both Docker and Docker-compose are installed, all you have to do is run:

And your site will be up and running. If there’s an update, then run:

Then throw away the old Docker images and run the docker-compose up -d command and new images will automatically be pulled in. Since you have the persistent data stored in a Docker Volume, your website’s content won’t be lost.

When to use Docker Swarm

While Docker-compose is more of an automation tool, Docker Swarm is meant for more demanding applications. Web apps with hundreds or thousands of users or workload that needs to be scaled parallelly. Companies with large user base and stringent SLA requirements would want to use a distributed system like Docker Swarm. If your app is running across multiple servers and multiple data centers then chances of downtime due to an affected DC or network link gets significantly reduced.

That said, I hesitate to recommend Docker Swarm for production use cases because competing technologies like Kubernetes are arguably more fitting for this task. Kubernetes is supported natively across many cloud providers and it works quite well with Docker Containers so you don’t even have to rebuild your app to take advantage of Kubernetes.

Conclusion

I hope that this rambling on Docker and its satellite projects was informative and you are more prepared for the docker ecosystem.