5 ms·

Autonomous Rust Unikernels in Google Cloud

121 points by eyberg 7y ago

utopian3 7y ago
What does autonomous mean in this context?
- eyberg 7y ago
  That it can recover by itself. It's a bit more than just 'auto-restart' (as mentioned in the article) since it's an entire vm that is restarting versus a process and it's not the same as restarting a linux vm.
  - perlpimp 7y ago
    so this is LXC based or is it something else? trying to figure this out as well.
    - perlpimp 7y ago
      https://ma.ttias.be/what-is-a-unikernel/ https://ma.ttias.be/what-is-a-unikernel/ found this.
    - eyberg 7y ago
      Nope, no linux. https://github.com/nanovms/nanos https://github.com/nanovms/nanos is a new kernel designed to run a single (linux) application as a virtual machine.
DSingularity 7y ago
A new memory layout on each request? That will be expensive.
- llarsson 7y ago
  Very. Back here in reality, we care about performance so much that we do not even close TCP connections needlessly. So we can support thousands of requests per second, not just... one per three seconds? I can find few better way of discrediting unikernels than to claim this as their killer feature. (The actual killer feature being their ability to reduce attack surface substantially by simply having fewer syscalls that can be abused.)
  - eyberg 7y ago
    I'm not advocating every application should do this as evidenced that this is a toggable switch that's off by default and even by itself doesn't actually have this particular feature (I was forcibly stopping the app through the inline instructions.). Just that it can be done is a capability that some people are very interested in. There is a category of security products called 'moving target defense' that this capability fits into. As for the syscall/security argument I find that to be one of the weakest security arguments for unikernels. Fewer syscalls unfortunately leads to a much smaller set of applications that can be ran. Even trivial hello world style of apps can use north of 30-40 different types of syscalls. Not saying you should keep adding more but spending time trying to reduce what's there is kind of a non-starter if you want adoption.
    - orf 7y ago
      > Even trivial hello world style of apps can use north of 30-40 different types of syscalls I'd wager a lot of those are irrelevant in a unikernel world. Some of those might be dealing with ttys, or setting terminal attributes, or other needless things.
      - eyberg 7y ago
        you're absolutely correct - in cases like that they become nops, however, if you don't have at least stubs you can't load unmodified software which imo is a imperative for any type of mass adoption Drew DeVault had a recent blogpost on this very subject -> https://drewdevault.com/2020/01/04/Slow.html https://drewdevault.com/2020/01/04/Slow.html however, when we were adding support for various language runtimes I was surprised at how much (ab)use there was where certain calls were used in a very very different manner than what was intended - for instance one might wonder why we have limited pipe support if we don't have the notion of multiple processes - cause ruby uses it to communicate from the main vm thread to the user thread - it's little gems like this that you simply won't know until you try to support it then there's the cases where you might support one type of syscall but there's another syscall exactly like it except it has one additional argument
rvz 7y ago
> Being able to reboot not just an application but an entire server in seconds in response to an attack is a killer feature of unikernels. Rebooting an entire server "in seconds" sounds costly here. Maybe if it was more about some secure service being at risk of attack with backup Unikernels, this would make sense. 1-5 unikernels running on high load? The risk of unavailability is greater. I'd accept this if it were a nanosecond or picosecond reboot. Seconds is too slow.
- eyberg 7y ago
  I didn't write Google Cloud but if you had your own server 5ms and even lower have been reported by OSv && NEC. http://cnp.neclab.eu/projects/lightvm/lightvm.pdf http://cnp.neclab.eu/projects/lightvm/lightvm.pdf Nano/Pico is obviously unrealistic. :)
- monocasa 7y ago
  Picosecond? Each clock tick at 3GHZ is hundreds of picoseconds.
pron 7y ago
Can you compare nanovms to osv.io?
- eyberg 7y ago
  NanoVMs is the company while Nanos is the kernel. I respect the developers at ScyllaDB (formerly Cloudius Systems) who created OSv quite a lot and find them very talented. There are some fairly major technical differences on implementation that stem from both a different time period and (time/money) resource constraints, however, yes the end goals are fairly similar. I'd say it's still a bit early to try and compare the two technically though since we have many architectural projects on our roadmap that are not yet in. I will say from a product/company standpoint we have paid kernel engineers working on this currently and some of our customers are extremely large organizations. I know this is probably not the answer you were looking for but it's just kinda early to compare.
sudapy1980 7y ago
It's a rust program running in a custom kernel not a unikernal written in rust. Not sure how re-start qualify as autonomous. Looking at the source it does preserve the syscall instruction and addresses space separation so from a purist perspective it cannot qualify as a unikernal.

121 points by eyberg 7y ago

utopian3 7y ago

What does autonomous mean in this context?

eyberg 7y ago
That it can recover by itself. It's a bit more than just 'auto-restart' (as mentioned in the article) since it's an entire vm that is restarting versus a process and it's not the same as restarting a linux vm.
- perlpimp 7y ago
  so this is LXC based or is it something else? trying to figure this out as well.
  - perlpimp 7y ago
    https://ma.ttias.be/what-is-a-unikernel/ https://ma.ttias.be/what-is-a-unikernel/ found this.
  - eyberg 7y ago
    Nope, no linux. https://github.com/nanovms/nanos https://github.com/nanovms/nanos is a new kernel designed to run a single (linux) application as a virtual machine.

DSingularity 7y ago

A new memory layout on each request? That will be expensive.

llarsson 7y ago
Very. Back here in reality, we care about performance so much that we do not even close TCP connections needlessly. So we can support thousands of requests per second, not just... one per three seconds? I can find few better way of discrediting unikernels than to claim this as their killer feature. (The actual killer feature being their ability to reduce attack surface substantially by simply having fewer syscalls that can be abused.)
- eyberg 7y ago
  I'm not advocating every application should do this as evidenced that this is a toggable switch that's off by default and even by itself doesn't actually have this particular feature (I was forcibly stopping the app through the inline instructions.). Just that it can be done is a capability that some people are very interested in. There is a category of security products called 'moving target defense' that this capability fits into. As for the syscall/security argument I find that to be one of the weakest security arguments for unikernels. Fewer syscalls unfortunately leads to a much smaller set of applications that can be ran. Even trivial hello world style of apps can use north of 30-40 different types of syscalls. Not saying you should keep adding more but spending time trying to reduce what's there is kind of a non-starter if you want adoption.
  - orf 7y ago
    > Even trivial hello world style of apps can use north of 30-40 different types of syscalls I'd wager a lot of those are irrelevant in a unikernel world. Some of those might be dealing with ttys, or setting terminal attributes, or other needless things.
    - eyberg 7y ago
      you're absolutely correct - in cases like that they become nops, however, if you don't have at least stubs you can't load unmodified software which imo is a imperative for any type of mass adoption Drew DeVault had a recent blogpost on this very subject -> https://drewdevault.com/2020/01/04/Slow.html https://drewdevault.com/2020/01/04/Slow.html however, when we were adding support for various language runtimes I was surprised at how much (ab)use there was where certain calls were used in a very very different manner than what was intended - for instance one might wonder why we have limited pipe support if we don't have the notion of multiple processes - cause ruby uses it to communicate from the main vm thread to the user thread - it's little gems like this that you simply won't know until you try to support it then there's the cases where you might support one type of syscall but there's another syscall exactly like it except it has one additional argument

rvz 7y ago

> Being able to reboot not just an application but an entire server in seconds in response to an attack is a killer feature of unikernels. Rebooting an entire server "in seconds" sounds costly here. Maybe if it was more about some secure service being at risk of attack with backup Unikernels, this would make sense. 1-5 unikernels running on high load? The risk of unavailability is greater. I'd accept this if it were a nanosecond or picosecond reboot. Seconds is too slow.

eyberg 7y ago
I didn't write Google Cloud but if you had your own server 5ms and even lower have been reported by OSv && NEC. http://cnp.neclab.eu/projects/lightvm/lightvm.pdf http://cnp.neclab.eu/projects/lightvm/lightvm.pdf Nano/Pico is obviously unrealistic. :)
monocasa 7y ago
Picosecond? Each clock tick at 3GHZ is hundreds of picoseconds.

pron 7y ago

Can you compare nanovms to osv.io?

eyberg 7y ago
NanoVMs is the company while Nanos is the kernel. I respect the developers at ScyllaDB (formerly Cloudius Systems) who created OSv quite a lot and find them very talented. There are some fairly major technical differences on implementation that stem from both a different time period and (time/money) resource constraints, however, yes the end goals are fairly similar. I'd say it's still a bit early to try and compare the two technically though since we have many architectural projects on our roadmap that are not yet in. I will say from a product/company standpoint we have paid kernel engineers working on this currently and some of our customers are extremely large organizations. I know this is probably not the answer you were looking for but it's just kinda early to compare.

sudapy1980 7y ago

It's a rust program running in a custom kernel not a unikernal written in rust. Not sure how re-start qualify as autonomous. Looking at the source it does preserve the syscall instruction and addresses space separation so from a purist perspective it cannot qualify as a unikernal.