Unikernels don't need a killer app, they need millisecond boot and teardown time from the major cloud vendors, along with suitable pricing.
Unikernels are a great technology and very much ready for prime time, but unless cloud vendors provide the millisecond boot/teardown/pricing, Unikernels will remain nothing more than a niche special interest technology.
All the technology is in place for Unikernels to take off once the cloud vendors get behind them.
I wrote Bootrino specifically for the purpose of booting Unikernels (and a whole host of other exotic tiny operating systems) on the major clouds and it works fine -
you can see a demo here: https://www.youtube.com/watch?v=zJhxmVlR46c (Bootrino not released to public as yet).
However, the real draw for Unikernels is short lifetime function as a service type applications.
To add to this, I think attention needs to shift from "booting" unikernels to sorta... "instantiating" them. Booting involves enumeration, initialization, and teardown of devices. If unikernels could be resumed from a compact memory image without having to enumerate or initialize any (virtual) devices then I figure things would get a lot easier.
For what it's worth, though, there's a lot of value in long-running unikernels. There are good reasons not to pay even the cost of a memcpy of the unikernel image, especially when it comes to making good use of system resources. I'm mostly interested in unikernels on bare metal (or something close, like device-specific PCIe passthrough). There's a lot of potential in an application having full and exclusive access to a hardware platform; it means that your application can make creative use of isolation primitives, be aware of its true resource limits, and choose scheduling and work sharing primitives which make sense for the application.
In many ways, good unikernel environments are similar to DOS, I'm amused to see the resurgence.
There are plenty of standalone libcs that can be compiled like any other code, they don't need special support from the host. Likewise you could effectively statically link any libraries you wanted into your unikernel image - though if you just build the normal interpreter then you're not getting a lot of advantage out of having a unikernel, part of the point is to build your program in a more direct form without so many extra layers of translation.
It would. But it would come with a cost because you need to store that instance in very fast storage, something like RAM, in order to have very fast reanimated times. The problem with this is that RAM is still at a premium in cloud services.
> This VM would not have an IP stack but a small, secure, and well defined interface. It can basically do two or three things to communicate with the host: [...] All of these mechanisms can be transported out of the VM through hypercall (like VMCALL).
So how is this better than using existing IPC mechanisms and using the "user" abstraction to separate privileges?
And how is this more secure then IPC to a process running under another user given
> The browser takes a careful look at the pointer and the data it is pointing at. This code will need to be properly vetted as a buffer overflow here could potentially allow the unikernel to execute code outside its hardware prison.
(The long list of CVEs tells us how good programmers are at "properly vetting" buffers).
> So how is this better than using existing IPC mechanisms and using the "user" abstraction to separate privileges?
It's a smaller, cleaner, interface that's been designed from day 1 to be secure, rather than having security awkwardly partially retrofitted.
> (The long list of CVEs tells us how good programmers are at "properly vetting" buffers).
Right, which is exactly why it's vital to keep those interfaces as small as possible, rather than having dozens of different IPC mechanisms for vulnerabilities to hide in.
> It's a smaller, cleaner, interface that's been designed from day 1 to be secure,
Care to argue how something based on sharing memory could ever be more secure than sending messages over pipes or sockets (between different processes)?
Pipes and sockets on a local system are usually implemented using shared memory. While there are challenges to implementing secure* shared memory interfaces, it has been done (see eg. SEL4, QNX and many others).
If there was only one of pipes, sockets, system calls, and the filesystem, that would be fine. Instead there are all of those and more.
There's no fundamental reason shared memory should be less safe than sockets (say); ultimately it's just bytes. Shared memory has a bad reputation because of how it behaves when processes sharing memory run concurrently, especially if they're both writing, but that's not a concern when we're talking about a unikernel interacting with the host, because there's no need to have anything happen concurrently there.
> If there was only one of pipes, sockets, system calls, and the filesystem, that would be fine. Instead there are all of those and more.
So you choose ONE for the message-passing mechanism. If the process does not incorporate code that opens a pipe and reads from it, you cannot force it to do so. Alternatively, there are all of these and you want to add VMCALL to that soup as well.
> There's no fundamental reason shared memory should be less safe than sockets (say); ultimately it's just bytes.
We're talking about a unikernel writing to the hypervisor's address space. A bug in the hypervisor's validation (or another exploit) will allow it to overwrite arbitrary memory in the hypervisor. Sockets will not.
> So you choose ONE for the message-passing mechanism. If the process does not incorporate code that opens a pipe and reads from it, you cannot force it to do so.
But then you find that somewhere in the lower layers of the framework/interpreter you were using there's something that relies on it. You disable all the sysctls you thought you weren't using and then your image library turns out to need them. Once the functionality has ever existed in the ecosystem, it's very hard to get away from.
> Alternatively, there are all of these and you want to add VMCALL to that soup as well.
I want to deprecate all the others at the same time, otherwise there would indeed be no point.
> We're talking about a unikernel writing to the hypervisor's address space. A bug in the hypervisor's validation (or another exploit) will allow it to overwrite arbitrary memory in the hypervisor. Sockets will not.
What's the difference between a unikernel sending data to the hypervisor and a process sending data to the kernel? The data always has to cross the boundary one way or another. Why would one approach be any more or less safe than the other?
> But then you find that somewhere in the lower layers of the framework/interpreter you were using there's something that relies on it.
So you refrain from using the framework in question because the very same framework wouldn't work at all in the hypothetical VM because files do not exist there. You have to write everything from scratch using only your IPC mechanism of choice, just like with VMCALL.
> What's the difference between a unikernel sending data to the hypervisor and a process sending data to the kernel?
Ultimately, trust.
1. The developers. I have more confidence in the implementors of, say, Linux kernel, than in developers of, say, Chrome or Firefox or Safari.
2. Testing. Kernels routinely handle successfully vastly more corner-cases than web-browsers. [Yes, I see upon all of current Linux, Windows, etc. installations as continuous, live, in-production testing.]
If kernels were as shabby as today's browsers, nobody would use them for anything but toys. On the other hand, try to find a person who gets genuinely surprised when a web browser crashes.
> So you refrain from using the framework in question because the very same framework wouldn't work at all in the hypothetical VM because files do not exist there. You have to write everything from scratch using only your IPC mechanism of choice, just like with VMCALL.
It's always going to take a new standard and a new community/ecosystem that fits things into that new standard or rewrites the things that can't be fitted. The only way such an effort can ever hope to succeed is a) an extremely clear standard with a rigorous conformance test b) a way to run legacy programs that don't comply with the standard c) but in such a way that there are still incentives for programs to move onto the new way.
In theory we could create a stripped-down linux that only offered one limited form of IPC and then start porting libraries and processes to run on that stripped-down linux. But it would be difficult to get a consensus on exactly what system calls etc. are allowed, and what would you do for running legacy processes? You have to add the alternative IPC systems etc. back in and add an opt-out mechanism, and then a) every component, even well-behaved ones, loses the advantages of the new system (fast booting, low overhead and so on) b) there's very little incentive for a component to ever be ported to the new system.
> 1. The developers. I have more confidence in the implementors of, say, Linux kernel, than in developers of, say, Chrome or Firefox or Safari.
I'm not sure where web browsers comes into it. I have a lot more confidence in the unikernel folks than the container folks from what I've seen of their tool choices and code quality.
> Kernels routinely handle successfully vastly more corner-cases than web-browsers.
Kernels get very little direct exposure to actively hostile userspace programs, and local privilege escalation vulnerabilities are relatively common - indeed I'd say more common than browser vulnerabilities.
> The only way such an effort can ever hope to succeed is a) an extremely clear standard with a rigorous conformance test
VMCALL is too flexible for being able to call it a "standard". What does the original article suggest? Yeah, define a struct and pass a pointer to it. As "standard" as defining protobuf messages.
Heck, even the "big" (Xen, HyperV, VMWare, VirtualBox) hypervisors don't agree on their hypercalls.
The problem of having multiple incompatible OS-interfaces is repeating itself, just one level below, on the hypervisor level. Madness.
Ironically, these problems would not exist had the world gone the way of IDL and microkernels.
> b) a way to run legacy programs that don't comply with the standard
No-go unless the VM implements all of the stuff that you want to get rid of.
Plus, whatever you decide to run in a VM may want to talk to a service in another VM. How do they talk to each other? [continue the exercise until you reimplement one or more of existing IPC mechanisms].
> Ironically, these problems would not exist had the world gone the way of IDL and microkernels.
I see it as another path to a very similar end state. A unikernel running under a hypervisor is much like a process running under a microkernel.
> No-go unless the VM implements all of the stuff that you want to get rid of.
Legacy components can run under a traditional linux VM running under the same hypervisor. If you've got, say, a gnarly image processing piece that needs to talk to a task queue over unix domain sockets or something, you run them both in the same VM; you can get on with your business, but at the same time that doesn't impact the isolation of your other components, performance/scalability cost is only borne by the component that's causing it, so there's an adequate incentive to properly isolate that component (or maybe not - if it's not causing reliability or performance issues it can stay as it is, that's fine too).
> Plus, whatever you decide to run in a VM may want to talk to a service in another VM. How do they talk to each other?
In a way that's always traditionally been used for untrusted communications (e.g. network sockets), so that they know not to trust each other.
The network stack shouldn't need to be trusted - inter-unikernel routing can be done by another (untrusted) dedicated unikernel, just as in a microkernel.
And yes, whenever one component talks to another they have to authenticate themselves; that's much of the point.
I would argue they are roughly comparable, not one better than the other. The risk profile is similar and the common CVEs are the same between the two.
As far as i understood, it is single point of failure and something that browser developers would need to ensure, not end developers. It's possible to cover that specific part with extensive testing and fuzzing to make sure it's robust.
All the replies so far miss amluto's point: A unikernel running on a hypervisor is a process, just with an awkward syscall interface and inflexible memory management. Especially when the hypervisor is KVM which runs VMs as regular Linux processes, this is very clear.
> A unikernel running on a hypervisor is a process, just with an awkward syscall interface and inflexible memory management.
...and with no way to run ancillary scripts and cronjobs e.g. log management, backups, security tools...
Nor ssh into the VM to inspect it and run debuggers or monitoring and metric agents.
Essentially you are giving away all the practical advantages of modern OSes. There's a reason why the usual famous tech companies don't use unikernels, generally speaking.
VM interfaces are awkward due to emulating hardware so that they can run existing operating systems. A VT-backed unikernel interface does not need to inherit this awkwardness.
As for memory management, in the Solo5/ukvm case the amount of memory you grant to the guest (monitor process) is essentially the maximum you expect the guest to need, ever. So it's similar in terms of overhead to many usermode allocators which just mmap() a huge block of memory at start and then hand out to the application from that.
That's how a regular KVM works as well (mmap a physical memory block) and the mismatch comes from the fact that all the regular OS memory management mechanisms -- reclaim, swap, page cache, etc. -- are all broken by the abstraction provided.
FV guests can similarly have a balloon driver, that doesn't mean the interface isn't awkward.
A user process running on an OS running on a hypervisor has certain overhead, so you can either remove the hypervisor (native containers) or you can remove the OS (unikernels). Arguably the hypervisor has a smaller attack surface than an OS.
Also, there's a small set of programs that don't get along with the abstractions provided by OSes and run better on a virtual hardware abstraction instead.
You realize that the guest OS _does_ things right? It's not just overhead. You can't just remove the Linux network stack, you have to replace it with something. (And the Linux network stack is pretty damned good at what it does.)
The intrinsic overhead of the OS (i.e. costs of mode switching) is much smaller than you might think.
It's true that some programs don't really want an OS getting in their way, but a modern operating system provide decent facilities for getting _out_ of the way (e.g. O_DIRECT for block I/O, pinning tasks to cores) and that's usually what those things use.
A userspace process on x86 has a certain amount of overhead, namely the overhead needed to switch between it and the host kernel. This takes the form of SYSCALL/SYSRET (mostly) for system calls and interrupts/IRET (mostly) for interrupt returns. SYSCALL and SYSRET are quite fast. interrupts and IRET are slow.
A VM guest needs to do a VM exit (which is quite a bit slower than even an interrupt, I believe) and then fix up a bunch of host state that doesn't get restored by the CPU. Then, to get back to guest mode, it needs to manually restore some guest state and do VMRESUME.
Regular user mode wins hands down.
To be fair, unikernels get to directly create page tables, which is potentially very useful. But, for the simpler applications, it's probably not.
(I more or less maintain the glue between x86 Linux user code and the kernel. I do, in fact, know exactly how this works.)
The number of calls probably wouldn't be the same, though. A process might make hundreds of system calls while a unikernel might make one hypercall to do the same work (because virtio has batching).
Anyway, I don't personally think reducing system call overhead is interesting but it seems to be one of the arguments unikernel people make.
Neither are most unikernels. Especially the weak points are file system and network handling.
Generally the security of VMs is enforced by hardware and improved by limited attack surface - few drivers to audit, limited communication APIs.
You can do the same with general purpose OS by cutting options.
I'm not talking about unikernels. I'm talking about the VMs that isolate them from each other. The VM isolation mechanism is considered secure enough to isolate malicious users, while the container isolation mechanism isn't (at least Linux-based containers).
There's a whole zoo of "little operating systems" out there that more or less have unikernel-like properties.
Some more closely meet the definition of a Unikernel, others are more like stripped down Linux, others are more exotic OS's that are nothing more than a network driver and disk driver in a virtual machine, such as Solo5.
I got Bootrino (see elsewhere) to boot all of these types of operating systems including embedded Linux (Yocto), Solo5, TinyCore, Alpine, and some other weird run-from-RAM OS configurations.
I got MirageOS running on all of the above, so unikernels can fit within other OSs or live on their own.
By their nature, unikernels are extremely well suited to running on top of a simple and well-defined interface. By extension, such interfaces are easy to audit and secure.
Why is this better than running as a normal user process? Look at the complexity inherent in securely sandboxing applications using existing interfaces -- the Linux system call interface amounts to hundreds of system calls, with different mutations for different architectures and many calls multiplexing even more operations (eg. ioctl()) the numbers grow even higher.
Unikernels give us a shot at redefining the process interface, while still being able to run on existing infrastructure (host OS or hypervisor). This means we can work toward a system where the application (unikernel) has least privilege by default.
With Solo5 [1] we're working towards defining such an interface. We have a way to go yet [2], and are still very much in the "early adopter who knows what a unikernel is" stage, but the possibilities are exciting, not only from the application security point of view.
How is this any different from running a process with a very short whitelist of system calls? Compare to the original linux seccomp, which only allowed read, write, exit and sigreturn.
The Linux kernel is a dumping-ground, kitchen-drain of all features (20 megaLoC with no end in sight) because of their inability to isolate concerns and provide fast IPC.
Is the obsession with avoiding memory copying really justified? I'd like to see some data. Is this really a bottleneck in modern systems? Is TLS a bottleneck at all for most work loads?
Memory bandwidth still matters, yes. Cache sizes are still not very big, and a copy uses more cache. Obviously you may have other bottlenecks first, but it matters once you are using 10Gb ethernet or faster, for example.
That's a good point. It's probably more a cache thing than a CPU cycles thing and that might not show up on a straightforward CPU profile.
What would happen if you used special instructions to try to implement a non-cache-polluting memcpy? Or is that even possible? It's been a while but I seem to think that modern CPUs have a variety of cache control instructions. Zero copy is great but it can be a PITA.
You have to use at least one cache line for memcpy. But you need more for pipelining the accesses probably to get good speed. Benchmarking memcpy though is complicated.
The smaller attack surface and the possibility to implement optimizations across boundaries (userspace vs kernelspace, for example) are the selling points.
I'm not buying into this myself as of yet but at least in theory this could lead to.an "application provably correct all the way down the stack".
If you compare the attack surface of a Linux user process that is very tightly seccomped to the attack surface of a whole guest VM (with all the awkward emulation needed), it's not at all clear to me that guests are better.
Better isolation and a cleaner interface. There's a huge hodgepodge of different ways user programs can communicate and interfere with each other, many of which are rarely used and don't make sense for most programs but have to be retained lest removing them break something.
Quite the opposite. The Unix userland <-> kernel and IPC interfaces are enormous: hundreds of system calls, often overlapping, a dozen different socket types, multiple different kinds of magic filesystem interfaces (some of which take complex datastructures in arbitrary unstandardized text formats)... Whereas the interface between a VM and its host is pretty small.
Sure, but the set you'd restrict to would look rather like the VM interfaces, only more awkward because it's had to be retrofitted on to what already exists, and often more permissive than it should be because a library assumes all syscalls are available (why would it not?)
The virtualized hardware interfaces also enormous. And more cumbersome to restrict than seccomp, and more cumbersome to use than syscalls.
I'm not sure I follow the logic in your harder-to-retrofit opinion. In unikernels the central idea is retrofitting the unikernel around the host interface and the application. It seems obvious to me that this would be more easier to develop and debug inside a standard process, than an emulation of bare iron, even if you would have to call it a different platform due to a radically smaller syscall interface.
> The virtualized hardware interfaces also enormous.
I don't see that they have to be? There's no reason for the host to offer e.g. a virtualized graphics card except to unikernels that specifically want to output graphics.
> In unikernels the central idea is retrofitting the unikernel around the host interface and the application.
I don't think I follow? The only part that's retrofitted is using an interface that was designed to host OSes to instead host an application, but it's a good fit because virtualized guests haven't been treated as trusted (particularly not in contexts like AWS), whereas for decades of unix history any local process was treated as more-or-less trusted.
> It seems obvious to me that this would be more easier to develop and debug inside a standard process, than an emulation of bare iron, even if you would have to call it a different platform due to a radically smaller syscall interface.
If we're talking about creating a new platform with a restrictive, strictly secured syscall interface, whether we talk about a hypervisor running unikernels or a kernel running processes is pretty much just terminology. I would think the actual interface specification would end up very similar to the current hypervisor/unikernel one.
The big advantage of keeping compatible with existing VMs is to provide a way to run legacy processes without compromising the security of new-style ones (and while making sure the incentives in terms of e.g. performance run in the right direction). If one component of your system needs to be run as a traditional unix process, that's fine - it gets its own VM in which it's running a traditional kernel and the actual process - but it can't interfere directly with your other components, and it pays for its own overheads.
I agree that VM interfaces don't have to be big, but they are by default just like the syscall one is. This argument was just to set the two at a similar starting point.
Historically Unix processes and VM guests have both been treated as untrusted on paper, but with not much scrutiny. There are frequent VM breakout vulnerabilities announced and there's wide agreement that this is a porous security boundary. The numbers are probably better for the VM interface, but it's in the same category.
Apparently we agree that in terms of exposed functionality, the end result is not going to be very different, if we restrict the VM interface vs use seccomp or similar.
A difference here is that there is already an easy and widely supported and understood system for this restriction for the process case. And processes are easier to debug, instrument, monitor and manage. And they don't require platform support for virtualization, which can be useful on eg embedded platforms, phone apps etc.
For the last point about running legacy processes, maybe we have a different understanding of what Unikernels are. If you have an unikernel application that uses a Rump kernel or MirageOS, you are not going to be able to run legacy processes in the Unikernel container in any case, there is not even going to be a kernel/userspace boundary. There is just one code image with everyting linked into it.
So the traditional VM interface is not going to help with the legacy processes.
If you were talking about running regular VMs for legacy apps alongside unikernel images, then that's of course valid, but I don't agree that this is an argument for using the VM interface for unikernel images.
> A difference here is that there is already an easy and widely supported and understood system for this restriction for the process case.
There is? I see a bunch of ad-hoc, retrofitted efforts, which seem to be constantly playing whack-a-mole in terms of what they forgot to restrict.
> And processes are easier to debug, instrument, monitor and manage.
Yes and no. The kernel/process boundary can make debugging and profiling much harder when you need to do so across it. With a lot of unikernels you can run the whole thing as a userspace process for development purposes and debug/profile without worrying about that. And these days we have a lot of good tooling for monitoring and managing VMs.
> If you were talking about running regular VMs for legacy apps alongside unikernel images, then that's of course valid, but I don't agree that this is an argument for using the VM interface for unikernel images.
That's what I meant. If you have a mixed deployment of legacy components and new-style components, that approach lets you realise the benefits quicker for the new-style pieces and ensure there's an incentive to move components into the new style. Whereas if you just run a bunch of processes, then no single component can benefit from isolation until you've ported everything.
seccomp does not imply a whack-a-mole type of effort: you can have a very small whitelist of syscalls, and further restrict their parameters.
The debugging would be similar with a unikernel run as a seccomp process: you could debug it as a single process. I believe the BSD rump kernel is already used like this for debugging purpouses.
If you want to mix legacy processes and unikernels in parallel, you would still run the legacy processes on a different VM in the seccomp case.
A question that constantly reoccurs for me is this: who does the scheduling of threads and/or processes in a unikernel?
I know unikernels are single process, but are they also intended to be single core? If not, without the kernel scheduler, what is providing that function to the unikernel? Is it just an optional module, say in the case of rumprun?
Consider that any complex language runtime (e.g. Erlang's BEAM, the JVM, etc.) has its own scheduler. If you convert such a runtime into a unikernel (such as in Erlang on Xen), the runtime scheduler is "the" scheduler.
Besides languages, though, plenty of complex applications have their own schedulers. Databases, for example. Postgres-as-a-unikernel would make a lot of sense, because it's already doing its own equivalent to everything that OSes do.
If your program is complex enough, it likely will already have an "optimized" form of internally-managed shared memory/message-passing multithreading (with core affinities et al) to allow it to allocate tasks to cores better than the OS can without the "insider knowledge" of what it's trying to accomplish. At that point, your program will end up with a scheduler "inside" whether you set out to build one or not.
On the other hand, if your program isn't that complex, then it's very likely you'll get better performance out of your code by just making each process into a single-core unikernel and then packing instances onto however many vCPUs the hypervisor host offers.
I don't know much about the other Runtimes that you mention, but correct me where I'm wrong:
In the case of the JVM, green threads were dropped a long time ago, and under the current paradigm, native threads are used (on all platforms?). So doesn't this need to be written into the JVM? Not impossible of course (or provided by the unikernel wrapper as it is in OSv).
Similarly with Databases, Oracle and Postgres both use a process per connection client/server model. So a unikernel for these would be impractical without rearchitecting those to run in that kind of environment.
I was initially very excited for Unikernels, but because of this question (and others), I've really started becoming less enamored by them. I'm sure there are many places where they can be put to use, but for most of the software that I'm familiar with, there are still a bunch of kernel services that are quite handy.
At what point of building these services into your unikernel/userspace application do you cross-over to basically building a new kernel. It really feels like the micro-kernel architecture would be a better fit in many of these cases. And yes, I understand that we can think of unikernels as VMs based micro-kernel services, but they have more isolation than traditional variations specifically allowing them to be used in AWS, etc. But still...
Most people consider unikernels to be single process without threads.
IncludeOS is rather liberal and has rudimentary multicore support. There is no preemption however so the "threads" will have to yield if there are more threads than cores. So more like fibers than threads, really.
The hypervisor typically doesn't care. So if you are using multiple cores in your application it will schedule and de-schedule your VM as per the regular rules.
IncludeOS is capable of booting on bare metal and we have some basic SMP tests passing. This is currently mostly of academic interest but if you don't mind having no pre-emption you can, once we improve our hardware support, have an application that runs on multiple physical cores. Perhaps this might be of interest to people with very strict latency requirements.
The whole point is there are many ways to do it and the application knows best.
The API specifics are probably different but it's just setting some registers and the the program counter on that CPU core. The code likely looks very similar to a context switch.
I wonder if functional programming might be something to implement with a "flock" of unikernels? I'm not even sure what I mean, but it seems like decomposing into unikernels might allow entirely new architectures. (Perhaps analogous to a VM allowing better use of hardware resources, unikernels might allow complete abstraction away from, and across, hardware??)
Aren't most of these developed using realtime kernels on platforms such as VxWorks ? (last time i looked into hardware dev was 10 years ago, so my knowledge might be outdated)
How so? In an IoT device the userspace process usually has access to whatever the device is actually doing, so which part is the kernel actually securing?
I'd expect unikernel devices to end up more secure: no shipping old Linux kernels full of vulnerabilities, and you're naturally guided towards using a safer programming language (OCaml).
It's the initial user interaction. Users usually expect appliances to be powered on and be running right the way. If it takes 30 seconds to start, the user is not sure whether it's not working or it's just initializing. These things don't have great visual feedback to start with.
I don't know, it's pretty unlikely at this point that anything will replace Linux as The Kernel. It's like replacing Google as the search engine.
On top of that users are currenlty moved away one additional abstraction layer from the kernel, to work with apps inside of containers (see Android, Kubernetes). The OS underneath becomes a static one-version-one-set-of-packages layer. That reduces the amount of people who can even decide to exchange a kernel for another, and these are mostly people who are rewarded for stability instead of experiments. Who would still like to write Android apps, if Android would start to crash more often or change its API drastically?
This is a battle that can't be won. Let's move on to one that is still undecided, e.g. which container engine will finally win. Although Docker seems to be the most likely favorite already at this point, I'd still like to see if nspawn will do a systemd move and just replace the alternatives.
>I don't know, it's pretty unlikely at this point that anything will replace Linux as The Kernel
Depending on the domain (embedded, IoT, industrial, medical, etc), tons of other kernels are used (and prevail). We're not necessarily talking web services here.
>This is a battle that can't be won. Let's move on to one that is still undecided, e.g. which container engine will finally win.
Yes there are always special cases that use special tools. But add all computers in data centers + all smart phones and you may have a factor bigger than 1000:1. For the broad mass of people it's totally irrelevant that there is an edge case that makes power use of special kernels.
And no the container war is not a totally different concern. That's the current main concern which influences most people and how software will be administrated (and therefore developed) in the next 20 years.
>And no the container war is not a totally different concern. That's the current main concern which influences most people and how software will be administrated (and therefore developed) in the next 20 years.
I'm not really sure. I think containers (if we're talking of the Docker type) is a hype.
But in any case, totally different concern doesn't preclude it being important. Just irrelevant to unikernels.
Unikernels are a great technology and very much ready for prime time, but unless cloud vendors provide the millisecond boot/teardown/pricing, Unikernels will remain nothing more than a niche special interest technology.
All the technology is in place for Unikernels to take off once the cloud vendors get behind them.
I wrote Bootrino specifically for the purpose of booting Unikernels (and a whole host of other exotic tiny operating systems) on the major clouds and it works fine - you can see a demo here: https://www.youtube.com/watch?v=zJhxmVlR46c (Bootrino not released to public as yet).
However, the real draw for Unikernels is short lifetime function as a service type applications.