Just stumbled across The sad state of sysadmin in the age of containers. It unforunately ends with "Before, admins would try hard to prevent security holes, now they call themselves "devops" and happily introduce them to the network themselves!". With that closing statement, which was an update to the original article, it reframes the context to read like devops sysadmins don't worry about security, only old-school sysadmins do. Disclaimer: I consider myself both. I started Systems Administration in the 90's, running slackware on both servers and my workstation for a medium sized business. Even gosh darn compiled my own kernel and taught myself C using the 'info c' command back when it was an amazing C tutorial. For devops: My current environment was (and still is) using chroot's for everything since long before docker was even an idea. I spend parts of many days writing chef recipes and custom nagios monitors. I even have crossed to the dark side and am writing powershell scripts to be processed by NCPA and using GPO to do all kinds of stuff on Windows. The author does make some really good points, especially about how nice it would be if people would start signing binaries they ship. This happens a lot in the Windows side of the shop where shipping binaries has long been how they've done it. Believe it or not, there are entire enterprise operating systems that ship without a compiler. There's also plenty of devops guys who pull binaries down and modify the distributed scripts to pull from a local repo. If I was deploying docker images I'd certainly pull them locally and deploy from the copy. That's how you do dev/stage/prod, right? You pull from the internet, deploy to dev then make sure you deploy the exact same thing to stage/prod from a local copy so you don't introduce any risk of changes happening to the gold copy. Plus, with the size of many of these things it's also faster to only pull it down once. It's the job of the software developer to figure out how to get it to you simply. It's up to the system administrator to figure out how to get it securely. Sometimes the software developer's simplifications make doing it securely difficult, that's life (or job security). Devops isn't a change from the old-school way of doing things. It should and I believe in most cases is a way to reinforce the correct way of doing things. The old-school sysadmin has a file tree full of documentation, maybe even a wiki. The devops sysadmin has gone through that documentation and figured out how to script a lot of it so repeatable processes are now repeatable without the risk of a typo. Containers, are a great security mechanism. They isolate your app to running in a tree that attackers will have a harder time breaking out of. They solve library dependency problems allowing us to run more things on our over powered hardware without having to go all the way in to deploying virtual machines. I think the original author gets it. But, over all the article to me read as a complaint about the tools and a knock on devops. The core problem is that in some cases it sounds like the tools are being used the wrong way. Don't complain about the sledgehammer, teach the new guy not to use it to drive a nail. Lastly, I guess I'm fortunate to not have to support hadoop yet. I get the same problems from other enterprise applications from vendors I won't name as I do value my job enough to not start a finger pointing game. I'm old-school enough to realize that at the end of the day it's my job to support my business and give them what they need to best get their work done. This means I don't waste time complaining about the old version of java or the other pieces of the stack that's shipped to me to deploy. It's pointless. I instead spend the time figuring out how to best isolate, firewall and otherwise protect the the application, the data and the network on which it resides. When you've been doing this long enough to consider yourself old-school then you should already know nothing is secure and it's all about minimizing risk to a level that's cost appropriate.Let’s Stop and Remember What Devops Is