Site is running on such a VM as well, press escape for a console to see stats.
Here is an example output from running their demo:
300 sec : is how long it takes to launch a Linux instance to availability on Amazon EC2.
50 sec : is the time between power on and the lock screen for an Android phone.
0.4 sec : ago is when we received your request. Within this time we managed to create a new Xen instance, boot it, and run the application that rendered the page you are viewing. By the time you are done reading this, the instance will be gone.
Magnus' version builds a static set of unikernels whose total resource usage is known ahead of time, and boots them based on DNS lookups as necessary. Because there is a race between a DNS response, the first TCP SYN from the client, and the VM booting up to receive it, there is a helper unikernel called "Synjitsu" which terminates TCP connections and replays them to the MirageOS unikernel as soon as it boots up. This is very easy due to the OCaml TCP/IP stack in Synjitsu sharing its state via serialising it into an s-expression. More gory details in http://anil.recoil.org/papers/2015-nsdi-jitsu.pdf
Now, imagine a version of Synjitsu that did this handover with TLS connections rather than just TCP. The recipient unikernel wouldn't ever even have to know the private key, just the ephemeral session key...
Would these fine-grained unikernels also run well on KVM, VMware ESXi, Hyper-V, or bhyve (FreeBSD's new VMM)? Or is Xen uniquely suited to this kind of thing?
Indeed. I didn't realise that Docker/Container folks had ever said VMs were too heavyweight. Is this linked anywhere?
> "Would these fine-grained unikernels also run well on KVM, VMware ESXi, Hyper-V, or bhyve (FreeBSD's new VMM)?"
We've been asked this before and for KVM at least, it just boils down to someone suitably motivated to write the boot and VirtIO code [1, 2]. If anyone's interested in this, we'd love to hear about it !
I know that's what DabbleDB was doing back then (in Squeak Smalltalk, each of their users has a smalltalk VM serving them). Is there anyone else doing anything similar nowadays?
Here's the camera ready paper that we'll be presenting at USENIX NSDI in May: http://anil.recoil.org/papers/2015-nsdi-jitsu.pdf
There's a lot more besides just the spawning to build a robust SaaS of course, but you can see the direction we're heading in...
Disclaimer: I worked on Cloud Foundry.
s/languages/frameworks, and I agree. One step at a time -- this work is a foundational block that we're building on, not the ultimate solution.
It looks like the place to make the change would be in Diego in the Executor component, which currently implements behaviour in terms of containers (using Linux-Garden as the container system).
So long as you can conceptually fit into the Receptor Actions API it looks as though unikernels would be a plausible addition to Executor. Once you have that, you can either wire into Lattice or a full Cloud Foundry installation as a first-class citizen.
Disclaimer: I'm not as familiar with Diego as other CFers are, so it's possible I'm just making stuff up.
In any case, we started the Lattice effort last year to make it easier for people to play with Diego without having to stand up a whole Cloud Foundry installation.
My only Lattice-related claim to fame is not knowing what is was: https://github.com/pivotal-cf-experimental/lattice-app/issue...
It was published at SYSTOR last year (2014).
This kind of fast experimentation is going to lead to some really cool things happening with unikernels.
Using that you can store a whole filesystem at the URL instead of one file, and you also get synchronization mechanisms built in, so your endpoints can communicate with each other in a structured way that you control.. vs the undefined communication you will get between VM's if you try this with the VM architecture.
I probably got it wrong but I'd love to hear a more expert opinion on why/why not this could be used for security..