5 ms·

In general, I get the impression that the whole virtualization trend is just a way to re-invent process isolation with newer technology.

armenb 12y ago
The process isolation is very useful but they've got a point, why we should run million lines of code until we get to the point to run a single web server? Have we ever asked our self why the operating system which its only responsibility is running a web-server should take 300 seconds to boot?
- digi_owl 12y ago
  Sounds like a badly optimized install then. Unless you are running a disk check, or have a hardware raid controller, on every boot, getting a kernel and the minimal environment to run a web server up should take under 1/10 of that.
  - amirmc 12y ago
    So with a whole bunch of additional optimisations (not out-of-the-box) you can get an order of magnitude improvement. Unikernels are at least another two orders of magnitude faster than that (~300ms), without any optimisations. Upcoming paper: http://anil.recoil.org/papers/2015-nsdi-jitsu.pdf http://anil.recoil.org/papers/2015-nsdi-jitsu.pdf
- jacquesm 12y ago
  Boot time is rarely an issue when working with long running daemons such as web servers. We run the millions of lines of code because web servers typically serve up web applications which in turn depend on a whole host of infrastructure being available. The millions of lines of code support all the possible hardware that you could throw at it (and so you can save some if you compile your kernel just for that purpose), and if you know exactly which services your web-app will depend on then you can prune even more. Specialization always pays off in terms of efficiency and it always costs in terms of ease of expansion and adaptation to future needs.
  - nine_k 12y ago
    Boot time of a server is somehow important when you dynamically spin new instances. If spinning a new instance were a sub-second process, you could allow the number of instances you run (and pay for) to follow the demand much more closely. But here the boot time is a proxy metric of complexity. It's great to have software that can do a wide spectrum of things. But your server most often does a narrow spectrum of highly predefined tasks. You often go to great lengths to obviate and disallow any other activity on it, for security reasons. So it would be great if you took the universal software, somehow cut it to your task set, and could throw away the unused parts (which are 90%+). Unfortunately, this is not really attainable with traditional OSes. Unikernels allow you to do just that—with some quite noticeable limitations, as of now, though.
baruch 12y ago
But it's not just process isolation. You also isolate the entire OS, so you can tune your TCP stack to match this application without affecting the others. If you go deeper than that you can even give access to the hardware and thus reduce latencies where you care for it and still provide sensible isolation between the different applications. In the shallowest mode it is just process separation at the deep end it gives you a lot more than that.
- bobland 12y ago
  I don't know for sure with Mirage, but OSv does not provide process isolation since everything is running in kernel memory.
  - baruch 12y ago
    Presumably you'd run one application inside such an image and between two images you do have isolation.
    - bobland 12y ago
      Correct, and it's fair to say that the application pretty much is the image - if the application exits, the VM shuts down. Configuration can be kept out of the image with cloud-init, and I basically treat all images as immutable. The majority of my experience has been using OSv, running Akka, and it's yielding excellent results. Image sizes are small (<200MB), easy enough to upload to AWS and create a new AMI in a few minutes. Boot time to a running application is a few seconds. The only possibly downside is that OSv (as yet) doesn't support paravirtualisation, only HVM.
deleted 12y ago
[deleted]
weland 12y ago
It's not even new. It has a 40-year history and unikernel-like systems were a major research topic during in the late 80s and early 90s -- except everyone was dreaming that we'd have thousands of tiny machines to run it on, rather than big machines with virtualization. "Not enough machines" and "network gets slow before we even get to enough machines" were the two main bottlenecks. Virtualization solves them to some degree. What doesn't help nowadays is the marketing hype that tries to oversell everything and the insane complexity involved in sustaining the whole thing, since virtualization on x86_64 is still, to a high degree, an afterthough that was grumpily patched on x86 along with everything else. The PR bullshit makes serious people outside the high-availability & distributed field discard this as fancy fluff, and the baroque technology stack makes the development pace rather slow.

armenb 12y ago

The process isolation is very useful but they've got a point, why we should run million lines of code until we get to the point to run a single web server? Have we ever asked our self why the operating system which its only responsibility is running a web-server should take 300 seconds to boot?

digi_owl 12y ago
Sounds like a badly optimized install then. Unless you are running a disk check, or have a hardware raid controller, on every boot, getting a kernel and the minimal environment to run a web server up should take under 1/10 of that.
- amirmc 12y ago
  So with a whole bunch of additional optimisations (not out-of-the-box) you can get an order of magnitude improvement. Unikernels are at least another two orders of magnitude faster than that (~300ms), without any optimisations. Upcoming paper: http://anil.recoil.org/papers/2015-nsdi-jitsu.pdf http://anil.recoil.org/papers/2015-nsdi-jitsu.pdf
jacquesm 12y ago
Boot time is rarely an issue when working with long running daemons such as web servers. We run the millions of lines of code because web servers typically serve up web applications which in turn depend on a whole host of infrastructure being available. The millions of lines of code support all the possible hardware that you could throw at it (and so you can save some if you compile your kernel just for that purpose), and if you know exactly which services your web-app will depend on then you can prune even more. Specialization always pays off in terms of efficiency and it always costs in terms of ease of expansion and adaptation to future needs.
- nine_k 12y ago
  Boot time of a server is somehow important when you dynamically spin new instances. If spinning a new instance were a sub-second process, you could allow the number of instances you run (and pay for) to follow the demand much more closely. But here the boot time is a proxy metric of complexity. It's great to have software that can do a wide spectrum of things. But your server most often does a narrow spectrum of highly predefined tasks. You often go to great lengths to obviate and disallow any other activity on it, for security reasons. So it would be great if you took the universal software, somehow cut it to your task set, and could throw away the unused parts (which are 90%+). Unfortunately, this is not really attainable with traditional OSes. Unikernels allow you to do just that—with some quite noticeable limitations, as of now, though.

baruch 12y ago

But it's not just process isolation. You also isolate the entire OS, so you can tune your TCP stack to match this application without affecting the others. If you go deeper than that you can even give access to the hardware and thus reduce latencies where you care for it and still provide sensible isolation between the different applications. In the shallowest mode it is just process separation at the deep end it gives you a lot more than that.

bobland 12y ago
I don't know for sure with Mirage, but OSv does not provide process isolation since everything is running in kernel memory.
- baruch 12y ago
  Presumably you'd run one application inside such an image and between two images you do have isolation.
  - bobland 12y ago
    Correct, and it's fair to say that the application pretty much is the image - if the application exits, the VM shuts down. Configuration can be kept out of the image with cloud-init, and I basically treat all images as immutable. The majority of my experience has been using OSv, running Akka, and it's yielding excellent results. Image sizes are small (<200MB), easy enough to upload to AWS and create a new AMI in a few minutes. Boot time to a running application is a few seconds. The only possibly downside is that OSv (as yet) doesn't support paravirtualisation, only HVM.

deleted 12y ago

[deleted]

weland 12y ago

It's not even new. It has a 40-year history and unikernel-like systems were a major research topic during in the late 80s and early 90s -- except everyone was dreaming that we'd have thousands of tiny machines to run it on, rather than big machines with virtualization. "Not enough machines" and "network gets slow before we even get to enough machines" were the two main bottlenecks. Virtualization solves them to some degree. What doesn't help nowadays is the marketing hype that tries to oversell everything and the insane complexity involved in sustaining the whole thing, since virtualization on x86_64 is still, to a high degree, an afterthough that was grumpily patched on x86 along with everything else. The PR bullshit makes serious people outside the high-availability & distributed field discard this as fancy fluff, and the baroque technology stack makes the development pace rather slow.