Hey folks!
Continuing the Container series with the typical “Container is NOT a VM”, that most of us don’t really understand fully. Well, at least not until now, as I got quite determined to figure it out :)
Hope you enjoy the article and, as usual, additional description is below the image!
(click on image to enlarge)
First things first - I was wrong about it as well. I thought that this means that VM carries the whole OS with it, whereas Container is that small light thing that carries only your binary and it's dependencies. Feather-like! I was wrong; in a way, at least.
Simply put - main difference is in how each technology communicates to underlying hardware. VMs use a Hypervisor in order to get direct access to hardware, effectively skipping the whole Host OS and being completely isolated. On the other hand, Containers rely on Host's OS to communicate to hardware. Specifically, Containers use Runtime Engines (e.g. Docker, containerd, etc.) to get access to underlying Kernel functions. So if anyone were to stop you on the street and ask you "So, what's the difference between VM and Container", your answer should be - "former carries it's own kernel and communicates directly to hardware, whereas latter relies on host OS to do stuff. Former is way more isolated and secure than latter one!".
Regarding the "Containers carry only their dependencies" - that's a funny one :) Truthfully, yes, Containers pack ONLY the libraries they depend on. But funny thing is that this usually means "almost the whole OS". Hence you have most of your containers that depend on "Alpine Linux" (FROM alpine), "Debian Linux" (FROM debian), "Windows Server" (FROM windows/nanoserver), etc.
Given the fact that containers rely on having host OS kernel to do stuff, this poses a logical limitation that you can run them natively only on environment that they were based on. Hence, if you build Container image from Windows - you can run it natively on Windows only. Same is true for Linux. If you want to go cross-platform - you need a lightweight VM with kernel that would actually enable stuff for you. Which makes sense, no?
And that'd be about it on this topic. Next time I'm going to go a level deeper into HOW Containers really communicate to Kernel, what is needed to achieve it, etc.
Until then!
Other articles in the Container series:
Docker != Containers (Part 2 of the series) - deals with the common misconception that “Docker” is all there is in Container world.
Containers are like The Truman Show (Part 4 of the series) - some words on the fact how Containers see themselves (and what really happens on the outside).
How do COWs (Containers on Windows) work? (Part 5 of the series) - specific focus on running containers natively on Windows.