4 ms·

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

by 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.

by c0l0 7y ago

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.