[nderjung]

> Most people don't run metal today

We are seeing an increasing trend towards On-prem/Cloud-prem/Co-los[0], mainly due to cost and reduced complexity. Inversely, most smaller companies (1-10 emp) who use hyperscalers do not use their metal offerings, because of cost. They wish to scale with demand which metal cannot provide. Using EKS and other similar services have the benefit of being familiar and elastic, but are in fact slow and soon become quite expensive[1].

[0]: https://www.gartner.com/en/newsroom/press-releases/2023-05-1...

[1]: https://a16z.com/the-cost-of-cloud-a-trillion-dollar-paradox...

> How many people know unikernels?

This has been a goal of Unikraft for a long time, to make using unikernels simple and familiar to use (in fact, transparent). This is why we use OCI images as the root filesystem; why it's possible to start unikernels through Docker; why we have several types of Kubernetes integrations.

> How do you debug a running app?

For one, you can attach a gdb server and step through both application code and kernel code together. Secondly, at Unikraft at least, we are introducing a virtual shell that allows you to introspect the filesystem, main threads, see system stats, etc.

> Stripped down Linux distros reduces attack surface

This is may reduce the attack surface, but one bad-actor application can still take down the host and all the other containers since they are still process (software) isolated. With unikernels you get hardware-level isolation AND, interestingly, the performance thanks to the lack of strong syscall boundaries.

> Unikernels increase complexity

Give us a chance and try out one of our examples :-)

https://github.com/unikraft/catalog/tree/main/examples

[cedws]

> With unikernels you get hardware-level isolation AND, interestingly, the performance thanks to the lack of strong syscall boundaries

How does this compare to gVisor? My understanding is that it's the same.

Thanks for the detailed response. I might give it a go some weekend.

[nderjung]

In fact gVisor is the opposite, it injects more guard instructions between the application and the kernel across the syscall layer in order to make stronger security guarantees. These additional guards slow the application even further by however long it takes to perform necessary permission checks.

It is not necessary to have such checks in a unikernel because the kernel inherently trusts the application because together they were constructed in the same pipeline. The hardware then protects the two together.

[redwood]

Out of curiosity when you say "we", what vantage point are you referring to?