3 ms·

Also came here to ask this. Seems like something being simple and something being sort of done and not under active development are two sides of the same coin.

Also came here to ask this. Seems like something being simple and something being sort of done and not under active development are two sides of the same coin. A related question - the article mentions swarm here as the k8s equivalent, but can docker compose also fill this role in even simpler usecases, like just a handful of services in a typical 3 tier web stack? (especially on a team without k8s expertise that goes much beyond the functionality of docker compose) I get a general sense from reading various threads on this topic that using docker compose in prod isn't seen as a great idea, without ever having seen the why properly articulated.

fivea 5y ago
> Also came here to ask this. Seems like something being simple and something being sort of done and not under active development are two sides of the same coin. This. To me Docker's swarm mode is already feature-complete and solid. The only thing that I'm aware that needs some work is the notorious intra-node connection speed issue, but that's not a blocker in any way.
kubanczyk 5y ago
> the article mentions swarm here as the k8s equivalent, but can docker compose also fill this role Docker-compose is inherently limited to the single node (single daemon). No redundancy. The multinode version of docker-compose is docker swarm, in terms of the yaml file being mostly just ready for migration to swarm. > something being simple and something being sort of done and not under active development are two sides of the same coin If someone's resumé is basically "5 years experience with docker swarm" they have a harder time on the market than if they had these years with k8s.