5 ms·

If I'm reading this right, that's pretty major. The isolation benefits of a VM with a bootspeed faster than docker?

tyingq 9y ago
https://hypercontainer.io https://hypercontainer.io is also in this space. Doesn't boot as fast as docker, but faster than a normal VM.
- _joel 9y ago
  Also Clear Containers from Intel - https://clearlinux.org/features/intel%C2%AE-clear-containers https://clearlinux.org/features/intel%C2%AE-clear-containers
  - blixtra 9y ago
    Right, Clear Containers is a feature of both rkt and cri-o container runtimes. rkt has had that feature for a couple years, if I recall correctly.
lbotos 9y ago
I haven't been on the server side in a while, but 1) isn't Xen falling out of favor and 2) is docker boot speed a big problem?
- weberc2 9y ago
  Boot speed is a big selling point for Docker, but Docker's isolation story is poorer than a VM. If you can make a VM boot as quickly as Docker while preserving isolation, then Docker loses a big selling point.
  - Philipp__ 9y ago
    It’s called Zones (on illumos, prev. on Solaris)
    - wise0wl 9y ago
      I'm a huge fan of Illumos and SmartOS and think that Zones + LX Branding are a far superior technology than the hodgepodge of cgroups + namespaces + userland container technology. HOWEVER---the amount of driver support in the OpenSolaris forks, the awful package management system, the ancient IPF system etcetera make it a non-starter for most environments. I have used SmartOS in production (along with the Triton ecosystem) and found it to be well thought out and compelling, albeit woefully immature and buggy. I think that these reasons, plus the EOL nature of Solaris "upstream", would easily put off most people in charge of making a long term technology commitment. I know it did for me.
      - Philipp__ 9y ago
        Well, you are right, but remember how old SmartOS actually is... I kinda hope more people get it, and start investing into that amazing open source technology. I always liked BSDs and Solaris more than Linux (who I find really messy and chaotic).
      - yjftsjthsd-h 9y ago
        Solaris as an upstream was dead long ago; Oracle stopped publishing source years before killing their own product. The heirs of opensolaris seem to have managed well enough
- uytuijhgj 9y ago
  > isn't Xen falling out of favor what are you talking about? somebody tell amazon, stat! idiot. one shouldn't talk when one doesn't know what he's talking about.
- hinkley 9y ago
  Imagine you wanted to run ImageMagick in a docker image in order to reduce the attack surface. The container startup time could become a significant fraction of your image processing time.
- nyrikki 9y ago
  Xen is having a tough time keeping up with qemu/KVM which can take advantage of all the development time Intel spends on the kernel and the scheduler. Obviously Xen will have a long life due to AWS, but I am failing to see anything that machined and kvm don't offer here on the performance oriented side. There is probably be some use case but the xen time slice model doesn't seem to know enough about frequency binning or the impacts of high energy/heat instructions on them to be very competitive in the applications I can think of. Dockers main problem is an increasing number of use cases, and their engineering decisions not meeting everyone's needs. To be honest if it wasn't for faux container support needs on windows/osx I am betting that systemd-nspawn would take over that market due to this. For the most part docker performance is mostly limited by concurrency and amdahl's law (including fs perf). I don't see Xen solving these issues, but there are very real security benefits. One very real use case I can think of is that any person or process that can launch a container on Docker is effectively given password-less sudo access, particularly because you can't disable the privileged flag. The attack surface on Xen would be much lower in that case but once the exploits start arriving docker could change that choice and reduce their attack surface quite a bit.
wkz 9y ago
With the debugging benefits of a brick.
- weberc2 9y ago
  As long as debugging isn't fundamentally incompatible with a unikernel approach, it's just a matter of maturity. And it's pretty silly to criticize a new, prospective technology for immaturity.
  - wkz 9y ago
    > As long as debugging isn't fundamentally incompatible with a unikernel approach, it's just a matter of maturity. Well no, it's not "fundamentally" incompatible, it just doesn't seem very practical. And practicality matters IMHO. Maybe I'm missing something but it seems the debug mode of these systems would be very similar to how you debug a regular kernel. I.e. you have some GDB stub provided by your hypervisor. That might be fine for GDB, but what about all the tools to observe a running system? How would I ftrace, perf, strace, netstat, tcpdump, poke around in /proc and /sys etc? Sure there is noting stopping you from developing equivalent tools. But it's not very practical. Building a truly isolated container environment for Linux (something like Zones) would also give you isolation and provisioning speed, but you get to keep all your tooling.
    - equalunique 9y ago
      Try it with the LING Erlang-on-Xen unikernel and see for yourself if it's not debugabble. Looks like they've got a solution for dubugging: https://twitter.com/erlang_on_xen/status/641628659657371648 https://twitter.com/erlang_on_xen/status/641628659657371648
      - wkz 9y ago
        Again, I'm not saying it can't be done. If Erlang+Xen=Debug then that's great. But if we're comparing unikernel-VMs to containers, my guess is that most users are after the "take my $LANG binary and concatenate it with half a Linux kernel"-workflow. And for that general case, most standard tools are off the table.
est 9y ago
Maybe faster than docker, but how about Intel's Clear Containers? https://lwn.net/Articles/644675/ https://lwn.net/Articles/644675/

https://hypercontainer.io https://hypercontainer.io is also in this space. Doesn't boot as fast as docker, but faster than a normal VM.

_joel 9y ago
Also Clear Containers from Intel - https://clearlinux.org/features/intel%C2%AE-clear-containers https://clearlinux.org/features/intel%C2%AE-clear-containers
- blixtra 9y ago
  Right, Clear Containers is a feature of both rkt and cri-o container runtimes. rkt has had that feature for a couple years, if I recall correctly.

lbotos 9y ago

I haven't been on the server side in a while, but 1) isn't Xen falling out of favor and 2) is docker boot speed a big problem?

weberc2 9y ago
Boot speed is a big selling point for Docker, but Docker's isolation story is poorer than a VM. If you can make a VM boot as quickly as Docker while preserving isolation, then Docker loses a big selling point.
- Philipp__ 9y ago
  It’s called Zones (on illumos, prev. on Solaris)
  - wise0wl 9y ago
    I'm a huge fan of Illumos and SmartOS and think that Zones + LX Branding are a far superior technology than the hodgepodge of cgroups + namespaces + userland container technology. HOWEVER---the amount of driver support in the OpenSolaris forks, the awful package management system, the ancient IPF system etcetera make it a non-starter for most environments. I have used SmartOS in production (along with the Triton ecosystem) and found it to be well thought out and compelling, albeit woefully immature and buggy. I think that these reasons, plus the EOL nature of Solaris "upstream", would easily put off most people in charge of making a long term technology commitment. I know it did for me.
    - Philipp__ 9y ago
      Well, you are right, but remember how old SmartOS actually is... I kinda hope more people get it, and start investing into that amazing open source technology. I always liked BSDs and Solaris more than Linux (who I find really messy and chaotic).
    - yjftsjthsd-h 9y ago
      Solaris as an upstream was dead long ago; Oracle stopped publishing source years before killing their own product. The heirs of opensolaris seem to have managed well enough
uytuijhgj 9y ago
> isn't Xen falling out of favor what are you talking about? somebody tell amazon, stat! idiot. one shouldn't talk when one doesn't know what he's talking about.
hinkley 9y ago
Imagine you wanted to run ImageMagick in a docker image in order to reduce the attack surface. The container startup time could become a significant fraction of your image processing time.
nyrikki 9y ago
Xen is having a tough time keeping up with qemu/KVM which can take advantage of all the development time Intel spends on the kernel and the scheduler. Obviously Xen will have a long life due to AWS, but I am failing to see anything that machined and kvm don't offer here on the performance oriented side. There is probably be some use case but the xen time slice model doesn't seem to know enough about frequency binning or the impacts of high energy/heat instructions on them to be very competitive in the applications I can think of. Dockers main problem is an increasing number of use cases, and their engineering decisions not meeting everyone's needs. To be honest if it wasn't for faux container support needs on windows/osx I am betting that systemd-nspawn would take over that market due to this. For the most part docker performance is mostly limited by concurrency and amdahl's law (including fs perf). I don't see Xen solving these issues, but there are very real security benefits. One very real use case I can think of is that any person or process that can launch a container on Docker is effectively given password-less sudo access, particularly because you can't disable the privileged flag. The attack surface on Xen would be much lower in that case but once the exploits start arriving docker could change that choice and reduce their attack surface quite a bit.

wkz 9y ago

With the debugging benefits of a brick.

weberc2 9y ago
As long as debugging isn't fundamentally incompatible with a unikernel approach, it's just a matter of maturity. And it's pretty silly to criticize a new, prospective technology for immaturity.
- wkz 9y ago
  > As long as debugging isn't fundamentally incompatible with a unikernel approach, it's just a matter of maturity. Well no, it's not "fundamentally" incompatible, it just doesn't seem very practical. And practicality matters IMHO. Maybe I'm missing something but it seems the debug mode of these systems would be very similar to how you debug a regular kernel. I.e. you have some GDB stub provided by your hypervisor. That might be fine for GDB, but what about all the tools to observe a running system? How would I ftrace, perf, strace, netstat, tcpdump, poke around in /proc and /sys etc? Sure there is noting stopping you from developing equivalent tools. But it's not very practical. Building a truly isolated container environment for Linux (something like Zones) would also give you isolation and provisioning speed, but you get to keep all your tooling.
  - equalunique 9y ago
    Try it with the LING Erlang-on-Xen unikernel and see for yourself if it's not debugabble. Looks like they've got a solution for dubugging: https://twitter.com/erlang_on_xen/status/641628659657371648 https://twitter.com/erlang_on_xen/status/641628659657371648
    - wkz 9y ago
      Again, I'm not saying it can't be done. If Erlang+Xen=Debug then that's great. But if we're comparing unikernel-VMs to containers, my guess is that most users are after the "take my $LANG binary and concatenate it with half a Linux kernel"-workflow. And for that general case, most standard tools are off the table.

est 9y ago

Maybe faster than docker, but how about Intel's Clear Containers? https://lwn.net/Articles/644675/ https://lwn.net/Articles/644675/