> Hi, I'm the author of the article. Awesome! Although I don't agree with the thesis, any systems article is a great article :) > Also, the container types yo

> Hi, I'm the author of the article. Awesome! Although I don't agree with the thesis, any systems article is a great article :) > 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. Granted, containers have gotten better over time. My beef isn't with containers, just that they're often compared to virtualization as if they're a substitute or replacement. I really disagree with that. Containers are still one kernel, with a huge attack surface. Forget about other OSes (including other versions of linux -- system calls do change over time, e.g. -- epoll, inotify, etc.). It's still a single buffer cache, so policing memory (beyond RSS) and disk I/O is tricky. It's one thing for a platform like Heroku, but containers don't make sense for a general purpose, multi-tenant infrastructure. > 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. Re: The long-term performance of virtualization. It's a different abstraction which I believe lends itself better to using all the resources of large physical machines. We're talking future here (so to be sure, we'll just have to wait and see), but as a philosophy it makes sense to me. The same way we hit the limit on cranking the frequency of CPUs and eventually starting adding cores, a single operating system won't scale linearly forever. (Not that Linux isn't doing a laudable job). The optimizations I mentioned specifically apply to the use of virt hardware (i.e. the VT extensions effectively give you multiple TLBs because they are tagged) because there are different set of semantics associated with how those threads of execution run on the hardware. The restricted physical interface presented to VMs can free the hardware by shifting some low-level problems of scale and co-ordination into software (effectively achieving performance by forcing a more scalable software architecture). > 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. There are techniques to reduce these overheads, but you've got a good point -- there is a price to pay for full virtualization. But fundamentally, I think this is part of the trade-off of better isolation. A common buffer cache in Linux will improve performance of containers, but it becomes very difficult or impossible to enforce exact resource policies. > 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. I acknowledge that containers can be more efficient -- I just don't think it justifies giving up the benefits that full virtualization provides. I also think that virtualization is valuable because it enables some additional technologies, but that's a different story... Ultimately, I think it boils down to the fact that I just don't think containers and VMs are comparable. I don't see how containers could displace virtualization for infrastructure use cases beyond a platform for specific applications. The EC2+Heroku model makes perfect sense -- some people will run containers inside VMs on a general purpose infrastructure, some won't.