4 ms·

You use the native cloud facilities available by spinning up a new instance per deploy. Whether you need a simple shared thread (smallest instances available) o

by eyberg 6y ago

You use the native cloud facilities available by spinning up a new instance per deploy. Whether you need a simple shared thread (smallest instances available) or you want to tackle the 368 thread monsters available on something like GCloud both are fine. It's worth pointing out that if you run containers on public cloud you are inherently virtualized already - this actually removes layers instead of adding layers on.

angry_octet 6y ago
Theoretically you are renting 100% of a virtual core (whatever fraction of a real core that is depends on the hardware you're scheduled on at that moment), but in practice you're sharing cycles at small core counts. But anyway, if you spawn 8 instances each with 2 cores you're not getting any more compute than 16 cores on the same box. You could schedule them with cpuset to have 2 cores per process, or you could let the scheduler run. But there is no free lunch from the cloud. I have no idea why you think running on N images reduces overhead.
- pjmlp 6y ago
  Less fat in OS layers, thus reducing the total resources per image.
  - angry_octet 6y ago
    But if the images are unique you now have N instances to manage... when the dependencies are strongly coupled!
    - pjmlp 6y ago
      Just like Docker images that everyone around here loves so much.
- eyberg 6y ago
  Where do most of the container users deploy their containers? Would you say they are on the public cloud which is inherently virtualized to begin with? A lot of people that have not deployed unikernels might not be aware of how they are actually deployed. When we deploy our websites and database and such to something like Google or AWS we upload a disk image. That disk image is then converted into a machine image. On AWS that would be an AMI. Then we boot that AMI and that AMI only contains your program. There is no underlying linux that you deploy and then you ssh into and install some k8s substitute. So, yes, in comparison to launching a linux instance on AWS or Google, then installing k8s or using nomad or something like that, that has to inherently duplicate networking, duplicate storage, duplicate security, and many other things - yes it reduces quite a lot. This doesn't even touch on the fact that many unikernels tend to run much faster for other reasons. We are just talking about not having to use things like underlay/overlay networks or storage proxies. Again, the images that are deployed get managed by the cloud of choice - so your networking, storage, security, etc. is all managed by that cloud.

by eyberg 6y ago

angry_octet 6y ago

Theoretically you are renting 100% of a virtual core (whatever fraction of a real core that is depends on the hardware you're scheduled on at that moment), but in practice you're sharing cycles at small core counts. But anyway, if you spawn 8 instances each with 2 cores you're not getting any more compute than 16 cores on the same box. You could schedule them with cpuset to have 2 cores per process, or you could let the scheduler run. But there is no free lunch from the cloud. I have no idea why you think running on N images reduces overhead.

pjmlp 6y ago
Less fat in OS layers, thus reducing the total resources per image.
- angry_octet 6y ago
  But if the images are unique you now have N instances to manage... when the dependencies are strongly coupled!
  - pjmlp 6y ago
    Just like Docker images that everyone around here loves so much.
eyberg 6y ago
Where do most of the container users deploy their containers? Would you say they are on the public cloud which is inherently virtualized to begin with? A lot of people that have not deployed unikernels might not be aware of how they are actually deployed. When we deploy our websites and database and such to something like Google or AWS we upload a disk image. That disk image is then converted into a machine image. On AWS that would be an AMI. Then we boot that AMI and that AMI only contains your program. There is no underlying linux that you deploy and then you ssh into and install some k8s substitute. So, yes, in comparison to launching a linux instance on AWS or Google, then installing k8s or using nomad or something like that, that has to inherently duplicate networking, duplicate storage, duplicate security, and many other things - yes it reduces quite a lot. This doesn't even touch on the fact that many unikernels tend to run much faster for other reasons. We are just talking about not having to use things like underlay/overlay networks or storage proxies. Again, the images that are deployed get managed by the cloud of choice - so your networking, storage, security, etc. is all managed by that cloud.