The downside is: you are also, at the same time, excluding yourself from standard patch management. Whereas in ye olde times for a situation like Heartbleed or log4shell the 24/7 on-call sysop team would run a simple "apt-get upgrade openssl" and restart all affected daemons, under modern "devops"/docker-centric models you need to wait for the developers or, worse, the container image vendor to deliver updated versions.
It also really makes a difference if you are combining some tasks and ownership in a DevOps concept where it's not just developers handing off some binary and telling the operations team "good luck eh". That classic setup mostly brings finger-pointing problems and not really much of a solution.
What a patch management concept would look like is much a more modern version of the server thing: you have some system that allows you to query all the servers "what is your current version of thing X" and if you then want to change that you build an updated machine image and deploy that to all those servers. Cattle, not pets.
DevOps has always been more about companies attempting to "save" money by shoe-horning together roles that require completely different skill sets.
I have to vehemently disagree with this statement. I had 10 years in IT before I did my bootcamp and quickly found myself in deployment engineer roles by accident. Most of my bootcamp cohort ended up at smaller companies wearing many hats and learning quickly where a good half of them are in deployment type roles by necessity.
After an additional 10 years in this industry, I'm finding invariably that it's the FAANGs and companies hiring fresh grads out of the best schools where engineers aren't learning anything about the underlying systems. It's the feature factories where people put their headphones on, the heads down and code like their life depends on it.
They do things like write microservices that implement basic functionality of opensource loadbalancers, because they've never heard of nginx or haproxy before, don't know how it solves their specific problem and wouldn't know how to configure it. When all you do is write code, every problem looks like it should be solved by writing code.
Before the overlap between development and operations there were multiple teams involved in every step, everything was slow and expensive and you'd be lucky to deploy once a week. After making sure that where overlap exists the people that have the skills to work in that area can do what they need to do (i.e. build, verify, release and instrument the systems they are responsible for) we get every team releasing every system multiple times per day in small increments. This is both faster, easier for everyone, and worth the ROI on people and tech far more than trying to invent borders and fiefdoms between hyper-specialised teams.
That's just a sing for bad communication/practices/documentation and processes, and why don't the dev's test the application on the dev/test-environment?
BTW: Why can the JAVA-team even install something on the dev/test/prod-env? That's completely against the rules.
Containerisation allows reproducibility, in a self-documenting manner. Delivery can be automated, depended upon to run, in a totally system configuration agnostic manner. It allows projects to deliver their software in a way that it can be ran, instantly, with a single command (image download not withstanding).
I've worked heavily in service software engineering for over a decade now, and with docker since 2013, and it has changed everything. There will be some people who don't fully understand it, but perhaps they don't have the problems that it solves and thus don't need it.
Alternatively, they /could/ just be suffering without realising there is a solution.
This is a good way to fix those problems with communication/practices/documentation and processes.
No it's not because the dev who made the database-container forgot to inform you that you need the new jdbc.jar etc...it's the same just with one more layer.
Containerization largely eliminates this need for communication. There are new problems - security of running containers, image sizes, building images safely and so on, but this problem disappears.
They did, it failed, then the JVM was upgraded for dev/test (but not yet for prod as that was still running the prev-JVM version of the code).
See first error, dev/test has to be a exact mirror of production, otherwise it makes no sense. And if not even the admins from dev/test/production can communicate with each other...you really have deep rooted problem.
Then you have lads who use python who can use virtualenv, and then the ruby ones who use rbenv and then you have the CPP developers which are usually fine but on Tuesday Joe messed up the linker settings and all of a sudden we're not statically linked, thanks Joe.
And then our Java team forgot to tell the sysadmins that they upgraded the JVM version.
The thing with docker is that you just get a complete package with everything delivered directly by the developer and it's very hard to mess up.
Also docker can run applications that aren't shipped by people in your company and also does more stuff (like more sandoboxing and it also helps you with the resource management).