Docker attempts to do all of these things. It may not do them well but it provides a framework/opinion on how this should all be managed: 1. binary + configs (

Docker attempts to do all of these things. It may not do them well but it provides a framework/opinion on how this should all be managed: 1. binary + configs (PWD, files, ENV): baked into the image's Dockerfile 2. Secrets: passed in via env vars at runtime 3. Service discovery: docker-compose exposes container name as a hostname and provides a DNS record for this available in all netns that are connected to the same network. 4. data storage folders: Volumes https://docs.docker.com/storage/volumes/#share-data-among-machines https://docs.docker.com/storage/volumes/#share-data-among-ma... 5. Health checking: https://docs.docker.com/engine/reference/builder/#healthcheck https://docs.docker.com/engine/reference/builder/#healthchec... 6. binary placement: https://www.docker.com/blog/multi-arch-build-and-images-the-simple-way/ https://www.docker.com/blog/multi-arch-build-and-images-the-... 7. networking configs: https://docs.docker.com/network/ https://docs.docker.com/network/ 8. log management: to file or to syslog over TCP (super easy to ship to ELK) https://docs.docker.com/config/containers/logging/configure/ https://docs.docker.com/config/containers/logging/configure/ 9. fault-tolerant rollbacks: if you tag images correctly and you are upgrading from v1 -> v2 you can just replace the tag with :v1 to rollback to the correct version which will also be cached on the machine. If your registry is down you can still rollback. 10. Process isolation: this is exactly what docker is. Process isolation implemented in the kernel (sometimes).