3 ms·

Conceptually I really like unikernels, but I don't think they have much purpose in the software world today. A lot of companies aren't running their stuff on m

by cedws 3y ago

Conceptually I really like unikernels, but I don't think they have much purpose in the software world today. A lot of companies aren't running their stuff on metal anymore, they're running on Kubernetes. It's what people know and are familiar with. How many people know unikernels? How do you even debug an app running on a unikernel? How do you convert a "legacy" app to be runnable on a unikernel? There are already very stripped down Linux distributions out there for running apps on Kubernetes like Bottlerocket OS. This removes the majority of the attack surface that unikernels remove. And you get to keep the Linux ABI. Unikernels may strip out a lot of bloat and attack surface, but they also introduce a lot of complexity of their own.

pjmlp 3y ago
The approach is similar to how to debug or convert an application to run on serveless, or cloud managed runtimes. The unikernels benefit is exactly for such cloud offerings to be even leaner in resource usage.
- cedws 3y ago
  So the market for this is cloud providers? If so, I think it's failed. Amazon, Cloudflare, et al have already developed their own lightweight runtimes based on Firecracker/V8. They might not be quite as light as unikernels, but within the same order of magnitude for sure, and I doubt the savings justify additional development complexity. As a cloud provider, your goal is to make your services as easy to adopt as possible.
  - pjmlp 3y ago
    As Oxide, Joyent. Netfly, Vercel, GraalOne,... are showing, there is a lot of market out there beyond hyperscalers. One doesn't need to be yet another AWS to be a sustainable business.
  - TotoroGendut 3y ago
    Why would it automatically fail just because others have ship their products first? It's always good when new ideas are tried and bring something new to the table. Never say never. > I doubt the savings justify additional development complexity. As a cloud provider, your goal is to make your services as easy to adopt as possible. I have been following the news on Unikraft development for a few years now (since 2019 I think) and now fortunately am a beta tester on kraftcloud. I have seen their website and documentation transform from something that only linux kernel wizards would use to what it is now. So definitely they put some work on making sure unikraft is easy to adopt. As the current state of kraftcloud, some apps can already be deployed by copy-pasting the config file (that usually consists of 4 or so lines), install the CLI and hit the deploy button. If you want to enable the scale-to-zero you only need to put -0 at the end of the deploy command. If your use cases not covered in their documentation asking their support or joining the discord is a good start if you don't want to deal directly with the "complexity" (which from my experience mainly consist of copy-pasting some .so files into the root folder).
nderjung 3y ago
> 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-16-gartner-says-4-trends-are-shaping-the-future-of-cloud-data-center-and-edge-infrastructure https://www.gartner.com/en/newsroom/press-releases/2023-05-1... [1]: https://a16z.com/the-cost-of-cloud-a-trillion-dollar-paradox/ 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 https://github.com/unikraft/catalog/tree/main/examples
- cedws 3y ago
  > 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 3y ago
    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.
citizenpaul 3y ago
I was under the impression that containers/Kubernetes actually depend more on the kernel than virtualization as they run the containers by sharing the kernel? I may be misunderstanding it and need some HN knowledge power!

by cedws 3y ago

pjmlp 3y ago

The approach is similar to how to debug or convert an application to run on serveless, or cloud managed runtimes. The unikernels benefit is exactly for such cloud offerings to be even leaner in resource usage.

cedws 3y ago
So the market for this is cloud providers? If so, I think it's failed. Amazon, Cloudflare, et al have already developed their own lightweight runtimes based on Firecracker/V8. They might not be quite as light as unikernels, but within the same order of magnitude for sure, and I doubt the savings justify additional development complexity. As a cloud provider, your goal is to make your services as easy to adopt as possible.
- pjmlp 3y ago
  As Oxide, Joyent. Netfly, Vercel, GraalOne,... are showing, there is a lot of market out there beyond hyperscalers. One doesn't need to be yet another AWS to be a sustainable business.
- TotoroGendut 3y ago
  Why would it automatically fail just because others have ship their products first? It's always good when new ideas are tried and bring something new to the table. Never say never. > I doubt the savings justify additional development complexity. As a cloud provider, your goal is to make your services as easy to adopt as possible. I have been following the news on Unikraft development for a few years now (since 2019 I think) and now fortunately am a beta tester on kraftcloud. I have seen their website and documentation transform from something that only linux kernel wizards would use to what it is now. So definitely they put some work on making sure unikraft is easy to adopt. As the current state of kraftcloud, some apps can already be deployed by copy-pasting the config file (that usually consists of 4 or so lines), install the CLI and hit the deploy button. If you want to enable the scale-to-zero you only need to put -0 at the end of the deploy command. If your use cases not covered in their documentation asking their support or joining the discord is a good start if you don't want to deal directly with the "complexity" (which from my experience mainly consist of copy-pasting some .so files into the root folder).

nderjung 3y ago

> 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-16-gartner-says-4-trends-are-shaping-the-future-of-cloud-data-center-and-edge-infrastructure https://www.gartner.com/en/newsroom/press-releases/2023-05-1... [1]: https://a16z.com/the-cost-of-cloud-a-trillion-dollar-paradox/ 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 https://github.com/unikraft/catalog/tree/main/examples

cedws 3y ago
> 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 3y ago
  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.

citizenpaul 3y ago

I was under the impression that containers/Kubernetes actually depend more on the kernel than virtualization as they run the containers by sharing the kernel? I may be misunderstanding it and need some HN knowledge power!