5 ms·
This article is mostly FUD I think. It comes off as a slew of strawmen arguments ... for example the idea that unikernels are defined as applications that run
by bcg1 11y ago
This article is mostly FUD I think.
It comes off as a slew of strawmen arguments ... for example the idea that unikernels are defined as applications that run in "ring 0" of the microprocessor... and that the primary reason is for performance...
All of the unikernel implementations he mentioned (mirageos, osv, rumpkernels) all run on top of some other hardware abstraction (xen, posix, etc) with perhaps the exception of a "bmk" rumpkernel.
We currently have a situation in "the cloud" where we have applications running on top of a hardware abstraction layer (a monolithic kernel) running on top of another hardware abstraction layer (a hypervisor). Unikernels provide a (currently niche) solution for eliminating some of the 1e6+ lines of monolithic kernel code that individual applications don't need and introduce performance and security problems. To dismiss this is as "unfit for production" is somewhat specious.
I wonder if Joyent might have a vested interest in spreading FUD around unikernels and their usefulness.
- mwcampbell 11y agoYour argument in favor of unikernels assumes that we're stuck with hardware virtualization as the lowest layer of the software stack. What if cloud providers offered secure containers on bare metal, under a shared OS kernel? That's what Joyent provides. So yes, Joyent has a vested interest in calling out the problems with unikernels. But I think their primary motive is that they truly believe containers on bare metal are a superior solution.
- jclulow 11y agoSpeaking for myself, that's exactly why I work at Joyent. I believe in OS virtualisation (whether you call them zones or containers) for multi-tenancy, in high quality tools for debugging both live (DTrace) and post mortem (mdb), and in open source infrastructure software (SmartOS, SDC, etc). I also believe that as an industry and a field, we should continue to build on the investments we've already made over many decades. The Unikernel seems, to me at least, to be throwing out almost everything; not just undesirable properties, but also the hard-won improvements in system design that have fired so long in the twin kilns of engineering and operations.
- oxryly1 11y agoIsn't it possible, therefore, that Unikernel and Joyent's virtualisation serve different purposes and are definitely not meant to be interchangeable?
- lmm 11y ago>What if cloud providers offered secure containers on bare metal, under a shared OS kernel? Then they're offering a very similar thing. And the questions then are things like: What should the interface between contained and outside look like? Is there value in running a traditional unix userland inside the container? What kind of code do we want to run inside the container? IMO the unikernel answers to these questions are better. The Unix userland is an accident of history; if unikernels had come first we wouldn't even think of it.
- thescriptkiddie 11y agoI'm still a little confused as to why he assumed that unikernels will run under virtualization in production. The whole point of a unikernel is to get rid of a layer of abstraction, isn't it? So why would it make sense to replace that with another, thicker layer? Any non-toy unikernels are going to have to run on bare metal to actually get those performance gains. Kinda like how you don't run your docker host in a VM - you don't need to, because it replaces VMs. If you assume that a unikernel (or docker host) is going to run in a VM, of course it will look pointless.