> Alternative to VM is Linux namespaces. They're really not. Containers (and by that I mean their underlying technology) are not alternatives to VMs, in the sa

> Alternative to VM is Linux namespaces. They're really not. Containers (and by that I mean their underlying technology) are not alternatives to VMs, in the same way that unikernels are not alternatives to containers (yet, anyway). They're technologies that can be used for similar purposes, but in practice, they all have their tradeoffs that should be considered before use. For one, containers share the same kernel of the host machine. The isolation provided by VMs is on a deeper level, which also makes them more secure. Unikernels are more like VMs in this sense. My point is that the only drawback of unikernels in theory is the immature tooling and support around it. So I'm wondering if there is another reason that they haven't been as widely adopted as containers. > As to why VM is supposed to be lighter than container, I don’t really understand. You misunderstood. I said that unikernels, not VMs, have less overhead than containers. Containers require a minimal, but fully functioning, OS to work, while unikernels only require a cut-down version of a kernel. Whether unikernels are more lightweight is debatable, since containers are merely another process running on the same host OS with improved isolation, while unikernels depend on a hypervisor to work, but if we define "lightweight" to include boot time and performance, unikernels have certainly surpassed containers in this sense as well[1]. So the main benefit containers had over VMs is also an attribute of unikernels. [1]: https://www.ietf.org/proceedings/95/slides/slides-95-nfvrg-2.pdf https://www.ietf.org/proceedings/95/slides/slides-95-nfvrg-2...