Hi, I'm the author of the article.
> Containers have been mature for longer than the article implies (freebsd jails, Solaris zones).
Mature containers have been around since the the days of mainframes. The recent (say, last decade) disparity has been lack of mature containers on the platform of choice, which is Linux for most cloud-based projects. I don't know many people who would switch their projects to run on FreeBSD or Solaris just to use containers instead of VMs.
Also, the container types you mention don't support independent, fine-grained choices of isolate-or-not for networking, the file system, user IDs, process IDs, and scheduling of system resources.
> Modern virt hardware+hypervisors is blazing fast and (I believe) will eventually outpace bare metal for specific workloads on big boxes due to the improved isolation for many performance critical operations (I.e. separate TLBs for flushes, smarter cache invalidation).
It's unclear why you think such optimization would appear in hypervisors but not kernels, especially given how much more insight a kernel has into the workloads it directly runs compared to a hypervisor running a kernel running workloads.
Even if hypervisors achieve CPU performance parity for running systems, you still haven't addressed the memory and storage overhead (in terms of resident footprint) of running full OS images instead of containers.
> Even if they don't reach parity, the gap certainty wouldn't justify giving up all the benefits of full virtualization.
You're portraying virtualization as having benefits versus containerization while ignoring that containerization also has many benefits over virtualization, especially w.r.t. cost efficiency.
> Containers have been mature for longer than the article implies (freebsd jails, Solaris zones).
Mature containers have been around since the the days of mainframes. The recent (say, last decade) disparity has been lack of mature containers on the platform of choice, which is Linux for most cloud-based projects. I don't know many people who would switch their projects to run on FreeBSD or Solaris just to use containers instead of VMs.
Also, the container types you mention don't support independent, fine-grained choices of isolate-or-not for networking, the file system, user IDs, process IDs, and scheduling of system resources.
> Modern virt hardware+hypervisors is blazing fast and (I believe) will eventually outpace bare metal for specific workloads on big boxes due to the improved isolation for many performance critical operations (I.e. separate TLBs for flushes, smarter cache invalidation).
It's unclear why you think such optimization would appear in hypervisors but not kernels, especially given how much more insight a kernel has into the workloads it directly runs compared to a hypervisor running a kernel running workloads.
Even if hypervisors achieve CPU performance parity for running systems, you still haven't addressed the memory and storage overhead (in terms of resident footprint) of running full OS images instead of containers.
> Even if they don't reach parity, the gap certainty wouldn't justify giving up all the benefits of full virtualization.
You're portraying virtualization as having benefits versus containerization while ignoring that containerization also has many benefits over virtualization, especially w.r.t. cost efficiency.