4 ms·

I believe, that success of containers is not because of lightweightness or other isolation properties of them. Containers won dev mindshare because of ease pac

I believe, that success of containers is not because of lightweightness or other isolation properties of them. Containers won dev mindshare because of ease packaging and distribution of the artifacts. Somehow it is Docker, not VM vendors came up with a standard for packaging, distributing and indexing for glorified tarballs and it quickly picked up.

enw 5y ago
> glorified tarballs Calling container images glorified tarballs is like calling cars glorified lawnmowers.
- kjeetgill 5y ago
  Maybe closer to calling a 16-wheeler a glorified minivan. I think there's something meaningful in that comparison.
- brazzy 5y ago
  Um...a container image is very literally and exactly a collection of tarballs and some JSON files with metadata.
aequitas 5y ago
> Somehow it is Docker, not VM vendors came up with a standard for packaging, distributing and indexing for glorified tarballs and it quickly picked up. Packaged VM's existed for a while already with thing like Vagrant on top, there was also already LXC which leaned more into the VM concept. Where Docker made the difference imho is with Dockerfiles and the layered/cached build steps.
throwaway894345 5y ago
> Somehow it is Docker, not VM vendors came up with a standard for packaging, distributing and indexing for glorified tarballs and it quickly picked up. IMO the important, catalyzing difference is that Docker containers have a standard interface for logging, monitoring, process management, etc which allow us to just think in terms of “the app” rather than the app plus the SSH daemon, log exfiltration, host metrics daemon, etc. In other words, Docker got the abstraction right: I only care about the app, not all of the ceremony required to run my app in a VM. These common interfaces allow orchestration tools to provide more value: they aren’t just scheduling VMs, they’re also managing your log exfiltration, your process management, your SSH connection, your metrics, etc, and all of those things are configurable in the same declarative format rather than configuring them with some fragile Ansible playbook that requires you to understand each of the daemons it is configuring, possibly including their unique configuration file/filesystem conventions and syntaxes.

enw 5y ago

> glorified tarballs Calling container images glorified tarballs is like calling cars glorified lawnmowers.

kjeetgill 5y ago
Maybe closer to calling a 16-wheeler a glorified minivan. I think there's something meaningful in that comparison.
brazzy 5y ago
Um...a container image is very literally and exactly a collection of tarballs and some JSON files with metadata.

aequitas 5y ago

> Somehow it is Docker, not VM vendors came up with a standard for packaging, distributing and indexing for glorified tarballs and it quickly picked up. Packaged VM's existed for a while already with thing like Vagrant on top, there was also already LXC which leaned more into the VM concept. Where Docker made the difference imho is with Dockerfiles and the layered/cached build steps.

throwaway894345 5y ago

> Somehow it is Docker, not VM vendors came up with a standard for packaging, distributing and indexing for glorified tarballs and it quickly picked up. IMO the important, catalyzing difference is that Docker containers have a standard interface for logging, monitoring, process management, etc which allow us to just think in terms of “the app” rather than the app plus the SSH daemon, log exfiltration, host metrics daemon, etc. In other words, Docker got the abstraction right: I only care about the app, not all of the ceremony required to run my app in a VM. These common interfaces allow orchestration tools to provide more value: they aren’t just scheduling VMs, they’re also managing your log exfiltration, your process management, your SSH connection, your metrics, etc, and all of those things are configurable in the same declarative format rather than configuring them with some fragile Ansible playbook that requires you to understand each of the daemons it is configuring, possibly including their unique configuration file/filesystem conventions and syntaxes.