Containers are useful in packaging applications and running them in isolation from other programs. This seems to be the de-facto standard in the software industry. What are alternatives to containers that provide similar capabilities?<p>More philosophically, are containers a necessary component needed to run software at scale (such as replication and partitioning)? Or are they the result of the accidental complexity the modern OS has?
> What are alternatives to containers that provide similar capabilities?<p>VMs on one hand, tools like Guix and Nix on the other.<p>> More philosophically, are containers a necessary component needed to run software at scale (such as replication and partitioning)?<p>No. They're one tool in the box among others. They're common for reasons, though.<p>> Or are they the result of the accidental complexity the modern OS has?<p>What does this even mean?
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.<p>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.<p>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.