| > I'd say that the static linking metaphor refers to the container image itself, in that it's standalone and (fairly) "universal". That metaphor makes no sense beyond the standalone part. Container images are way more than mere stand-alone statically linked binaries, much like an installer (deb/rpm/MSI/PKG/etc) are way more than statically linked binaries. If anything, container images are a kin to fat JARS or macOS's bundles, but even that metaphor leaves key features out, like healthchecks, image inheritance, and of course support for software defined networking. > To me, the analogy doesn't have to be 1:1 for it to work. The whole point is that the metaphor makes no sense and completely misses the whole point of containers. No one uses containers because they want statically linked binaries. Or even installers or packages. At all. What container users want is what containers provide and neither statically linked binaries or zips or installers or bundles come close to offer.
We're talking about being able to deploy and scale the same app at will in a completely sandboxed and controlled environment. We're talking about treating everything as cattle, from services to system architecture. We're talking about out-of-the-box support for healthchecks, and restart apps when they fail. Each and every single one of these features is made available with docker run. That's what containers offer. None of this has anything to do with static linking anything, and insisting on this metaphor shows that people completely miss the whole point of containers. |
> We're talking about being able to deploy and scale the same app at will in a completely sandboxed and controlled environment. We're talking about treating everything as cattle, from services to system architecture.
Same is true for AMIs and VMs. Containers are the technology, not the pattern.