4 ms·
Historically the container as a product was not OS complexity derived, but language packaging and runtime heterogeneity derived. C/C++, Java, Ruby, Python, Go,
by jonahbenton 2y ago
Historically the container as a product was not OS complexity derived, but language packaging and runtime heterogeneity derived. C/C++, Java, Ruby, Python, Go, etc all have different packaging practices and trying to unify those inconsistencies across a fleet was what inspired the container, which was possible because underlying OS technologies like namespacing and layered filesystems existed.
The namespacing and layered filesystem work in the OS that make containers possible itself arose through other motivations within kernel scope to actually reduce accidental complexity and make various workloads, like suspend and resume, more sane.
Now that containers exist and have been successful, related but alternate tech like unikernels have seen interest, to reduce the security surface and further optimize deployments of large fleets.