4 ms·

So, a niche technology for a handful of HFT firms, betting platforms and hyper-scale cloud vendors. Those already use non-mainstream tech (eg LMAX disruptor) to

So, a niche technology for a handful of HFT firms, betting platforms and hyper-scale cloud vendors. Those already use non-mainstream tech (eg LMAX disruptor) to achieve max performance. This is all nice and good, but the Unikernel guys claim since 20 years its the next big revolutionary thing. In the real world, the evolutionary approach using containers has turned out to solve the problems most people care about. Don’t get me wrong, this is fascinating stuff. But there is a difference between „changes mainstream computing“ and „cool tech to shave off another millisecond of latency“.

throwaway894345 6y ago
Unikernels could also be the next phase of cloud orchestration technologies. They would be truly lightweight VMs, and obviate the need for containers (collapse the VM orchestration and container orchestration layers into a single orchestration layer). This would offer better security and better performance without impacting developer/operator friendliness. And a side note about improved performance, in the cloud space, being able to boot in ten ms means you can start a VM in the scope of a single request, which means you can scale up dynamically without keeping a bunch of VMs running idle in the background just in case your traffic spikes. This is real, significant cost savings for cloud providers and customers.
- rbanffy 6y ago
  Debugging a single-executable container is quite unpleasant. I assume debugging unikernels or thin VMs (with a kernel and a single program) would be a similar experience.
  - zarkov99 6y ago
    Could you not do all your debugging and development on a normal host and only deploy on a unikernel when you are stable? There is already a divide between development and production with debug and release builds the later of which are a massive pain to debug.
    - rbanffy 6y ago
      > debugging and development on a normal host and only deploy on a unikernel when you are stable? Sure! And, still, when you deploy, it fails. At least one of your assumptions that led to your conclusion that your development/testing environment is equivalent to the production one are flawed. Find which ones.
      - zarkov99 6y ago
        That is not a new problem. To some extent it already happens with debug and release builds, with running on a VM vs a real host, running on a different distribution than the one you developed in, etc. If the performance gains are significant in some domains that would be more than enough to pay for the extra pain.
        rbanffy 6y ago
        > running on a VM vs a real host, running on a different distribution than the one you developed in Except that, in those cases, you can connect to the server and spin up a shell and actually get an idea, from the file system, from logs or from any of the many ways you have to inspect a system. All that you'll need to provide to your unikernel.
        throwaway894345 6y ago
        Not much of a problem in theory; just include the relevant library.
  - MrBuddyCasino 6y ago
    Yep dev tooling matters. Containers are already annoying, but Unikernels are a different universe, and it is not going to be pleasant.
    - microcolonel 6y ago
      Depends on what is meant by debugging. If you're talking about running a debugger on your program, you can attach GDB to your VM any time you want.
  - throwaway894345 6y ago
    You can compile your debugging utilities into a unikernel for prod or debug builds (or not at all) depending on your development preferences, performance requirements, and security requirements.
- MrBuddyCasino 6y ago
  > being able to boot in ten ms means you can start a VM in the scope of a single request That is actually a good point. Though this is also achievable with WebAssembly (see CloudFlare), but Unikernels could do it more generally I suppose. On the other hand, AWS Lambda has yet to drive classic EC2 to extinction.
  - throwaway894345 6y ago
    Yeah, webassembly workers is an exciting idea as well. Unikernels is similar, but it removes a couple of layers of abstraction (another way to cut layers would be to implement a low-level hypervisor that runs WASM). As for lambda not driving EC2 to extinction, these are different technologies for different use cases, and lambda is a relatively new technology—it takes a long time for big companies to change their ways, and it rarely makes sense to port a stable, legacy EC2 code base to functions. There are still plenty of mainframes kicking around for the same reasons.

throwaway894345 6y ago

Unikernels could also be the next phase of cloud orchestration technologies. They would be truly lightweight VMs, and obviate the need for containers (collapse the VM orchestration and container orchestration layers into a single orchestration layer). This would offer better security and better performance without impacting developer/operator friendliness. And a side note about improved performance, in the cloud space, being able to boot in ten ms means you can start a VM in the scope of a single request, which means you can scale up dynamically without keeping a bunch of VMs running idle in the background just in case your traffic spikes. This is real, significant cost savings for cloud providers and customers.

rbanffy 6y ago
Debugging a single-executable container is quite unpleasant. I assume debugging unikernels or thin VMs (with a kernel and a single program) would be a similar experience.
- zarkov99 6y ago
  Could you not do all your debugging and development on a normal host and only deploy on a unikernel when you are stable? There is already a divide between development and production with debug and release builds the later of which are a massive pain to debug.
  - rbanffy 6y ago
    > debugging and development on a normal host and only deploy on a unikernel when you are stable? Sure! And, still, when you deploy, it fails. At least one of your assumptions that led to your conclusion that your development/testing environment is equivalent to the production one are flawed. Find which ones.
    - zarkov99 6y ago
      That is not a new problem. To some extent it already happens with debug and release builds, with running on a VM vs a real host, running on a different distribution than the one you developed in, etc. If the performance gains are significant in some domains that would be more than enough to pay for the extra pain.
      - rbanffy 6y ago
        > running on a VM vs a real host, running on a different distribution than the one you developed in Except that, in those cases, you can connect to the server and spin up a shell and actually get an idea, from the file system, from logs or from any of the many ways you have to inspect a system. All that you'll need to provide to your unikernel.
        throwaway894345 6y ago
        Not much of a problem in theory; just include the relevant library.
- MrBuddyCasino 6y ago
  Yep dev tooling matters. Containers are already annoying, but Unikernels are a different universe, and it is not going to be pleasant.
  - microcolonel 6y ago
    Depends on what is meant by debugging. If you're talking about running a debugger on your program, you can attach GDB to your VM any time you want.
- throwaway894345 6y ago
  You can compile your debugging utilities into a unikernel for prod or debug builds (or not at all) depending on your development preferences, performance requirements, and security requirements.
MrBuddyCasino 6y ago
> being able to boot in ten ms means you can start a VM in the scope of a single request That is actually a good point. Though this is also achievable with WebAssembly (see CloudFlare), but Unikernels could do it more generally I suppose. On the other hand, AWS Lambda has yet to drive classic EC2 to extinction.
- throwaway894345 6y ago
  Yeah, webassembly workers is an exciting idea as well. Unikernels is similar, but it removes a couple of layers of abstraction (another way to cut layers would be to implement a low-level hypervisor that runs WASM). As for lambda not driving EC2 to extinction, these are different technologies for different use cases, and lambda is a relatively new technology—it takes a long time for big companies to change their ways, and it rarely makes sense to port a stable, legacy EC2 code base to functions. There are still plenty of mainframes kicking around for the same reasons.