Company selling compute in shock promotion of higher compute requirements
If you need a VM, use a VM, if you need containers, use them. They are not interchangeable.
Intel's taken its turn trying to advance containerisation technology by announcing a new approach to container security. Chipzilla'ss new idea is called “Clear containers”, which rely on the VT-x extensions in its chippery to enhance security and scalability. VT-x adds virtualisation support to silicon, the better to let CPUs …
This post has been deleted by its author
>If Intel can provide the added isolation of a VM but with the lower overhead of a container
Except, they can't. Not given the cost of a context-switch on an x86-type CPU. They appear to be using a minimalistic VM based on kvmtool and quote some enouraging figures on memory overhead and startup times, but I've seen nothing about actual execution overhead. There are really two performance advantages of containers over VMs - one is the simplified memory management (you're not maintaining multiple copies of the OS occupying more RAM or multiple sets of page tables and multiple kernels competing for the cache and TLB) and the other is that you don't have a set of virtual device drivers intercepting I/O requests and serving them out to individual VMs. You can't magic those away.
The argument seems to be that bugs in the OS can be exploited in a shared container environment. Well, bugs in the VM can be exploited too. There are x86 architectural features that could improve the security of containersiation - lilke multiple protection rings - but they don't perform very well/have long-standing problems. What Intel appear to be doing is trying to define the problem as one that can be solved by the better-implemented features they already added to their processors to support virtualisation. They could, instead, be improving/fixing or adding features to their processors to support containerisation - and probably will, at some point, when the requirements are more stable. This sound very much like keeping their foot in the door in the meantime.
Not given the cost of a context-switch on an x86-type CPU
Can you expand on that? Surely both containers and VMs incur context switches somewhere along the line? Are you saying that trapping all the way out to the hypervisor and back to kernel space is a heavy cost compared to switching between processes in the same kernel?
A group of senior architects were discussing the value of containerisation, it's been around awhile, and the conclusion we came to was that, actually it would never reach it's full potential because most developers can't be bothered to understand their deployment environments and weed out the stuff they don't need, and use a load of stuff they can share.
Not to say there aren't people who do it right, or even want to do it right, but apart from lazy developers there are also lazy project managers who don't understand the technologies, and won't invest in what they see as effort that mostly doesn't benefit their projects.
Enterprise class server software can support multiple applications very effectively, and indeed flex their resources across multiple servers, though seldom get deployed that way. So, in the end, containers will not just benefit chip manufacturers by adding another abstraction layer, but also Enterprise software vendors who can sell yet more licences for under utilised software.