4 ms·

I'm not going to support the general thesis of this article, but I want to address something you said. You're right that containers are not VMs, but that's onl

by cmsj 7y ago

I'm not going to support the general thesis of this article, but I want to address something you said. You're right that containers are not VMs, but that's only really relevant as pedantry of technical details. I think that what the author was trying to say (without really understanding it) was a comparison of containers to VMs as units of software deployment. I don't think anyone is credibly using containers as a security measure on Linux, because if they think they are, they are in for several large surprises. Rather, we're seeing the unbundling of software - it used to be that you deployed software to a physical machine with a full OS, then you could deploy it to a virtual machine with a full OS, then you could deploy the process, its dependencies and a minimal OS into a container. I agree that Docker doesn't have a huge and profitable future ahead of it, because it's providing commodity infrastructure. Rather I think it's interesting to think about what the next level of software deployment decomposition will be, and I'd wager that it's FaaS (ie serverless).

vorpalhex 7y ago
> You're right that containers are not VMs, but that's only really relevant as pedantry of technical details. That isn't pedantry, it is an extremely critical point and the one most people miss when figuring out Docker. Both from a security context (docker doesn't provide vm level promises about isolation) and from a resource management side (docker is really close to no overhead). It is not uncommon to deploy containers on VMs in the real world...
- hardwaresofton 7y ago
  This is precisely why I said the fact that someone would gloss over this is a red flag. The point is super critical. VMs are literally so hard to do correctly and in a performant fashion that parts of CPU instruction sets[0], and kernel subsystems (KVM[1]) were created to make them easier to run. Containers, in contrast are literally a few flags and a bunch of in-kernel antics. A few people, notably Liz Rice and Jessie Frazelle have given talks on how to make containers from scratch that are very illuminating for those that are interested: https://www.youtube.com/watch?v=HPuvDm8IC-4 https://www.youtube.com/watch?v=HPuvDm8IC-4 https://www.youtube.com/watch?v=cYsVvV1aVss https://www.youtube.com/watch?v=cYsVvV1aVss [0]: https://en.wikipedia.org/wiki/X86_virtualization https://en.wikipedia.org/wiki/X86_virtualization [1]: https://en.wikipedia.org/wiki/Kernel-based_Virtual_Machine https://en.wikipedia.org/wiki/Kernel-based_Virtual_Machine
  - panpanna 7y ago
    Containers are "easy" because they are backed by tons of kennel code (cgroups, namespaces and basically a small part of many other subsystems). You can actually create containers from the shell! VMs are "hard" because you start with nothing save some very low-level help from the hardware.
    - hardwaresofton 7y ago
      Also, I want to be clear that I'm using "simple" and "easy" in the rick hickey sense of the words, as in "simple" has more to do with what a thing is made of, and "easy" has more to do with ease of use, taking available tooling/familiarity and context into mind. What I should have made clearer was that I think containers are both easier and simpler than VMs. There are both less moving parts (I haven't looked, but I assume less code), and containers are easier to get started with than VMs (set some flags on some syscalls versus make sure you buy the right CPU).
      - panpanna 7y ago
        Fair enough, but don't forget there are some extremely simple hypervisor implementations out there too.
hardwaresofton 7y ago
> I think that what the author was trying to say (without really understanding it) was a comparison of containers to VMs as units of software deployment. I agree, I think the next evolution of software deployment is definitely heading to sub-program sizes. I do want to point out that we've seen this before, it was called CGI. It's not exactly the same, and things will be better this time (more isolation, better tooling), but if we're doing functions-as-a-service now, we were doing scripts-as-a-service much earlier. I think the great unbundling of the future is definitely coming and in fact it's already here -- it's just unevenly distributed. > I agree that Docker doesn't have a huge and profitable future ahead of it, because it's providing commodity infrastructure. Rather I think it's interesting to think about what the next level of software deployment decomposition will be, and I'd wager that it's FaaS (ie serverless). This was not what I meant to get across -- Docker may have a huge and profitable future ahead of it, but is only tangentially related to the near assured continuance of containerization. Docker as a company and project's goals are different, they do more than simply offer a way to run containers, and they have for a very long time -- my point was that the literal use of the word "docker" should die, because we should be just referring to containerization in the general sense (no matter which lib you're using). It's like the "tissue" vs "kleenex" debate, in a way.
- cmsj 7y ago
  That's a fair point, small-d-docker should not be a thing.

by cmsj 7y ago

vorpalhex 7y ago

> You're right that containers are not VMs, but that's only really relevant as pedantry of technical details. That isn't pedantry, it is an extremely critical point and the one most people miss when figuring out Docker. Both from a security context (docker doesn't provide vm level promises about isolation) and from a resource management side (docker is really close to no overhead). It is not uncommon to deploy containers on VMs in the real world...

hardwaresofton 7y ago
This is precisely why I said the fact that someone would gloss over this is a red flag. The point is super critical. VMs are literally so hard to do correctly and in a performant fashion that parts of CPU instruction sets[0], and kernel subsystems (KVM[1]) were created to make them easier to run. Containers, in contrast are literally a few flags and a bunch of in-kernel antics. A few people, notably Liz Rice and Jessie Frazelle have given talks on how to make containers from scratch that are very illuminating for those that are interested: https://www.youtube.com/watch?v=HPuvDm8IC-4 https://www.youtube.com/watch?v=HPuvDm8IC-4 https://www.youtube.com/watch?v=cYsVvV1aVss https://www.youtube.com/watch?v=cYsVvV1aVss [0]: https://en.wikipedia.org/wiki/X86_virtualization https://en.wikipedia.org/wiki/X86_virtualization [1]: https://en.wikipedia.org/wiki/Kernel-based_Virtual_Machine https://en.wikipedia.org/wiki/Kernel-based_Virtual_Machine
- panpanna 7y ago
  Containers are "easy" because they are backed by tons of kennel code (cgroups, namespaces and basically a small part of many other subsystems). You can actually create containers from the shell! VMs are "hard" because you start with nothing save some very low-level help from the hardware.
  - hardwaresofton 7y ago
    Also, I want to be clear that I'm using "simple" and "easy" in the rick hickey sense of the words, as in "simple" has more to do with what a thing is made of, and "easy" has more to do with ease of use, taking available tooling/familiarity and context into mind. What I should have made clearer was that I think containers are both easier and simpler than VMs. There are both less moving parts (I haven't looked, but I assume less code), and containers are easier to get started with than VMs (set some flags on some syscalls versus make sure you buy the right CPU).
    - panpanna 7y ago
      Fair enough, but don't forget there are some extremely simple hypervisor implementations out there too.

hardwaresofton 7y ago

> I think that what the author was trying to say (without really understanding it) was a comparison of containers to VMs as units of software deployment. I agree, I think the next evolution of software deployment is definitely heading to sub-program sizes. I do want to point out that we've seen this before, it was called CGI. It's not exactly the same, and things will be better this time (more isolation, better tooling), but if we're doing functions-as-a-service now, we were doing scripts-as-a-service much earlier. I think the great unbundling of the future is definitely coming and in fact it's already here -- it's just unevenly distributed. > I agree that Docker doesn't have a huge and profitable future ahead of it, because it's providing commodity infrastructure. Rather I think it's interesting to think about what the next level of software deployment decomposition will be, and I'd wager that it's FaaS (ie serverless). This was not what I meant to get across -- Docker may have a huge and profitable future ahead of it, but is only tangentially related to the near assured continuance of containerization. Docker as a company and project's goals are different, they do more than simply offer a way to run containers, and they have for a very long time -- my point was that the literal use of the word "docker" should die, because we should be just referring to containerization in the general sense (no matter which lib you're using). It's like the "tissue" vs "kleenex" debate, in a way.

cmsj 7y ago
That's a fair point, small-d-docker should not be a thing.