Why would I consider Compose over a tool like Minikube for local development?

[adam-beck]

Hello Bret!

I've been working through several of your Udemy courses. You go into great detail about how to use Docker Compose for local development. You even mention how compose file version "2" can offer more features for developing over "3" (which I assume that guidance may change with the new Compose). One thing I either missed or you didn't touch on was why pick Compose over a tool like Minikube.

I'm a developer -- meaning I have no real sway in DevOps decisions -- but I do know that we deploy our apps to a Kubernetes cluster. However, we use Compose for local development and, to me, it would just make more sense to switch to something that more closely matches production.

So my question: why would you consider Compose, over a tool like Minkube, for local development when your production app is deployed to a K8s cluster?

[BretFisher]

Thanks for the question. Some random thoughts in no specific order:

• Compose is a tool designed around the developer workflow, and there are lots of Compose commands to make it easier while developing locally (run, ps, restart, top, images, pause up/down, etc.). Kubernetes is a ops tool for managing clusters. To do those same, commands with kubectl you'll usually need additional tools (like stern for easier log viewing, kubens for switching namespaces, etc.) and a LOT more complex commands that a pure-dev wouldn't know unless they were a K8s admin. Many of the Compose commands don't even have a k8s equivalent (like docker compose images).
• The compose file is usually a 4th of the size of K8s manifests (helm is larger than pure manifests, making them even worse for dev setups).
• Running the docker engine locally is much more efficient than running Kubernetes. You'll see a laptop battery drain much quicker when K8s is running, for example. K8s is hard on CPU's even with no apps running and needs a dozen or so binaries active just to be "on" vs. dockerd.
• I know there are many ideas on solutions for dev's to "dev in k8s" but I've not seen them stick across teams in a way that makes them anything I'd recommend by default. You'll see those tools often trying to use remote infrastructure to save dev's from having to maintain local complex k8s setups. In the end, it's not making the dev workflow easier or better than Compose, so I'm not sure why they would be used as a team standard.
• Because of different storage, networking, ingress, and remote services/api's, it's very rare that a teams prod k8s setup would look anything like a local setup. You'll likely need a lot of templating to turn off all the "prod parts" and have the app work in a simple local setup. For example, I don't think the Load Balancer service type works in minikube (but it does in Docker Desktop K8s).
• Most dev's will need to understand docker at a basic level, and compose uses that knowledge and makes the commands even easier. It builds on what they know. K8s is such a different thing, that it's a lot more effort to learn it, even for just a simple local setup.
• Most local dev setups run things quite differently... images with dev tools in them, different startup processes that watch for file changes, added scripts in containers for workflow optimization, and local db's/queue's/api emulators for cloud services.
• Nearly every team I've helped has decided to stick with Compose for local and K8s for prod for all these reasons and more.

Note: most teams who use Compose locally and K8s on servers, will have some sort of manifest or Helm repo that can work in most local K8s setups (Docker Desktop, minikube, microk8s), but only for testing a "production-ish setup", and not for development.

BTW, yes unless you're using Swarm, drop the versions: key/value from your compose files and the work great in docker-compose and the new docker compose and combine v2, v3, and new features. No more versions!

[plashenkov]

That's so great answer, thank you!

[robodude666]

BTW, yes unless you're using Swarm, drop the versions: key/value from your compose files and the work great in docker-compose and the new docker compose and combine v2, v3, and new features. No more versions!

Interesting! I didn't know this. Leaving a few links in case they'll be helpful for anyone else:
https://docs.docker.com/compose/compose-file/
https://github.com/compose-spec/compose-spec/blob/master/spec.md

TL;DR as of Docker Engine 19.03 and Docker Compose 1.27.0 the compose file uses a new Compose Specification.

[Rvanmech]

@adam-beck Thanks for asking this question, I discovered it today. Based on the answer, for our development workflows I think it makes sense to keep using docker-compose (especially since that is already enough of a learning curve for developers). However, I do see a use-case for some developers to use Kubernetes locally to help create Helm charts and help bridge the dev team -> DevOps gap and their capacity (if it is limited).