KraftCloud
github.com
github.com
You can find more information about Unikraft here:
- https://unikraft.io -- The Unikraft Company
- https://unikraft.org -- The open-source project
- https://kraft.cloud -- The Millisecond Cloud Platform based on Unikraft
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.
The unikernels benefit is exactly for such cloud offerings to be even leaner in resource usage.
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.
One doesn't need to be yet another AWS to be a sustainable business.
> 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).
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 :-)
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.
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.
I wonder how mature is that.
The key difference between unikernels (and library OSes) vs. other kernels is that each kernel is different with a unikernel. Your application goes through a process of specialization, where you can decide exactly the necessary features (e.g. libraries, syscalls, memory allocation, scheduler, etc.) are necessary or desired for your application. Additionally, other kernels are typically multi-process whereas a unikernel is inherently single-process since it does not support syscalls like fork. (That said, at Unikraft, we are working on supporting fork, eta. late April).
Additionally, before Unikraft, one of the major trade-offs was developer time and effort to get your application into a unikernel. Since Unikraft has been actively developed for several years by ~100+ people, it has become much more stable, feature complete and easier to use; ultimately making unikernels easier to approach.
Today, in-addition to multi-process applications, the trade-off now really depends on your usecase and so selecting whether you wish to deploy your application as a unikernel or on top of a monolithic kernel or microkernel. For example, developer environments which require many subsystems, multiple programs, etc., where you can't know everything ahead-of-time, are still best suited for multi-user, monolithic kernels that can run most workloads.
Another thing to note is that unikernels are designed to be immutable and are often created in a CI/CD context. This means that they are single-purpose and if you wish to change them, you need to re-build (or re-package).
[Disclaimer, I'm one of the maintainers]
Another unikernel yes, sorry about that! :) . Unikraft started back in 2017 initially as a research project, and has been a Linux Foundation OSS project since 2018.
While Unikraft OSS is used in different use cases, our primary target is cloud deployments. Unikraft has 3 key principles:
1. A fully modular OS -- so that we can specialize the resulting unikernels (VMs) as much as possible
2. Linux-API compatibility -- so that we don't break applications
3. Integration with Docker/Dockerfiles (and other tools) -- for ease of use
Unikraft powers kraft.cloud . You can see the platform's guides to get an idea of the apps/frameworks it supports: https://docs.kraft.cloud/guides/
In comparison, compiling NGINX together with Unikraft results in a kernel size of under 2MB. This means that there is 28MB of kernel we didn't need or want.
[0]: https://arxiv.org/abs/2104.12721 (See Figure 1)
At least I know from talking to Alex that they actually know what users and people playing with kernels like in his toolchain.
Kraftcloud is just them eating their own dogfood. In my opinion it's all about the toolchain(I mean not only) and these people understand that.
In my opinion Linux didn't win because it has the best design on every front. It won, because it had the easiest toolchain for someone like me with zero experience to just read a total after school and start building a kernel.
This is similar. Building is simple, configuring is simple, packaging is simple. It has the added bonus of having people behind it, that are ALSO good researchers.
I hope that at some point they will pay for a professional audit, but it's already awesome to see where they got.
Kraft Dinner and Kraft Singles, my two favourite almost cheese products.
Names are really hard.
Absolutely nothing about this headline had me thinking about consensus protocols.