undefined | Better HN

0 pointsrualca4y ago0 comments

> Exactly! I don’t see this as a criticism of containerization so much as it is a praise of static linking.

Not really. It seems the keyword "static linking" is being abused to refer to stand-alone executables, because that's what some people know. Yet, calling containers a kind of "static linking" is simplistic and incorrect, even taking the standalone executable interpretation info account.

If anything, container images are installers, and containers are the end-result of installing and configuring these containers, which is barely noticed because it works so well even and specially the networking part. More importantly, containers are designed to be both ephemeral and support multiple instances running in parallel on the same machine.

Then there's also the support for healthchecks, which allows container engines to not only determine when they should regenerate containers, but also provides out-of-the-box support for blue-green deployments.

And absolutely none of this fits the "static linking" metaphor.

0 comments

vladvasiliu4y ago

I'd say that the static linking metaphor refers to the container image itself, in that it's standalone and (fairly) "universal".

All the other things you talk about could be set up for standalone binaries as some form of orchestration, after installation, as you say.

To me, the analogy doesn't have to be 1:1 for it to work. Yes, that means there are edge cases which should be taken into account, but that doesn't make it useless.

Especially if you look at how most developers see containers: "I'll give you this image, which I know works [in a given way] and you can run it with something that understands it". You can go ahead and set up a full K8S cluster to run it, or you can run it on Docker Desktop on a random Windows / Mac laptop. "It just works", and it's in this I think the "universal static binary" analogy works.

I get the feeling that all those fancy orchestration tools (health checks, blue / green deployment / fancy network setup / etc) have seen an impressive growth around container runtimes, and therefore often thought of as belonging together, but I don't think that one requires the other and couldn't exist without the other.

I'm curious to see what kind of ecosystem will grow around new developments such as Firecracker and "unikernel containers". I seem to remember a post on HN the other day about some effort by google to run go binaries directly on some VM kernel.

rualcaOP4y ago

> 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.

nyx__4y ago

Containers aren't Docker. They're a combination of Linux features. Your container runtime might provide health checks and fancy features, but containers do not.

> 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.

rualcaOP4y ago

> Containers aren't Docker.

Discussing if containers are Docker or not I'm this discussing is a non-sequitur fueled by needless nitpicking and being pedantic for being pedantic.

The whole point is that all those features that I listed are basic container features, not higher-level concepts provided at the container orchestration level.

> Same is true for AMIs and VMs.

No, not really. Running something in a VM is not the same as running a containerized process.

1 more reply

catlifeonmars4y ago

In practice, I think the analogy holds up. A sizable chunk of use cases for containerization is to confer the benefits of standalone executableness, which is similar to a sizable chunk of use cases for statically linked binaries.

rualcaOP4y ago

> A sizable chunk of use cases for containerization is to confer the benefits of standalone executableness,

No, not really. Just because in the end you get to run an application that does not mean that it's reasonable to explain thins in terms of static linking.

This broken metaphor is particularly counterproductive once you take into account that container images also provide you the tools to bundle interpreters, run shells, and create temporary file systems automatically.

Talking about containers in any way that leaves out the containing part is counterproductive and a bad mental model.

catlifeonmars4y ago

Yes those are things you can do with containers. I don’t get your point. It’s not like a said containers are only useful for bundling dependencies.

As an aside, I think we’re approaching the concept from two different perspectives. I’m working backwards from a (sub)set of use cases, while you appear to be working forwards from a set of capabilities. I think both approaches have their place.

catlifeonmars4y ago

> More importantly, containers are designed to be both ephemeral and support multiple instances running in parallel on the same machine.

This sounds a lot like how all os processes work (regardless of linking type of a binary).

rualcaOP4y ago

You don't create persistent file system mounts by launching a process, nor do you mount files into the process's file system.

j / k navigate · click thread line to collapse

0 comments

vladvasiliu4y ago

I'd say that the static linking metaphor refers to the container image itself, in that it's standalone and (fairly) "universal".

All the other things you talk about could be set up for standalone binaries as some form of orchestration, after installation, as you say.

To me, the analogy doesn't have to be 1:1 for it to work. Yes, that means there are edge cases which should be taken into account, but that doesn't make it useless.

rualcaOP4y ago

> 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.

> 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.

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.

nyx__4y ago

Containers aren't Docker. They're a combination of Linux features. Your container runtime might provide health checks and fancy features, but containers do not.

Same is true for AMIs and VMs. Containers are the technology, not the pattern.

rualcaOP4y ago

> Containers aren't Docker.

Discussing if containers are Docker or not I'm this discussing is a non-sequitur fueled by needless nitpicking and being pedantic for being pedantic.

The whole point is that all those features that I listed are basic container features, not higher-level concepts provided at the container orchestration level.

> Same is true for AMIs and VMs.

No, not really. Running something in a VM is not the same as running a containerized process.

1 more reply

catlifeonmars4y ago

rualcaOP4y ago

> A sizable chunk of use cases for containerization is to confer the benefits of standalone executableness,

No, not really. Just because in the end you get to run an application that does not mean that it's reasonable to explain thins in terms of static linking.

Talking about containers in any way that leaves out the containing part is counterproductive and a bad mental model.

catlifeonmars4y ago

Yes those are things you can do with containers. I don’t get your point. It’s not like a said containers are only useful for bundling dependencies.

catlifeonmars4y ago

> More importantly, containers are designed to be both ephemeral and support multiple instances running in parallel on the same machine.

This sounds a lot like how all os processes work (regardless of linking type of a binary).

rualcaOP4y ago

You don't create persistent file system mounts by launching a process, nor do you mount files into the process's file system.

j / k navigate · click thread line to collapse