The lightweight-ness argument is enticing, but I'm wondering if the fact that now you have to give these VMs enough RAM to run the app won't mean that you end up with worse flatpacking in terms of RAM than if you used containers?
It depends. A t2.nano has 512mb of memory. If you are using Go or something like that you could go much lower but any runtime environment such as ruby/python/node are going to want a minimum of a few hundred meg. If you are using the JVM you most definitely are going to want an instance with much more memory.
At the end of the day your application decides how much memory it wants and the sysadmin/SRE/devops person just ensures it has enough so it doesn't crash.
If you are hosting your own workloads and those workloads only need tens of megs of ram than you can pack as much as your hypervisor can handle.
Alfred talks about booting 110,000 vms on one host before memory exhaustion:
kinda. if the guest uses something like virtio balloon the sharing isn't any worse. handling exhaustion isn't any better - although I think transparent migration of vms is more of a standard function than for containers, so that's some up I guess.
It looks like around 2015 there was a lot of hype around the topic, but as I tried to document the state of the art, I noticed there hasn't been that much pick up yet. What's your take?
The two main advantages of unikernels are performance (reduced CPU and/or memory requirements) and security (hypervisor rather than container boundary).
It turns out that basically nobody cares about either of those. I know someone who for a while worked at a company that was trying to make money off unikernels. They ended up re-implementing a database in a unikernel, in a way that gave them a 2.5x performance improvement over the original project -- or to put it a different way, switching should allow companies to cut their hosting costs in half. Even with such a clear "win", it was still a difficult sell.
Think about how much backend code is written in interpreted languages like Python, or PHP, or Javascript, rather than in compiled languages like Go or Rust. It's just simpler to start with the simple solution and then throw money at the problem as you scale. And while performance may be one of the reasons that people are choosing Go or Rust for backends, if it were the only advantage, it's unlikely that would be compelling enough.
I suspect it was because containers sufficed and using and creating the tooling around them consumed the attention of those who might have otherwise looked at unikernels.
>I suspect it was because containers sufficed and using and creating the tooling around them consumed the attention of those who might have otherwise looked at unikernels.
I think you might be right. Right place at the right time for containers.
