3 ms·

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 J

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

by avsm 12y ago

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