Just replying to your comment, not trying to start an argument but just throwing out some thoughts. Please let me know if I'm off track in my response. What b

Just replying to your comment, not trying to start an argument but just throwing out some thoughts. Please let me know if I'm off track in my response. What baseimage should you use? - You can always create your own docker base images. I do agree that it gets confusing when you pull a docker image and it's not using the linux flavor that you were expecting. Building a docker image is quite simple though. How about logging? - If using Kubernetes, you can use a 'side car' pattern with a log exporter. How about PID 1 problem? - I'm a little confused what you mean, but I think you are referring to killing PID 1, which would kill the docker container. If you're using Kubernetes in production, then Kubernetes would solve the problem of routing to docker containers that are up or down. How about SSH? - You would have to SSH into the host with the docker container present, and drop into the docker container thereafter. Remote Docker containers cannot be accessed remotely for ex AWS Fargate. - I haven't used AWS Fargate before, no comment. How about restarting servers? - Handled by Kubernetes, totally ok to restart the servers and requests won't be routed to dead (5xx) containers. How about migrations? - Deployments are simple using Kubernetes (built in rolling deployment, but also easy to do blue/green deployments). If you want to migrate a database, then it'd be the same process as non-container deployments.