[curt15]

Containers took off because it was the easiest way for developers targeting Linux to get a predictable runtime environment. It freed them having to worry about the differences between Debian's OpenSSL or Red Hat's OpenSSL libraries or even the differences between different versions of a distribution. You don't see nearly the same level of uptake among Windows developers because not only is there only one Windows API for everyone to target but also Microsoft is willing to bend over backwards to preserve backward compatibility.

Containers also predated "modern sysadmins"; prior to docker, Google ran its prod software in chroots for the same reasons as above:

>The software run by the server is typically run in a chroot with a limited view of the root partition, allowing the application to be hermetic and protected from root filesystem changes. We also have support for multiple libcs and use static linking for most library uses. This combination makes it easy to have hundreds of different apps with their own dependencies that change at their own pace without breaking if the OS that boots the machine changes.

https://www.usenix.org/system/files/conference/lisa13/lisa13...

[mikepurvis]

Some have argued that the rise of containers correlates with the rise of Python, explaining that containers are particularly well suited to packaging up the dumpster fire that any moderately-complicated Python app quickly becomes.

Of course now we have Rust and Go, but being able to shove your statically-compiled binary into a tiny scratch container and have it cooperate with orchestration systems is still a pretty nice abstraction— just harder to say if it would have been worth it had we not had Django apps needing to be made deployable first.