I can explain why Docker is an attractive solution for us. It may not be the same for others.

We create app specific images (web applications) and store these on a registry. I am currently using Swarm so it operates in a cluster that scale up and down as needed. I've got a load balancer that discovers the services automatically with routing rules defined in each service.

This means I can scale up an app in 10 seconds without making any changes other than the scale command. This same ability lets me do app updates without downtime. As long as an app is scaled to at least 2, I can have it update the image by migrating connections away from one, replacing it, and then doing the same to the other.

For DR, I can duplicate our registry to a cloud service and run the stack in almost any cloud service because they all offer some type of container service.

Now this really only works well for our application layer. The data is all stored in databases that use dataguard or other methods of replication for dr/backup/etc.

Thanks. I must not have been paying close enough attention since I just now learned where everybody went.

@momurda I used this documentation from Docker: https://docs.docker.com/engine/swarm/swarm-tutorial/

I also used this documentation from Traefik which is the load balancer I used in my setup:
https://docs.traefik.io/user-guide/swarm-mode/

I ended up making a build machine that the team can share to create images. Harbor is the registry I ended up using to store the images.

I don't think any of the docker parts were too difficult. The harder part is getting the apps into functional images and even that is not too bad once you begin to understand how they work.

@momurda I used this documentation from Docker: https://docs.docker.com/engine/swarm/swarm-tutorial/

I also used this documentation from Traefik which is the load balancer I used in my setup:
https://docs.traefik.io/user-guide/swarm-mode/

I ended up making a build machine that the team can share to create images. Harbor is the registry I ended up using to store the images.

I don't think any of the docker parts were too difficult. The harder part is getting the apps into functional images and even that is not too bad once you begin to understand how they work.

I can explain why Docker is an attractive solution for us. It may not be the same for others.

We create app specific images (web applications) and store these on a registry. I am currently using Swarm so it operates in a cluster that scale up and down as needed. I've got a load balancer that discovers the services automatically with routing rules defined in each service.

This means I can scale up an app in 10 seconds without making any changes other than the scale command. This same ability lets me do app updates without downtime. As long as an app is scaled to at least 2, I can have it update the image by migrating connections away from one, replacing it, and then doing the same to the other.

For DR, I can duplicate our registry to a cloud service and run the stack in almost any cloud service because they all offer some type of container service.

Now this really only works well for our application layer. The data is all stored in databases that use dataguard or other methods of replication for dr/backup/etc.

Why not use it for production? I am investigating it for hosting many of our web apps. I've been looking at Docker Swarm, Kubernetes, and Rancher.

It lets me run the apps in a cluster, and I can scale them up and down easily, change versions without interruptions, etc.

Thanks. I must not have been paying close enough attention since I just now learned where everybody went.