I don't think I have much to agree with here. I do agree that one should be aware of the trade-offs of any given solution. And I agree that there is no such thi

I don't think I have much to agree with here. I do agree that one should be aware of the trade-offs of any given solution. And I agree that there is no such thing as a free lunch. I do disagree that "devops" is a job role and the sole responsibility of particular engineers on your team. So what does Docker bring to my team? Well it means repository maintainers have control over how their software is packaged and our deployment systems don't have to worry about configuration management on the host systems we deploy too. That saves our business time and money. It has instead allowed us to focus on high-level A/B canary deployments. Though Docker today is much better than Docker just a few years ago. I've used those third-generation configuration management systems to deploy services across hundreds of machines across two data centers. Usually without a hitch. It works great. But we were deploying a homogeneous suite of services that were all written in the same language ecosystem. Never had a problem. This is why I think it's important to think of devops as an approach to structuring teams. When the people who run and operate the software are on the same team as the people who write it then the trade offs that make sense become much clearer.