[awalGarg]

Begging for an example ;)

I do understand this. And I do agree. But the more I think about it, the more I find that those arguments don't matter in real life. Code written in high level languages/platforms like node/ruby/python/etc. is meant to be platform independent since the underlying VM abstracts the low-level details. Can you give me an example of the "configuration" differences that you (can?) encounter on different systems while developing on such platforms? (Except for the obvious and documented ones which containers can't solve either).

[drumdance]

Here's an example:

A few weeks ago we had an issue where a db migration would not work on some of our developer machines (it worked fine on mine and in staging and in production). After a lot of sleuthing, we found that it was because their version of the database was slightly different because they had installed it months after I did. Furthermore, it was a real pain to roll back to the appropriate version.

A container that locked down the db version would have avoided all that.

[maccard]

We just have the particular versions of tools we rely on checked into perforce, and when there's an upgrade, you don't have to do anything different and everyone gets the upgrade.

[IanCal]

I have several projects that use different versions of elasticsearch and different versions of postgres.

Elasicsearch has differences through versions which make some of the code incompatible (I recall changes with security around custom scoring functions). Some projects depended on an older version which allowed this code, other projects depended on newer features. Being able to have a different configuration per project can make things much simpler.

Even with the same versions, I'd like my ES process to be used by only one project, otherwise there's a risk of them stamping over each other causing issues which wouldn't be seen in production.