3 ms·

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 unikern

by NhanH 12y ago

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 ("vertical" scaling also get easier as you can just move VM away), app design will easily let it become an on premise installation. Code upgrade is also easier as it won't disturb everyone at once, and you can upgrade when the VM is not running for a specific user (no hotswap needed). There is definitely operational overhead in a DNS server, but besides that it seems like the benefits would outweight the cons. 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?

avsm 12y ago
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 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...
- jacques_chester 12y ago
  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.
  - avsm 12y ago
    > 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.
    - jacques_chester 12y ago
      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 https://github.com/cloudfoundry-incubator/executor [1] https://github.com/cloudfoundry-incubator/diego-design-notes https://github.com/cloudfoundry-incubator/diego-design-notes [2] https://github.com/cloudfoundry-incubator/receptor/blob/master/doc/actions.md https://github.com/cloudfoundry-incubator/receptor/blob/mast... [3] http://lattice.cf/ http://lattice.cf/
      - avsm 12y ago
        Thanks, this are all really helpful pointers! It's particularly useful to find Lattice, which seems to be a simpler entry point than a full CF setup.
        jacques_chester 12y ago
        The shiny website was new to me. I wonder if we've officially announced it yet? 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/issues/1 https://github.com/pivotal-cf-experimental/lattice-app/issue...
jacques_chester 12y ago
Erlang on Xen is probably closest to what you're asking: http://erlangonxen.org/ http://erlangonxen.org/
thomaskauth 12y ago
I did something similar during my PhD. Maybe you want to have a look: http://se.inf.tu-dresden.de/pubs/papers/knauth2014dreamserver.pdf http://se.inf.tu-dresden.de/pubs/papers/knauth2014dreamserve... It was published at SYSTOR last year (2014).

by NhanH 12y ago

avsm 12y ago

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

jacques_chester 12y ago
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.
- avsm 12y ago
  > 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.
  - jacques_chester 12y ago
    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 https://github.com/cloudfoundry-incubator/executor [1] https://github.com/cloudfoundry-incubator/diego-design-notes https://github.com/cloudfoundry-incubator/diego-design-notes [2] https://github.com/cloudfoundry-incubator/receptor/blob/master/doc/actions.md https://github.com/cloudfoundry-incubator/receptor/blob/mast... [3] http://lattice.cf/ http://lattice.cf/
    - avsm 12y ago
      Thanks, this are all really helpful pointers! It's particularly useful to find Lattice, which seems to be a simpler entry point than a full CF setup.
      - jacques_chester 12y ago
        The shiny website was new to me. I wonder if we've officially announced it yet? 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/issues/1 https://github.com/pivotal-cf-experimental/lattice-app/issue...

jacques_chester 12y ago

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

thomaskauth 12y ago

I did something similar during my PhD. Maybe you want to have a look: http://se.inf.tu-dresden.de/pubs/papers/knauth2014dreamserver.pdf http://se.inf.tu-dresden.de/pubs/papers/knauth2014dreamserve... It was published at SYSTOR last year (2014).