6 ms·

I'd like a real explanation for why containers are better than unikernels. Yes, unikernals are still early, and containers are convenient, because you have all

by MCRed 11y ago

I'd like a real explanation for why containers are better than unikernels. Yes, unikernals are still early, and containers are convenient, because you have all of linux there... but it seems that running several linuxes on a linux machine is a bit much. One operating system plus XEN plus several applications in unikernels seems more efficient, and more exciting. But it's the less common choice. I am guessing convenience is more important than the better solution that would ultimately be more just as convenient and more efficient if it gets enough eyeballs?

ticviking 11y ago
I strongly suspect that as time goes on we'll see that containers and uni-kernels converge.
DannoHung 11y ago
I'm completely unfamiliar with unikernels, but I just skimmed a brief description. My first question is: Do they still incur the overhead of running against a Hypervisor like common virtual machines? Also, possibly a clairification: Unless I'm misunderstanding what you mean by "running several linuxes on a linux machine", I believe you may be mistaken about the way containers work. Only one Linux is really running. And that is the Linux that the kernel comes from. The other stuff doesn't run unless you tell it to (so, no init, no daemons you don't specify, etcetera). Yeah the image size can be a little fat if you don't trim them down, but you can have a container nearly as small as your code is, if you statically compile. On the order of just a few bytes of overhead.
- mirceal 11y ago
  unikernel basically means that you pack your application and only the lower level bits and pieces that you need to get it working. you no longer have an OS in the traditional sense.
jacquesm 11y ago
I'd like a real explanation for why containers and unikernels are better than regular run-of-the-mill applications running on dedicated servers. It's almost as if the wild west of the web isn't quite enough and we now need to add another explosion of layers-of-abstraction but this time on the server in order to pretend we have infinite hardware which then becomes it's own reason for existence rather than to simply run efficient software configured properly on properly utilized hardware. As if regular virtualization alone doesn't give enough headaches in trying to figure out why some subsystem does not perform. At this rate we'll end up shipping containers as 'apps' to the clients machines with a suitable emulator at some point. All this luxury comes at (considerable) cost and not everybody seems to be doing the math before deployment which more often than not leads to terrible efficiency. But we're technology fans, so 'oohh! shiny!'.
- DannoHung 11y ago
  Sorry, but what costs do containers incur? From my understanding, the resource overhead should be exceedingly minimal (disk space would ostensibly be the largest drawback, if you don't spend time cutting out the fat. Personally, I see this as a tooling issue since fat containers are completely orthogonal to how a container really executes). I understand some of the situation with IO isn't perfect yet, but I haven't heard anyone suggest that it cannot be corrected.
  - jacquesm 11y ago
    An OS has some pretty extensive insight into the processes that it executes, a container is an OS with a single application, so containers (assuming they take basic precautions for isolation) are not going to be able to schedule with anywhere near the efficiency that multiple processes on a single OS will. I can see some (mostly potential at this point) security advantages but that's about it (and maybe those advantages will be enough to justify the performance overhead but containers are mostly treated as a silver bullet by the adherents and I'd like to see a bit more balance).
    - DannoHung 11y ago
      Do you know where I can read more about this? This is the first I have heard that processes running inside containers interfere with the kernel's scheduler. Or, sorry again, but maybe I'm not following your meaning in some way?
      - mixmastamyk 11y ago
        It's not true, so I wouldn't bother looking too hard. ;) The linux kernel does not "lose track" of processes/libs inside containers, they are simply namespaced, like a more extensive chroot environment.
      - jacquesm 11y ago
        Each 'container' is in effect an application plus all its dependencies. So if one or more active containers could share resources then they won't, which leads to inefficiencies because you'll be running a much larger number of processes than you would otherwise (because of duplication) requiring a larger memory footprint and probably less efficient cache and/or IO utilization. The deployment of the apps will be easier (which is a definite plus) but machine utilization will be lower and the amount of software running on a single machine will be far larger than otherwise, especially if multiple versions of dependencies are present on the same system. A container is very much not a single process, it can contain many processes and some of those processes will likely duplicate components in other containers but without the resource optimizations that a kernel can normally perform.
mixmastamyk 11y ago
> but it seems that running several linuxes on a linux machine is a bit much Perhaps because that's not what happens, the host runs one copy of linux, which namespaces the containers.
sp332 11y ago
If you have a statically-linked binary you can just run it in a container. You don't need a whole OS userland in there.
- zobzu 11y ago
  [...] since the whole userland that you need is included in the binary (worth noting) you just dont get the debugging stuff (which is okay as long as you can choose)
  - mirceal 11y ago
    would argue that it's not just the userland. you only have the functionality you need and your bits. for example an http server would have the http stack + your app. there is no userland, there are no drivers, just your app as the only thing that is running on the machine. your app basically merges with the "kernel"
    - zobzu 11y ago
      the kernel has the drivers you need. the http stack needs libc or equivalent. basically its the same except statically linked, and without debug/troubleshooting tools. yes, really! it does reduce the attack surface/amount of things.

by MCRed 11y ago

ticviking 11y ago

I strongly suspect that as time goes on we'll see that containers and uni-kernels converge.

DannoHung 11y ago

I'm completely unfamiliar with unikernels, but I just skimmed a brief description. My first question is: Do they still incur the overhead of running against a Hypervisor like common virtual machines? Also, possibly a clairification: Unless I'm misunderstanding what you mean by "running several linuxes on a linux machine", I believe you may be mistaken about the way containers work. Only one Linux is really running. And that is the Linux that the kernel comes from. The other stuff doesn't run unless you tell it to (so, no init, no daemons you don't specify, etcetera). Yeah the image size can be a little fat if you don't trim them down, but you can have a container nearly as small as your code is, if you statically compile. On the order of just a few bytes of overhead.

mirceal 11y ago
unikernel basically means that you pack your application and only the lower level bits and pieces that you need to get it working. you no longer have an OS in the traditional sense.

jacquesm 11y ago

I'd like a real explanation for why containers and unikernels are better than regular run-of-the-mill applications running on dedicated servers. It's almost as if the wild west of the web isn't quite enough and we now need to add another explosion of layers-of-abstraction but this time on the server in order to pretend we have infinite hardware which then becomes it's own reason for existence rather than to simply run efficient software configured properly on properly utilized hardware. As if regular virtualization alone doesn't give enough headaches in trying to figure out why some subsystem does not perform. At this rate we'll end up shipping containers as 'apps' to the clients machines with a suitable emulator at some point. All this luxury comes at (considerable) cost and not everybody seems to be doing the math before deployment which more often than not leads to terrible efficiency. But we're technology fans, so 'oohh! shiny!'.

DannoHung 11y ago
Sorry, but what costs do containers incur? From my understanding, the resource overhead should be exceedingly minimal (disk space would ostensibly be the largest drawback, if you don't spend time cutting out the fat. Personally, I see this as a tooling issue since fat containers are completely orthogonal to how a container really executes). I understand some of the situation with IO isn't perfect yet, but I haven't heard anyone suggest that it cannot be corrected.
- jacquesm 11y ago
  An OS has some pretty extensive insight into the processes that it executes, a container is an OS with a single application, so containers (assuming they take basic precautions for isolation) are not going to be able to schedule with anywhere near the efficiency that multiple processes on a single OS will. I can see some (mostly potential at this point) security advantages but that's about it (and maybe those advantages will be enough to justify the performance overhead but containers are mostly treated as a silver bullet by the adherents and I'd like to see a bit more balance).
  - DannoHung 11y ago
    Do you know where I can read more about this? This is the first I have heard that processes running inside containers interfere with the kernel's scheduler. Or, sorry again, but maybe I'm not following your meaning in some way?
    - mixmastamyk 11y ago
      It's not true, so I wouldn't bother looking too hard. ;) The linux kernel does not "lose track" of processes/libs inside containers, they are simply namespaced, like a more extensive chroot environment.
    - jacquesm 11y ago
      Each 'container' is in effect an application plus all its dependencies. So if one or more active containers could share resources then they won't, which leads to inefficiencies because you'll be running a much larger number of processes than you would otherwise (because of duplication) requiring a larger memory footprint and probably less efficient cache and/or IO utilization. The deployment of the apps will be easier (which is a definite plus) but machine utilization will be lower and the amount of software running on a single machine will be far larger than otherwise, especially if multiple versions of dependencies are present on the same system. A container is very much not a single process, it can contain many processes and some of those processes will likely duplicate components in other containers but without the resource optimizations that a kernel can normally perform.

mixmastamyk 11y ago

> but it seems that running several linuxes on a linux machine is a bit much Perhaps because that's not what happens, the host runs one copy of linux, which namespaces the containers.

sp332 11y ago

If you have a statically-linked binary you can just run it in a container. You don't need a whole OS userland in there.

zobzu 11y ago
[...] since the whole userland that you need is included in the binary (worth noting) you just dont get the debugging stuff (which is okay as long as you can choose)
- mirceal 11y ago
  would argue that it's not just the userland. you only have the functionality you need and your bits. for example an http server would have the http stack + your app. there is no userland, there are no drivers, just your app as the only thing that is running on the machine. your app basically merges with the "kernel"
  - zobzu 11y ago
    the kernel has the drivers you need. the http stack needs libc or equivalent. basically its the same except statically linked, and without debug/troubleshooting tools. yes, really! it does reduce the attack surface/amount of things.