The saga started in 2006 when the Google Infrastructure Group discovered that a new abstraction, named process control group or simply container would solve an endless list of issues in their enormous computing cloud.
In accordance with the GPL and its spirit, Google contributed their work back to Linus. It took until 2013, however, before the Docker team managed to replicate the almost magical characteristics of Google’s cloud infrastructure.
Docker tremendously facilitates pipelining and chaining processes across different submachines (“containers”) even located on different physical devices that start in subsecond time frames.
Suddenly a new submachine appears on the network, spends milliseconds on processing things, and then disappears again. It is more than a process running a program, but not that much more, but it still looks like a complete networked device of its own with storage space included.
Of course, you will still need something like the Bash shell to do the control group pipelining and orchestrate the magic. Hence, Microsoft’s effort to urgently port Bash to Windows.
Microsoft has not managed to replicate the abstraction of process control group in the Windows kernel. Google do not have the source code access to do it for them, while the Microsoft kernel group is simply not capable of doing it. In other words, true cgroups in Windows will not be ready any time soon.
Therefore, Microsoft will be implementing a docker-like alternative based on Hyper-V. This will in fact not really be an alternative to Docker but to Oracle’s Virtualbox. It will still be touted as an alternative to Docker.
Therefore, if you consider using these new Microsoft Hyper-V containers for your own applications, make sure to compare them to for example, Oracle’s Virtualbox technology, and not to Docker.
Furthermore, you should not try to use them for control group process pipelining, because virtual machines are simply too slow for that purpose. Only containers are suitable for that.
The purpose of virtual machines, aka virtualization, is to isolate different tenants of a physical device from each other. It is essentially a hosting technology.
The purpose of a control group, aka container, is to swiftly resuscitate and then possibly shut down the precise context in which you want to run one (or more) programs. A running program is indeed called: a process.
You can perfectly well run a container inside a virtual machine, if you happen to be one of the tenants of the physical device on which you to want to run your programs.
It does not make sense to update or upgrade a container. You just create a slightly different one, from a given base image.
You can run a container for as long as you want, even years in a row, but you don’t have to.
By default, containers are well isolated from each other, but isolation is not their primary purpose. Multiple tenants should rather be isolated by virtual machines and not by containers.
Virtual machines want to look as much as they possibly can as real physical devices. Containers don’t. They just want to look exactly like the environment that one (or more) programs need and expect to be around when they start running.
In order to unleash the magic of control groups, you will need to master the shell, aka the commandline and have a good understanding of process primitives such as environment variables, arguments, stdin, stdout, stderr, result code, signals, stream redirection, and forking child processes. In other words, it can simply not be done by clicking buttons in Visual Studio.