Comments URL: https://news.ycombinator.com/item?id=49452990

Points: 651

# Comments: 124

The challenge they encountered was at a different layer: horizontally scaling the underlying EC2 infrastructure. At the time, native EC2 fleet autoscaling wasn't yet supported by the platform, so they chose to take ownership of that part of the stack and build directly on Firecracker.

It's also worth noting that Unikraft is actively working on transparent infrastructure autoscaling (with live migration), so the gap they encountered is being addressed. The article's title may give the impression that unikernels were the bottleneck (they weren’t, and our platform transparently support Linux VMs as well), when in reality the decision was driven by infrastructure orchestration requirements rather than browser runtime capabilities.

As an aside, we love Browser-Use <3 and we still work together closely!

Comments URL: https://news.ycombinator.com/item?id=47979474

Points: 4

# Comments: 0

https://github.com/unikraft/cli

Feedback is very much appreciated, we're listening! :)

Unikraft aims to offer a Linux-compatible environment (so it feels familiar) with the ability to strip out unnecessary internal components in order to improve both boot-time/runtime performance and operational security.

Why would you need a memory allocator and garbage collector if you serve static content? Why would you need a scheduler if your app is run-to-completion?

Linux gives you the safety-net of generality and if you want to do anything remotely performant, you by-pass/hack it altogether.

In the article, Unikraft cold-boots in 150ms in an emulated environment (TCG). If it was running natively with virtualization hardware extensions, it can be even shorter, and without the need for snapshots which means you don't need to store this separately either.

Comments URL: https://news.ycombinator.com/item?id=41078350

Points: 2

# Comments: 3

It looks still very early days in terms of supporting all libc/syscalls as well as support for different platforms.

I wonder how this compares in terms of performance to https://unikraft.org which is able to do the same but is a more establish libOS/unikernel project (disclosure I am a maintainer of Unikraft :-)) since this is written in Zig and Unikraft is written in C.

Thanks for the feedback!

Good point on the Kraftfile syntax and as you've seen, there is a reference document. We can make sure to place a link to this in all guides.

The term "KraftCloud Specification" is in fact incorrect, this should just be "`Kraftfile` specification".

We are working on providing a "Unikraft Hub". Since unikraft.org is a public OCI registry and it works through many popular tools like `crane` or `regtool` as well as our native `kraft` CLI tool; you can actually view it locally by running `kraft pkg ls --all --apps --remote`.

Thanks again for the feedback! We'll get on to updating the docs to make these bits clearer!

We have built kraft.cloud, a millisecond cloud platform, where apps and services cold start, scale to zero and autoscale in milliseconds, ensuring you never pay for idle, can efficiently cope with traffic peaks, and don’t have to deal with complex cold start issues.

As of today we are now in open early access!

The platform (and we) come from research in the area of lightweight virtualization — trying to ask the question of how efficient cloud platforms could (or should) be while still retaining strong, hardware-level isolation. KraftCloud is the result of this research followed by years of building the Unikraft open source project (www.unikraft.org).

KraftCloud is based on unikernels, extremely specialized virtual machines, built on top of the Linux-API compatible Unikraft project. If you’ve heard of unikernels in the past, you’ve likely come across properties like millisecond cold start, small memory consumption, and small TCB, to name a few. You may have also heard of downsides like difficulty using them, debugging them, monitoring them or deploying them in the cloud — we’ve been hard at work tackling these issues.

KraftCloud leverages Unikraft unikernels, but also comes with a custom-built controller that can be reactive in millisecond scales and can scale to thousands of instances on a single server. We also have integrations with Dockerfiles, Terraform and Kubernetes, and the ability to deploy within hyperscaler infra. The end result is a platform where

- Cold starts take milliseconds (e.g., NGINX boots in 15ms)

- Scale to Zero (and scale back up) also takes milliseconds

- Autoscale takes milliseconds so you can transparently cope with fast peaks

- We can put 1000s of instances on a single server, reducing cost and carbon footprint

We’re in open early access and are actively handing (free) access tokens via the sign up form here: http://kraft.cloud/signup

We would really appreciate as much feedback as humanly possible: what you like, what you don’t like, what isn’t clear, what we’re missing, what’s broken, etc (you can find more information in our FAQs: https://unikraft.io/faq, or this blog post: https://unikraft.io/blog/kraftcloud/

Thanks so much for reading all the way to the end and looking forward to your comments!

Comments URL: https://news.ycombinator.com/item?id=40441629

Points: 7

# Comments: 5

This paper argues that when you build a extremely minimal kernel (i.e. ditch Linux entirely) and link your application against necessary bits of code to execute _as_ a VM, then you'll get better performance than a container and you'll get that isolation.

This is in fact true based on performance studies, the follow up paper to this shows so: https://arxiv.org/pdf/2104.12721

(Disclosure, co-author of the linked paper.)

We ended up taking this to real workloads if you want to see it in action: https://unikraft.io/

Check it out in our docs: https://docs.kraft.cloud/guides/traefik/

It's also possible to start traefik and other services together using Compose files: https://docs.kraft.cloud/guides/features/compose/

You can, and we've written about the differences also, here [0].

The summary is that there is still a performance hit for boot time (100s of milliseconds to seconds vs. 1 to 100 of milliseconds for Unikraft); performance hit at runtime (even removing the syscall boundaries has a less-than-ideal impact based on previous studies); and, there's extra bloat from the image size itself (the image is still at the very least 30MB+ vs. as little as 100KB for Unikraft) which affects startup time and cost of storage + transport.

[0]: https://unikraft.io/blog/ukl-vs-unikraft

Comments URL: https://news.ycombinator.com/item?id=39916578

Points: 4

# Comments: 0

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.

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

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)

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).