What we collectively refer to as "containers" and software like Docker are just tools that take advantage of various facilities provided by the OS which allow one to isolate/restrict various resources like CPU, memory, network, visibility of other processes, filesystem access, fs layering and namespacing, provide traffic shaping, etc. These isolation features go back a really long time in various OS's, but only in th…
> These isolation features go back a really long time in various OS's, but only in the last few years have they seen mass adoption, which, alas is running a bit ahead of any effort to make it a formal standard or anything even close to that. Also containers really didn't get very secure until Google started upstreaming various patches and updates to the kernel's cgroups[0]. The way docker runs containers is very diff…
OpenVZ's containers—and they were containers, in every sense of the word—were already secure; what they weren't was implemented by a set of granular, reusable in-kernel primitives that served any goals other than that of "containerization." Instead, OpenVZ was a very "cathedral"-esque approach to Linux containerization: just one big blob of code with a complex API surface. Thus, the kernel refused to upstream it.
Google's contribution was mainly to clone the feature-set of OpenVZ by working on a series of small enhancements (to cgroups and kernel namespaces) that would each be a useful standalone feature, but would also coincidentally be composable to replicate the power of an OpenVZ container. In other words, to create an OpenVZ alternative that was mergeable.
(Side-note: although Virtuozzo is recently a standalone company, for most of its life it was a brand owned by Parallels. If anyone is to "blame" for Linux containerization becoming a thing everyone was interested in, it's probably them.)