I think that Docker became popular because of very limited functionality of distributions' package managers that doesn't match developers' expectations.
Traditionally in Linux there is no concept of "system" and "applications". There is only one large "system" and you can add parts to it. In old times, you downloaded C source code, make'd and installed it. Now you use a package manager to extend your system with new features, like playing music or editing images.
There are no "applications". If you download Firefox package from Debian repository, it is not the Firefox application; it is a version of Firefox, tuned, patched and customized for integrating into Debian. You probably won't be able to run it even in Ubuntu, let alone other distributions.
Paths are often hardcoded; you cannot install a program into your home directory or an USB drive (apt-get might let you do that but it won't fix the embedded file paths for you).
It might be good enough for a user (as we see with Google Play Store on Android), but it is very inconvenient for a developer. You often need to have several versions of a program, for example, PHP interpreter or Go compiler; no way a package manager lets you do that, compile them yourself. You might want to use an application with project-specific config rather than the one in /etc and start it on demand rather than install as a system daemon. That is not easy too. Apt-get and dpkg has literally hundreds of configuration knobs in the manual but you cannot choose installation directory.
If you want to run an old application, like Firefox 2.0, get prepared for troubles. While newer versions of libraries like gtk are supposed to be backwards compatible, it won't run with them (I tried). You will have to obtain and build old versions of gtk manually; good luck with that. On the good side, I can add that Debian maintains an archive of old packages and you need only to write a custom package manager to install them along with their dependencies.
Often official repositories have outdated versions of software; you have to add third-party repositories while giving them full root access to your machine. Want to install Sublime Text in Debian? You have to trust its authors because they can replace your sshd and you won't even notice. Also, third-party repos sometimes break or conflict with system ones.
Package managers are a pain for developers too. They have to maintain packages for all popular distributions, and even for different versions of those distribution. Because there is no "apps", you have to integrate your program into every distibution manually. Of course, you will have to do it again and again when anything changes in the distro. Distro maintainers often have to do the same thing, maintaining private patches. And on top of that, different distributions use different package format.
Maybe one of the reasons for this is a lack of a standard package manager and build system for C programs. You cannot download from Github and build a C program with dependencies with a single command. It is disappointing if you got used to languages like PHP where it has been possible for a long time.
Docker seems to solve many of these problems (and some other, like hardcoded server port numbers) by using a lightweigt virtual machine with full-blown distribution in it. Of course it looks more like a quick hack rather than reliable and well-thought solution. Also, Docker requires many resources: space on disk to store multiple images, memory and CPU time to run unnsesessary daemons inside virtual machines. I don't like it.
By the way Linux kernel has similar problem with drivers that are a part of a kernel rather than separate entities.
> ... because of very limited functionality of distributions' package managers that doesn't match developers' expectations.
In particular, package managers don't match the expectations of build systems, because package managers are written by and for ops guys.
A sysadmin working on system serving a production load rarely wants to reboot the system, let alone blow it all away and rebuild from scratch. Moreover, the sysadmin needs to administer many systems, so they don't want to have anything being installed in special places, that's just adding more complexity.
A build system has to account for the fact that devs are tinkering with the code, experimenting, etc. and need to periodically wipe it all away and run it with a clean slate.
> A sysadmin working on system serving a production load rarely wants to reboot the system, let alone blow it all away and rebuild from scratch.
Uh, actually, that's exactly what I want. It's just Ops managers [1] who can't seem to wrap their heads around the notion.
I've only once had the luxury to actually get to do that, and it took 5 minutes from IPMI reset to fully running system (scalable up to 100 boxes at a time from a single kickstart server). That was over 10 years ago, too.
> package managers are written by and for ops guys.
I just don't believe that, at least the "by" part. Linux is created by developers, my experience with the two major packaging systems is that the vast majority of the tooling for packaging has to do with the building, not administrative.
> A build system has to account for the fact that devs are tinkering with the code, experimenting, etc. and need to periodically wipe it all away and run it with a clean slate.
Ok.. so how do the Linux distro package build systems fail to account for that?
How does a packaging system have anything to do with the behavior of choosing to start with a clean or dirty slate?
[1] OK, and maybe some, maybe even most sysadmins, but please don't tar us all with the same brush.
Traditionally in Linux there is no concept of "system" and "applications". There is only one large "system" and you can add parts to it. In old times, you downloaded C source code, make'd and installed it. Now you use a package manager to extend your system with new features, like playing music or editing images.
There are no "applications". If you download Firefox package from Debian repository, it is not the Firefox application; it is a version of Firefox, tuned, patched and customized for integrating into Debian. You probably won't be able to run it even in Ubuntu, let alone other distributions.
Paths are often hardcoded; you cannot install a program into your home directory or an USB drive (apt-get might let you do that but it won't fix the embedded file paths for you).
It might be good enough for a user (as we see with Google Play Store on Android), but it is very inconvenient for a developer. You often need to have several versions of a program, for example, PHP interpreter or Go compiler; no way a package manager lets you do that, compile them yourself. You might want to use an application with project-specific config rather than the one in /etc and start it on demand rather than install as a system daemon. That is not easy too. Apt-get and dpkg has literally hundreds of configuration knobs in the manual but you cannot choose installation directory.
If you want to run an old application, like Firefox 2.0, get prepared for troubles. While newer versions of libraries like gtk are supposed to be backwards compatible, it won't run with them (I tried). You will have to obtain and build old versions of gtk manually; good luck with that. On the good side, I can add that Debian maintains an archive of old packages and you need only to write a custom package manager to install them along with their dependencies.
Often official repositories have outdated versions of software; you have to add third-party repositories while giving them full root access to your machine. Want to install Sublime Text in Debian? You have to trust its authors because they can replace your sshd and you won't even notice. Also, third-party repos sometimes break or conflict with system ones.
Package managers are a pain for developers too. They have to maintain packages for all popular distributions, and even for different versions of those distribution. Because there is no "apps", you have to integrate your program into every distibution manually. Of course, you will have to do it again and again when anything changes in the distro. Distro maintainers often have to do the same thing, maintaining private patches. And on top of that, different distributions use different package format.
Maybe one of the reasons for this is a lack of a standard package manager and build system for C programs. You cannot download from Github and build a C program with dependencies with a single command. It is disappointing if you got used to languages like PHP where it has been possible for a long time.
Docker seems to solve many of these problems (and some other, like hardcoded server port numbers) by using a lightweigt virtual machine with full-blown distribution in it. Of course it looks more like a quick hack rather than reliable and well-thought solution. Also, Docker requires many resources: space on disk to store multiple images, memory and CPU time to run unnsesessary daemons inside virtual machines. I don't like it.
By the way Linux kernel has similar problem with drivers that are a part of a kernel rather than separate entities.