[verdverm]

Kubernetes is the standard now, why would I want to use something else?

I've not seen or used a docker-compose that was designed for production settings, it's primarily a dev time tool. Would we not have to maintain a second dc file with different settings?

[dschuessler]

For one, to use the same tool in local development and in production. For another, because docker-compose is simpler than Kubernetes.

[verdverm]

Production is more complicated than development. How would I express rolling updates or ingress with docker-compose?

Why not use Kubernetes for local dev (kind or minikube) instead of trying to make docker compose hacks for production? Docker Swarm is rarely seen, I suspect industry has already settled on k8s as the standard

[jsbroks]

Working at a large scale I agree that using something like this doesn't make sense. But for indie hackers, small startups, or people wanting to deploy foss, they dont need all the complexities you are talking about. They have a app they want to deploy and generally, as cheap as possible.

[JojoFatsani]

They should just use Heroku then

[JojoFatsani]

You can run your Kube stack locally.. look into kind, minikube etc.. just exclude your LB configs and stuff from your helm charts and dial down the resourcing