Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A unikernel experiment: A VM for every URL

skjegstad.com

Post reply on HN
Print view View original

11–20 of 34 posts

Re: A unikernel experiment: A VM for every URL

#11

Post by avsm »

NhanH wrote: post #10

I've always thought that something really cool could be done with unikernel for SaaS: you let each of your customer have a VM on their own, spinning the unikernel up when the requests came in, and let it process any request come in, after a while, if the specific user stop requesting then you kill the VM. There seems to be a lot of benefits from that: single user authentication, horizontally scaling is simple ("verti…

That sort of design is what motivated Magnus' post that has been linked here. We've been laying the uniSaaS groundwork with a new Xen toolstack daemon called Jitsu ("Just in Time Summoning of Unikernels").

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

Re: A unikernel experiment: A VM for every URL

#12

Post by rdtsc »

Already exists for Erlang. Here is a demo:

http://erlangonxen.org/

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.

---

Re: A unikernel experiment: A VM for every URL

#14

Post by jacques_chester »

NhanH wrote: post #10

I've always thought that something really cool could be done with unikernel for SaaS: you let each of your customer have a VM on their own, spinning the unikernel up when the requests came in, and let it process any request come in, after a while, if the specific user stop requesting then you kill the VM. There seems to be a lot of benefits from that: single user authentication, horizontally scaling is simple ("verti…

Erlang on Xen is probably closest to what you're asking: http://erlangonxen.org/

Re: A unikernel experiment: A VM for every URL

#15

Post by jacques_chester »

avsm wrote: post #11
NhanH wrote: post #10

I've always thought that something really cool could be done with unikernel for SaaS: you let each of your customer have a VM on their own, spinning the unikernel up when the requests came in, and let it process any request come in, after a while, if the specific user stop requesting then you kill the VM. There seems to be a lot of benefits from that: single user authentication, horizontally scaling is simple ("verti…

That sort of design is what motivated Magnus' post that has been linked here. We've been laying the uniSaaS groundwork with a new Xen toolstack daemon called Jitsu ("Just in Time Summoning of Unikernels"). 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…

I think the obstacle is that most folk are not prepared to give up their languages for this, so containerising PaaSes are still likely to dominate the scene.

Disclaimer: I worked on Cloud Foundry.

Re: A unikernel experiment: A VM for every URL

#16

Post by avsm »

jacques_chester wrote: post #15
avsm wrote: post #11

Earlier quoted context omitted.

That sort of design is what motivated Magnus' post that has been linked here. We've been laying the uniSaaS groundwork with a new Xen toolstack daemon called Jitsu ("Just in Time Summoning of Unikernels"). 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…

I think the obstacle is that most folk are not prepared to give up their languages for this, so containerising PaaSes are still likely to dominate the scene. Disclaimer: I worked on Cloud Foundry.

> I think the obstacle is that most folk are not prepared to give up their languages

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.

Re: A unikernel experiment: A VM for every URL

#17

Post by tobz »

thom_nic wrote: post #13

I seem to remember something similar that was an erlang VM running (I think) directly on Xen. The underlying idea in that case was each request causes a new VM to boot, service that request, then terminate.

Mentioned in another top-level comment: http://erlangonxen.org/

Re: A unikernel experiment: A VM for every URL

#18

Post by sp332 »

lbotos wrote: post #9

" I have not been able to find a hosting provider that has a minimum configuration which would be appropriate for large or small unikernels (e.g. 8MB vs 64MB RAM)." This is the biggest problem with unikernels right now.

Looks like an arbitrage opportunity! Buy 64MB server, sell 8MB servers.

Re: A unikernel experiment: A VM for every URL

#19

Post by jacques_chester »

avsm wrote: post #16
jacques_chester wrote: post #15

Earlier quoted context omitted.

I think the obstacle is that most folk are not prepared to give up their languages for this, so containerising PaaSes are still likely to dominate the scene. Disclaimer: I worked on Cloud Foundry.

> I think the obstacle is that most folk are not prepared to give up their languages 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.

Hm. Got me thinking about how to fit unikernels into the CF architecture, which is largely taking containers (Garden or Docker, take your pick) as the unit of currency at the low level.

It looks like the place to make the change would be in Diego in the Executor[0][1] 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[2] it looks as though unikernels would be a plausible addition to Executor. Once you have that, you can either wire into Lattice[3] 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.

[0] https://github.com/cloudfoundry-incubator/executor

[1] https://github.com/cloudfoundry-incubator/diego-design-notes

[2] https://github.com/cloudfoundry-incubator/receptor/blob/mast...

[3] http://lattice.cf/

Post reply on HN