Because in reality, with large teams, communication is expensive.

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.

You can think of docker files and other manifests as a highly structured and more direct-to-machine form of communication. Instead of a developer informing other developers to ensure that the dev machines and servers are upgraded to the right version of the JVM via a confluence page or slack message, that developer has left machine-readable instructions in a consistent format in a readily accessible place.

This is a good way to fix those problems with communication/practices/documentation and processes.

>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.

Yes. However, with more and more teams, and more and more languages, this communication, and especially planning and executing these upgrades and changes while providing rollbacks for all languages becomes harder and harder. It's very possible to do this, but it takes a lot of effort.

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.

Well yes you are absolutely right, the first comment who sees the down and upsides clearly.

> why don't the dev's test the application on the dev/test-environment?

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).

>They did, it failed, then the JVM was upgraded for dev/test

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.