Where may I need Docker Compose as Kubernetes won the container orchestration war?

Question

I found Docker Compose just release 1.28 on 2021-1-20 but as Kubernetes won the container orchestration war I am not sure where and why I may still need Docker Compose, under with case Docker Compose is a better option?

I have a web app that consists of a php docker, a nodejs docker, a nginx docker. We host it at aliyun cloud service. In 2018 aliyun used docker swarm so we used docker compose but in 2020 we had switched k8s so I was wondering if it is still worth to learn docker compose ?

--- update ----

I found these articles were helpful

1. Why do I need Compose if I already have Kubernetes? a docker blog published in 2018
2. Docker Swarm vs. Kubernetes for Single-Host Implementations
3. https://stackoverflow.com/questions/47536536/whats-the-difference-between-docker-compose-and-kubernetes an answer is what I do currently:

If you are networking containers within the same host go for docker compose.

If you are networking containers across multiple hosts go for kubernetes.

And that is what docker compose document said https://docs.docker.com/compose/#common-use-cases

Answer 1

Docker compose is still a comparatively easy and light-weight tool to run multiple docker containers with service discovery.

Kubernetes is a metaphorical elephant. Great if you need to smash Roman lines and win the battle, but overkill for a minor skirmish, and definitely more trouble than it's worth if you're trying to fight a small battle in the mountains.

If you have a fairly large app with multiple microservices, then Kubernetes is worth every penny.

But when you're trying to run just a couple of containers, especially if it's only on a single host (i.e. your frontend + backend and maybe a local instance of RabbitMQ), docker-compose is a much simpler/faster way to orchestrate it. Kubernetes is like using a cannon to kill a mosquito when a flyswatter will do.

Example use cases where docker-compose works just fine:

• Local development environments running on your machine. Even if you run Kubernetes in production, there's likely a lot of orchestration around getting it to work which would make it too complex for a single machine.
• Simple apps without a lot of components
• Single tenant apps which run on a single host
• Deploying docker-based apps on bare VMs or physical hosts

Answer 2

why I may still need Docker Compose, under with case Docker Compose is a better option?

Need it for what? Better for what? Docker Compose is mostly a different way to link multiple container-apps compared to Kubernetes and probably slightly more lightweight on a Desktop.

But if you run your apps in Kubernetes in production, you probably want to use as similar as possible solution on Desktop as well or none. In this case Kind or Minikube is popular alternatives for Desktop - but usually you want to only run the app directly from the IDE when developing and only in some cases test it in a Kubernetes networked environment.

I was wondering if it is still worth to learn docker compose ?

Knowledge is good. At least you would learn when to use Docker Compose and when to use Kubernetes with knowledge about both. But if you are using Kubernetes at work and in production it is probably better use of your time to improve your Kubernetes skills and knowledge.

Answer 3

TL;DR - you'll use compose locally or for single machine deployments... Yes its worth learning, probably now more than ever as Docker is dominating local development tooling.

--

RE: Now that k8s won the orchestration war.............

The idea that K8s "won the orchestration war" is something that makes me cringe when I hear other people saying it. It's propaganda that was percolated through the ranks by the CNCF marketing team so that people would just stop asking "what if we do it this way" and start adopting kubernetes.

The problem is, that even years after this came out, (it started circulating in probably 2018ish - I heard it at kubecon that year) its still absolutely untrue. In fact, I'd say that k8s has hit peak hype and its likely to see a bit of a decline in the coming years...

Why you might ask?? How could the "war winner" be taken from its throne? It's pretty simple really, most organization don't need 99% of what k8s offers and on top of that they simply cannot afford the massive cost of managing a k8s deployment (its a LOT).

Now I'm a bit partial, as I work for Cycle.io - a LowOps PaaS thats a direct k8s competitor, but I'm also on the front lines of hearing the horror stories from company after company as they look to migrate away from k8s and get back to productive. I don't expect you to take my word for it, but the growing masses are looking for k8s alternatives and you can find info on it all over the web.

I'd point you to this DZone article for example.