The biggest benefit for edX, which is where I started using Docker and gained the most experience, was being able to get developers up and running with our key

The biggest benefit for edX, which is where I started using Docker and gained the most experience, was being able to get developers up and running with our key services in a couple hours as opposed to days. Everything is scripted, and ephemeral. Broke something? Refresh the environment. Want to try a new configuration? Build a new image. This was not as easy in our previous Vagrant devstack. > Don’t you still inevitably end up having to manage assumptions about the differences between these environments in order to make this work in practice...? Yes, and I would do that regardless of my deploy target. If you follow the Twelve-Factor App methodology [1], your settings are always in a config file or passed in as environment variables. If you're using external services (e.g. Stripe) while developing set the appropriate variables to your test credentials. > Do you actually get any good abstractions out of the container which empower better solutions to deployment challenges? “I don’t have to think about which hosts the (random) http client used in my application is configured to talk to because I can just magically retarget it at the container level by manipulating networking configuration” The solution to this problem is the same regardless of whether you use Docker or a cloud provider. Use a load balancer to direct traffic to a group of hosts responding to a specific port. > And what about the impact to developer ergonomics? Admittedly, debugging is not perfect (at least not with my Docker Compose setup in PyCharm). That said, there are debuggers that attach to Docker containers. [1] https://12factor.net/ https://12factor.net/