7 ms·

> Unikernels have demonstrated enormous advantages over Linux in many important domains, causing some to propose that the days of Linux's dominance may be comin

by rapsey 7y ago

> Unikernels have demonstrated enormous advantages over Linux in many important domains, causing some to propose that the days of Linux's dominance may be coming to an end. Where are unikernels widely used?

ailideex 7y ago
research papers I would guess.
- pjmlp 7y ago
  And stuff like SQL Server for Linux or the original WSL implementation, via picoprocesses. Or the Docker TCP/IP stack on macOS, using parts of MirageOS.
c0l0 7y ago
I don't think that this statement describes the reality we live in. To me, unikernels feel quite a bit like statically linked server binaries running under an unprivileged UID - but you're choosing not to trust Linux' (or any other kernel's) user separation facilities, but your hypervisor's domU separation facilities instead. In exchange, you lose virtually all of your existing OS's amazing debugging and performance analysis/tuning tools. It's not a tradeoff I'd readily consider.
- pjmlp 7y ago
  Except that those amazing debugging capabilities are also possible, as anyone that used Erlang, Java or .NET debugging capabilities in production is aware of.
  - majewsky 7y ago
    Great, now I have to learn a new set of debugging capabilities for every language in my heterogenous stack.
    - kingraoul3 7y ago
      Haven't you heard? Devs aren't going to need us any more. They've been telling us that since the 70's, at least!
    - pjmlp 7y ago
      Or you, just get to used to heterogeneous monitoring tools like DataDog and Prometheus.
      - majewsky 7y ago
        Prometheus is great, but it won't tell me why that container gets "no route to host" when taking to that service. That's when I need a shell for running traceroute, tcpdump etc.
        pjmlp 7y ago
        That was just a possible example. If you want a shell, that is what stuff like JMX, or server side REPLs are for. "Lisp at NASA: using a REPL to debug Deep Space 1 while it was 100 million miles away" http://www.flownet.com/gat/jpl-lisp.html http://www.flownet.com/gat/jpl-lisp.html
    - seqastian 7y ago
      change? hate it.
- nutjob2 7y ago
  Unikernels also run on bare metal, so it's not about swapping one sort of protection for another. Besides the differences in protection and separate processes, unikernels can do anything an OS can do. Some unikernels will run application software with no changes (but obviously things like fork don't work anymore). The point (for me at least) is discarding features that you don't need in return for performance and simplicity gains. Those gains are not insubstantial when you're scaling your system and you don't want to spend your money on admin staff.
- wwarner 7y ago
  True, it's a different picture. It's about how to create a really efficient computing mesh. If unikernels are faster (they start faster, then they run faster), and simpler, and you offload security and topology to kubernetes (or some other orchestration system), then you have a superior system, both in terms of performance and in terms of control.
  - ori_b 7y ago
    If you run under a vm, your competition is a process, not an OS. Your unikernel is effectively a process with a funny syscall ABI.
  - edwintorok 7y ago
    When I first read about unikernels I thought its a great way to remove a layer forced upon you by cloud providers. Most public clouds run some form of hypervisor, on top of which you run your VM and applications. I only want to run my application, and I don't get to choose to remove the hypervisor, thus I can only remove the kernel: a unikernel is like running an application on a hypervisor: your hypervisor is your "OS kernel" and your unikernel is your application ... and we gained back what we lost compared to a bare-metal deployment. That is a simplified view, and there are other advantages as well: you probably don't need to exit to your hypervisor quite as often as you do with syscalls, so you benefit from reduced overhead. One disadvantage is that memory allocation is almost static (unless you do ballooning which is tricky to get right), so you "waste" some memory compared to a bare-metal deployment where unused memory can be used for the page cache instead.
- mirceal 7y ago
  i think this kindof misses the mark. A unikernel is both the kernel (just the things you need) + app together. It’s build for one thing: whatever the app is doing. Tooling/Perf/etc is not needed when running (do you really want to debug in production) but tooling can be used in the process of development. Why consider unikernels? 1) they’re stupid fast. You have only the things you need (booting in nanoseconds? yepp) 2) small attack surface (because you only have your app that’s the only attack surface. you don’t have cruft that build up in you os/kernel over years) 3) light resource usage (you could run thousands of these on the same physical machine) 4) true isolation via the hypervisor definitely worth keeping an eye on the developments in this space
  - imbriaco 7y ago
    > Tooling/Perf/etc is not needed when running (do you really want to debug in production) but tooling can be used in the process of development. Whether or not you want to debug in production, reality often means that you will see things in a live environment that you will not see in other environments. Unikernels are very interesting and have a number of compelling attributes, but let's not pretend that the current state of available tooling for troubleshooting, instrumentation, and general debugging isn't a challenge.
    - mirceal 7y ago
      hah. they're a new technology/approach. of course there are going to be challenges.
    - weberc2 7y ago
      You're moving the goal posts and invoking a straw man. No one is advocating for "pretending", and the anti-unikernel argument is that the inherent cost of unikernels in general is the loss of kernel debugging tools; not simply that "right now the unikernel debugging experience is subpar".
      - convolvatron 7y ago
        in general right now, running on a full-featured monolithic kernel, the debugging experience is really pretty bad. especially in the target environment of horizontal clustered services or lots of little micro services. so I actually believe there is an opportunity here to focus on the important pieces (network messages, control flow tracing, memory footprints, etc) after ejecting a huge amount of irrelevant stuff
- CameronNemo 7y ago
  You still retain all of the hypervisor monitoring and tuning tools. And you can tune the unikernel using different build options. Debugging is probably not as fleshed out, but it does not seem to be an impossible task.
yk 7y ago
GNU/Hurd on the desktop.
- b2ccb2 7y ago
  GNU Hurd is a microkernel, not an unikernel
rwmj 7y ago
To be fair that's not exactly what the paper says. It says that unikernels have demonstrated "enormous" advantages (a bit of an exaggeration), but they are not widely used right now and no one is claiming that.
- panpanna 7y ago
  I think it's fair to say that in certain scenarios they are very useful. The original unikernel paper used a streaming media device as an example and the numbers they provided were really good.
pizzazzaro 7y ago
Why would you do such a thing? Creating masses of crippled, non-general operating systems out of linux?! For the actually unheardof performance. Basically, you've taken the whole /sbin/init link out of the OS init chain, and replaced it with... A single binary you may remember. To do this took a little extra work. Your glibc and any other dependency ended up in kernel space. Single-use virtual machines obviously have the biggest boost, but other uses exist. Your kerberos-daemon isolated into its own vm on the network. Someone's gotta serve network filesystems. Apache servers for various websites you may host - the possibilities are endless. The processor itself has a Massive timesink for isolating kernel-space from user-space (even root is just another user at this level, I'm afraid). Even Server-side admins have simply gotten used to it - every application, server, program Ever runs on that user-space. So you have a bunch of single use VMs... and that much "context-switching" between virtual-drivers and memory allocation on one side, and the actual server the vm is for on the other. Now these VMs are running on an OS's hypervisor with the same context-switching performance problem! So, we package each vm as a unikernel - shove each virtualized server into the kernel. We avoid that context switching. Build that kernel lean enough, and sometimes the unikernel VM can perform almost at baremetal speeds. What if we did the same for the Host OS - built a hypervisor Unikernel to delegate hardware and nothing else? zomg folks are squeeing with excitement about a new way to frame building a lean system... But it gets us compiling in-house again instead of using COTS (commercial, off-the-shelf software). Got an old Gentoo-user hanging around that can debug kernel code, harden the kernel against attack, and compile it all lean? That guy is who we're gonna need to figure out what goes wrong with any of this. Because Murphy's law is unreliably unreliable, yet ultimately absolute.

by rapsey 7y ago

ailideex 7y ago

research papers I would guess.

pjmlp 7y ago
And stuff like SQL Server for Linux or the original WSL implementation, via picoprocesses. Or the Docker TCP/IP stack on macOS, using parts of MirageOS.

c0l0 7y ago

I don't think that this statement describes the reality we live in. To me, unikernels feel quite a bit like statically linked server binaries running under an unprivileged UID - but you're choosing not to trust Linux' (or any other kernel's) user separation facilities, but your hypervisor's domU separation facilities instead. In exchange, you lose virtually all of your existing OS's amazing debugging and performance analysis/tuning tools. It's not a tradeoff I'd readily consider.

pjmlp 7y ago
Except that those amazing debugging capabilities are also possible, as anyone that used Erlang, Java or .NET debugging capabilities in production is aware of.
- majewsky 7y ago
  Great, now I have to learn a new set of debugging capabilities for every language in my heterogenous stack.
  - kingraoul3 7y ago
    Haven't you heard? Devs aren't going to need us any more. They've been telling us that since the 70's, at least!
  - pjmlp 7y ago
    Or you, just get to used to heterogeneous monitoring tools like DataDog and Prometheus.
    - majewsky 7y ago
      Prometheus is great, but it won't tell me why that container gets "no route to host" when taking to that service. That's when I need a shell for running traceroute, tcpdump etc.
      - pjmlp 7y ago
        That was just a possible example. If you want a shell, that is what stuff like JMX, or server side REPLs are for. "Lisp at NASA: using a REPL to debug Deep Space 1 while it was 100 million miles away" http://www.flownet.com/gat/jpl-lisp.html http://www.flownet.com/gat/jpl-lisp.html
  - seqastian 7y ago
    change? hate it.
nutjob2 7y ago
Unikernels also run on bare metal, so it's not about swapping one sort of protection for another. Besides the differences in protection and separate processes, unikernels can do anything an OS can do. Some unikernels will run application software with no changes (but obviously things like fork don't work anymore). The point (for me at least) is discarding features that you don't need in return for performance and simplicity gains. Those gains are not insubstantial when you're scaling your system and you don't want to spend your money on admin staff.
wwarner 7y ago
True, it's a different picture. It's about how to create a really efficient computing mesh. If unikernels are faster (they start faster, then they run faster), and simpler, and you offload security and topology to kubernetes (or some other orchestration system), then you have a superior system, both in terms of performance and in terms of control.
- ori_b 7y ago
  If you run under a vm, your competition is a process, not an OS. Your unikernel is effectively a process with a funny syscall ABI.
- edwintorok 7y ago
  When I first read about unikernels I thought its a great way to remove a layer forced upon you by cloud providers. Most public clouds run some form of hypervisor, on top of which you run your VM and applications. I only want to run my application, and I don't get to choose to remove the hypervisor, thus I can only remove the kernel: a unikernel is like running an application on a hypervisor: your hypervisor is your "OS kernel" and your unikernel is your application ... and we gained back what we lost compared to a bare-metal deployment. That is a simplified view, and there are other advantages as well: you probably don't need to exit to your hypervisor quite as often as you do with syscalls, so you benefit from reduced overhead. One disadvantage is that memory allocation is almost static (unless you do ballooning which is tricky to get right), so you "waste" some memory compared to a bare-metal deployment where unused memory can be used for the page cache instead.
mirceal 7y ago
i think this kindof misses the mark. A unikernel is both the kernel (just the things you need) + app together. It’s build for one thing: whatever the app is doing. Tooling/Perf/etc is not needed when running (do you really want to debug in production) but tooling can be used in the process of development. Why consider unikernels? 1) they’re stupid fast. You have only the things you need (booting in nanoseconds? yepp) 2) small attack surface (because you only have your app that’s the only attack surface. you don’t have cruft that build up in you os/kernel over years) 3) light resource usage (you could run thousands of these on the same physical machine) 4) true isolation via the hypervisor definitely worth keeping an eye on the developments in this space
- imbriaco 7y ago
  > Tooling/Perf/etc is not needed when running (do you really want to debug in production) but tooling can be used in the process of development. Whether or not you want to debug in production, reality often means that you will see things in a live environment that you will not see in other environments. Unikernels are very interesting and have a number of compelling attributes, but let's not pretend that the current state of available tooling for troubleshooting, instrumentation, and general debugging isn't a challenge.
  - mirceal 7y ago
    hah. they're a new technology/approach. of course there are going to be challenges.
  - weberc2 7y ago
    You're moving the goal posts and invoking a straw man. No one is advocating for "pretending", and the anti-unikernel argument is that the inherent cost of unikernels in general is the loss of kernel debugging tools; not simply that "right now the unikernel debugging experience is subpar".
    - convolvatron 7y ago
      in general right now, running on a full-featured monolithic kernel, the debugging experience is really pretty bad. especially in the target environment of horizontal clustered services or lots of little micro services. so I actually believe there is an opportunity here to focus on the important pieces (network messages, control flow tracing, memory footprints, etc) after ejecting a huge amount of irrelevant stuff
CameronNemo 7y ago
You still retain all of the hypervisor monitoring and tuning tools. And you can tune the unikernel using different build options. Debugging is probably not as fleshed out, but it does not seem to be an impossible task.

yk 7y ago

GNU/Hurd on the desktop.

b2ccb2 7y ago
GNU Hurd is a microkernel, not an unikernel

rwmj 7y ago

To be fair that's not exactly what the paper says. It says that unikernels have demonstrated "enormous" advantages (a bit of an exaggeration), but they are not widely used right now and no one is claiming that.

panpanna 7y ago
I think it's fair to say that in certain scenarios they are very useful. The original unikernel paper used a streaming media device as an example and the numbers they provided were really good.

pizzazzaro 7y ago

Why would you do such a thing? Creating masses of crippled, non-general operating systems out of linux?! For the actually unheardof performance. Basically, you've taken the whole /sbin/init link out of the OS init chain, and replaced it with... A single binary you may remember. To do this took a little extra work. Your glibc and any other dependency ended up in kernel space. Single-use virtual machines obviously have the biggest boost, but other uses exist. Your kerberos-daemon isolated into its own vm on the network. Someone's gotta serve network filesystems. Apache servers for various websites you may host - the possibilities are endless. The processor itself has a Massive timesink for isolating kernel-space from user-space (even root is just another user at this level, I'm afraid). Even Server-side admins have simply gotten used to it - every application, server, program Ever runs on that user-space. So you have a bunch of single use VMs... and that much "context-switching" between virtual-drivers and memory allocation on one side, and the actual server the vm is for on the other. Now these VMs are running on an OS's hypervisor with the same context-switching performance problem! So, we package each vm as a unikernel - shove each virtualized server into the kernel. We avoid that context switching. Build that kernel lean enough, and sometimes the unikernel VM can perform almost at baremetal speeds. What if we did the same for the Host OS - built a hypervisor Unikernel to delegate hardware and nothing else? zomg folks are squeeing with excitement about a new way to frame building a lean system... But it gets us compiling in-house again instead of using COTS (commercial, off-the-shelf software). Got an old Gentoo-user hanging around that can debug kernel code, harden the kernel against attack, and compile it all lean? That guy is who we're gonna need to figure out what goes wrong with any of this. Because Murphy's law is unreliably unreliable, yet ultimately absolute.