4 ms·

I agree. One of the appeals of unikernels in my opinion is that (I think) they will eventually give us the things that Docker currently gives us, but with one l

I agree. One of the appeals of unikernels in my opinion is that (I think) they will eventually give us the things that Docker currently gives us, but with one less layer of abstraction (unikernels running on a VM orchestrator instead of containers running on a container orchestrator running on a VM orchestrator). I imagine that this is inevitable as a matter of efficiency, but it's probably such a small practical gain that we won't see much traction in the next decade.

rhinoceraptor 8y ago
Or you could just run containers without the abhorrent mess that is hardware virtualization...
- mato 8y ago
  The post discusses running unikernels without "the abhorrent mess that is hardware virtualization".
MaxBarraclough 8y ago
> I imagine that this is inevitable as a matter of efficiency, but it's probably such a small practical gain that we won't see much traction in the next decade. I agree that if the advantages boil down to saving a hundred MB of RAM of two, and enabling additional compiler optimisations, it won't be compelling to that many folks. Taken to the extreme though, we can start spinning up instances 'just in time' to deal with incoming requests. Doing this, you could run (and hopefully pay for) your instances for only a tiny fraction of the time your service is in a working/available state. This has apparently already been demonstrated [0], but their demo has been broken for as long as I can remember. I presume it worked at one point. I don't know if any commercial Xen-based offerings can spin up an instance as quickly as their configuration did, but the idea is there. [0] http://erlangonxen.org/zerg http://erlangonxen.org/zerg
- weberc2 8y ago
  I think container orchestration offerings are pretty much at the pricing model you describe. You can spin them up just in time and only pay for what you use. The advantage to unikernels is that cloud operators don't have to operate two layers of orchestrators, so they could pass those savings onto unikernel users; however, I don't think that will be the lowest hanging fruit for a long time.
- naasking 8y ago
  My VM is lighter and safer than your container: https://news.ycombinator.com/item?id=15610155 https://news.ycombinator.com/item?id=15610155
  - weberc2 8y ago
    Unfortunately the tooling story is poor for VMs. There isn't a good analog for the Docker toolchain (build, pull, push, etc) or container orchestrators (e.g., Kubernetes). These stories are at least as important as "lighter and safer".
    - eyberg 8y ago
      I'd disagree here. The entire public cloud model is built on top of VMs. While I have a strong distaste for most CFM tooling out there that is precisely what you're talking about. Chef, Puppet, Salt Stack, Terraform, etc. all fulfill this and all of these are popular in their own communities.
      - weberc2 8y ago
        I don't doubt that there are analogs for individual components, but I don't think there is anything comparable to Kubernetes for VMs. I also doubt the quality of those individual components or their integrations (for example, how do I build a VM image in <1m, what image repo technology should I use, what orchestration technologies exist and how do I tell it how to pull from my image repo, can I run that orchestration tech locally or on prem, etc?). I don't think these are insurmountable problems; there just isn't the same amount of investment (or rather, the investment is comparatively poorly coordinated).
    - justincormack 8y ago
      LinuxKit gives build push run for VMs. It was kind if designed to be a half way stage to a full unikernel model.
      - weberc2 8y ago
AnIdiotOnTheNet 8y ago
I'd argue the opposite, which is that the future will have even more layers of abstraction, not less, since that's been the trend for quite some time.
- weberc2 8y ago
  My prediction is absolutely not "fewer total layers of abstraction", but only that this one will be collapsed in time. You can collapse one layer of abstraction and add two more, which is sufficient for my prediction to be compatible with the "more total layers of abstraction" prediction. :)

rhinoceraptor 8y ago

Or you could just run containers without the abhorrent mess that is hardware virtualization...

mato 8y ago
The post discusses running unikernels without "the abhorrent mess that is hardware virtualization".

MaxBarraclough 8y ago

> I imagine that this is inevitable as a matter of efficiency, but it's probably such a small practical gain that we won't see much traction in the next decade. I agree that if the advantages boil down to saving a hundred MB of RAM of two, and enabling additional compiler optimisations, it won't be compelling to that many folks. Taken to the extreme though, we can start spinning up instances 'just in time' to deal with incoming requests. Doing this, you could run (and hopefully pay for) your instances for only a tiny fraction of the time your service is in a working/available state. This has apparently already been demonstrated [0], but their demo has been broken for as long as I can remember. I presume it worked at one point. I don't know if any commercial Xen-based offerings can spin up an instance as quickly as their configuration did, but the idea is there. [0] http://erlangonxen.org/zerg http://erlangonxen.org/zerg

weberc2 8y ago
I think container orchestration offerings are pretty much at the pricing model you describe. You can spin them up just in time and only pay for what you use. The advantage to unikernels is that cloud operators don't have to operate two layers of orchestrators, so they could pass those savings onto unikernel users; however, I don't think that will be the lowest hanging fruit for a long time.
naasking 8y ago
My VM is lighter and safer than your container: https://news.ycombinator.com/item?id=15610155 https://news.ycombinator.com/item?id=15610155
- weberc2 8y ago
  Unfortunately the tooling story is poor for VMs. There isn't a good analog for the Docker toolchain (build, pull, push, etc) or container orchestrators (e.g., Kubernetes). These stories are at least as important as "lighter and safer".
  - eyberg 8y ago
    I'd disagree here. The entire public cloud model is built on top of VMs. While I have a strong distaste for most CFM tooling out there that is precisely what you're talking about. Chef, Puppet, Salt Stack, Terraform, etc. all fulfill this and all of these are popular in their own communities.
    - weberc2 8y ago
      I don't doubt that there are analogs for individual components, but I don't think there is anything comparable to Kubernetes for VMs. I also doubt the quality of those individual components or their integrations (for example, how do I build a VM image in <1m, what image repo technology should I use, what orchestration technologies exist and how do I tell it how to pull from my image repo, can I run that orchestration tech locally or on prem, etc?). I don't think these are insurmountable problems; there just isn't the same amount of investment (or rather, the investment is comparatively poorly coordinated).
  - justincormack 8y ago
    LinuxKit gives build push run for VMs. It was kind if designed to be a half way stage to a full unikernel model.
    - weberc2 8y ago

AnIdiotOnTheNet 8y ago

I'd argue the opposite, which is that the future will have even more layers of abstraction, not less, since that's been the trend for quite some time.

weberc2 8y ago
My prediction is absolutely not "fewer total layers of abstraction", but only that this one will be collapsed in time. You can collapse one layer of abstraction and add two more, which is sufficient for my prediction to be compatible with the "more total layers of abstraction" prediction. :)