When I first read about unikernels I thought its a great way to remove a layer forced upon you by cloud providers.
Most public clouds run some form of hypervisor, on top of which you run your VM and applications. I only want to run my application, and I don't get to choose to remove the hypervisor, thus I can only remove the kernel: a unikernel is like running an application on a hypervisor:
your hypervisor is your "OS kernel" and your unikernel is your application ... and we gained back what we lost compared to a bare-metal deployment.
That is a simplified view, and there are other advantages as well: you probably don't need to exit to your hypervisor quite as often as you do with syscalls, so you benefit from reduced overhead.
One disadvantage is that memory allocation is almost static (unless you do ballooning which is tricky to get right), so you "waste" some memory compared to a bare-metal deployment where unused memory can be used for the page cache instead.
That is a simplified view, and there are other advantages as well: you probably don't need to exit to your hypervisor quite as often as you do with syscalls, so you benefit from reduced overhead. One disadvantage is that memory allocation is almost static (unless you do ballooning which is tricky to get right), so you "waste" some memory compared to a bare-metal deployment where unused memory can be used for the page cache instead.