[externalreality]

> only two things that matter: ease of use and memory consumption

Those are seriously not the only two things that matter. Not by a long shot. Depending on what you are doing there are other serious concerns like security, OS Noise and other performance concerns. From the literature I've been reading security is a huge concern when deploying containers. From experience I can tell you that Dev-Ops with containers can be a nightmare and a half costing companies heavily.

Saying Ease-of-Use and Memory footprint is all that matters is serious misinformation that no research or other literature or anecdote supports.

That said, at least, ease of use is coming. There are some tools on the market right now that make Unikernels fairly easy to use Ops and BoxFuse come to mind.

[balena]

I do share your vision externalreality, I'm just saying from an approximate, but factual, point of view, unikernels won't share a fraction of containers popularity until they can compete in the two areas I mentioned. ️

[externalreality]

Agreed, agreed.

[MuffinFlavored]

> From experience I can tell you that Dev-Ops with containers can be a nightmare and a half costing companies heavily.

Why are containers any more dangerous/vulnerable/prone to leaks than deploying say... a standalone REST API not in a container?

[externalreality]

> Why are containers any more dangerous/vulnerable/prone to leaks than deploying say... a standalone REST API not in a container?

Its not about one service, its about n services running on the same resource partitioned hardware. If one gets compromised how likely is that to affect other services running on other partitions. Containers (High, shared kernel), Unikernels (Lower, different kernel, hardware supported isolation - almost like running n different physical machines).

[viraptor]

It's not obvious though. It may be less risk, but you're not eliminating interfaces with a VM. You're replacing them with new ones. With bare processes you've got shared system resources and kernel to attack. With Docker you've got the kernel to attack. With VMs you've got virtual hardware drivers to attack.

We can play with risk estimation, but in practice, both containers and VMs were affected by memory sharing failures already. We know that syscall/ioctl issues exist. And we know that virtualisation issues exist.