[atemerev]

Docker way is structuring your apps in "one service per container" — Docker is designed around this. Even the simplest applications require multiple containers (one for front-end, one for back-end, one for the database etc) — even without clustering or high-availability, which complicate things even more.

When you have multiple containers, it is imperative that they are managed as a group, with clearly defined dependencies. This is why Docker requires an orchestration tool. And when the number of your production nodes is greater than one, Docker on its own becomes inadequate for that.

[ohstopitu]

Ignoring availability & mirroring (and all other cloud enabled features) for conversation's sake:

Can't the above be orchestrated via docker-compose?

(I've been using docker with docker-compose for my side projects but not been using it excessively in customer facing production)

[atemerev]

It can, if you have a single production host and only one development machine, i.e. if you are a solo developer.

For anything more than that, native Docker tooling is inadequate.

[ohstopitu]

I can understand the use of Kubernetes to spread over multiple hosts (but that's generally for scaling & availability).

If you have multiple devs...how does docker-compose fall short? (I'm asking because I wanted to suggest using docker for my team and wanted to know it's short comings before I suggested it).

From my understanding: you can use compose to orchestrate databases, cache, app all on one machine quite easily (and pass environment variables, get them linked etc.)

[wstrange]

In addition to multi-node distribution, there are a bunch of things Kubernetes gives you. Things that you may think you don't need, but you probably will if you ever intend to put something into production. To name just a few:

- Secret distribution

- Managing persistent volumes

- Monitoring containers for failure, restarting according to policy

- Service discovery and DNS integration

- Integration with load balancers, setting up routes, etc.

- Managing affinity / non-affinity for containers

- Sharing resources on a cluster via namespaces

[kossae]

- Monitoring containers for failure, restarting according to policy

This alone warrants an orchestration solution, even on a single machine.