6 ms·

KraftCloud

121 points by ashvardanian 3y ago

shaqbert 3y ago
This is related to an earlier post [0] and shows the underlying open-source repo. [0]: https://news.ycombinator.com/item?id=39902949 https://news.ycombinator.com/item?id=39902949
- nderjung 3y ago
  Hi, Alex here from Unikraft, that's right! You can find more information about Unikraft here: - https://unikraft.io https://unikraft.io -- The Unikraft Company - https://unikraft.org https://unikraft.org -- The open-source project - https://kraft.cloud https://kraft.cloud -- The Millisecond Cloud Platform based on Unikraft
west0n 3y ago
Looks like microVM.
- adhamsalama 3y ago
  And Kraft (Kafka without Zookeeper).
  - fhuici 3y ago
    Yes, our kraft CLI tool (https://github.com/unikraft/kraftkit/ https://github.com/unikraft/kraftkit/) definitely has a clash with KRaft .
- bastawhiz 3y ago
  That's a giant stretch. Kraft is a surname. I assumed it was an April fools joke that Kraft the cheese company was making their own cloud (which would be hilarious).
  - doubled112 3y ago
    I jumped to Kraft Dinner and wondered why that was the kind of perception you’d want to cause people to have about your product. Kraft Dinner and Kraft Singles, my two favourite almost cheese products. Names are really hard.
  - fhuici 3y ago
    I wonder whether we could get Kraft to sponsor us :) . Unikraft used to be called Unicraft but was changed to a "k" for name clash reasons. Agree that names are hard.
- moooo99 3y ago
  Kraft is just a the German word for strength or force.
- jagged-chisel 3y ago
  Sounds like craft. Seems more likely to me an intentional misspelling of “craft” or related to the Kraft Foods company if you’re in the US. Absolutely nothing about this headline had me thinking about consensus protocols.
  - pelasaco 3y ago
    LOL. Kraft is german for power/strength.
    - fhuici 3y ago
      Yes, we're a German company, it's a play on words :)
    - jagged-chisel 3y ago
      I caught on to that immediately. My statement was meant to mean that it would so so unlikely to indicate the Raft protocol, that it’s more likely to have been a reference to these other things. It is not a reference to those things, but it even less of a reference to Raft.
- karolist 3y ago
  The parent is downvoted because the original comment contained some stretch logic talking about possible confusion with Raft consensus protocol due to naming similarities, the current comment is after the ninja edit.
j16sdiz 3y ago
Another unikernel. I wonder how mature is that.
- checker659 3y ago
  Unikraft has been around for a while I think.
- sumtechguy 3y ago
  Also what is the particular use case here? Why use it over one of the other kernels out there? I see a lot of 'safe' and 'modern' but nothing showing how it is better/worse than the competition. What are the trade offs here? What do you get with this kernel and what is missing?
  - nderjung 3y ago
    Hi, [disclaimer, I am a project maintainer]. 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).
plz-remove-card 3y ago
Was totally expecting this to be about the Kraft food company creating their own cloud service as an April fools joke.
- pryelluw 3y ago
  Their dev kit would include a Mac and cheese.
- JosephRedfern 3y ago
  Oddly enough, I was wondering if this project for some reason came from Unilever -- the logo is quite similar!
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).
robbyiq999 3y ago
Cynically awaiting an open sourced internal google product dealing with unikernel management and scaling which is woefully complex, utilizes its own nomenclature for simple concepts like 'input' and 'output'. Becomes foundational to can-you-even-scale-bro job interviews. Appears on every bootcampers resume. Now each job posting requires 10 years of experience in it which is more or less organizing its nonsensical convoluted yaml files.

121 points by ashvardanian 3y ago

This is related to an earlier post [0] and shows the underlying open-source repo. [0]: https://news.ycombinator.com/item?id=39902949 https://news.ycombinator.com/item?id=39902949

nderjung 3y ago
Hi, Alex here from Unikraft, that's right! You can find more information about Unikraft here: - https://unikraft.io https://unikraft.io -- The Unikraft Company - https://unikraft.org https://unikraft.org -- The open-source project - https://kraft.cloud https://kraft.cloud -- The Millisecond Cloud Platform based on Unikraft

west0n 3y ago

Looks like microVM.

adhamsalama 3y ago
And Kraft (Kafka without Zookeeper).
- fhuici 3y ago
  Yes, our kraft CLI tool (https://github.com/unikraft/kraftkit/ https://github.com/unikraft/kraftkit/) definitely has a clash with KRaft .
bastawhiz 3y ago
That's a giant stretch. Kraft is a surname. I assumed it was an April fools joke that Kraft the cheese company was making their own cloud (which would be hilarious).
- doubled112 3y ago
  I jumped to Kraft Dinner and wondered why that was the kind of perception you’d want to cause people to have about your product. Kraft Dinner and Kraft Singles, my two favourite almost cheese products. Names are really hard.
- fhuici 3y ago
  I wonder whether we could get Kraft to sponsor us :) . Unikraft used to be called Unicraft but was changed to a "k" for name clash reasons. Agree that names are hard.
moooo99 3y ago
Kraft is just a the German word for strength or force.
jagged-chisel 3y ago
Sounds like craft. Seems more likely to me an intentional misspelling of “craft” or related to the Kraft Foods company if you’re in the US. Absolutely nothing about this headline had me thinking about consensus protocols.
- pelasaco 3y ago
  LOL. Kraft is german for power/strength.
  - fhuici 3y ago
    Yes, we're a German company, it's a play on words :)
  - jagged-chisel 3y ago
    I caught on to that immediately. My statement was meant to mean that it would so so unlikely to indicate the Raft protocol, that it’s more likely to have been a reference to these other things. It is not a reference to those things, but it even less of a reference to Raft.
karolist 3y ago
The parent is downvoted because the original comment contained some stretch logic talking about possible confusion with Raft consensus protocol due to naming similarities, the current comment is after the ninja edit.

j16sdiz 3y ago

Another unikernel. I wonder how mature is that.

checker659 3y ago
Unikraft has been around for a while I think.
sumtechguy 3y ago
Also what is the particular use case here? Why use it over one of the other kernels out there? I see a lot of 'safe' and 'modern' but nothing showing how it is better/worse than the competition. What are the trade offs here? What do you get with this kernel and what is missing?
- nderjung 3y ago
  Hi, [disclaimer, I am a project maintainer]. 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).

plz-remove-card 3y ago

Was totally expecting this to be about the Kraft food company creating their own cloud service as an April fools joke.

pryelluw 3y ago
Their dev kit would include a Mac and cheese.
JosephRedfern 3y ago
Oddly enough, I was wondering if this project for some reason came from Unilever -- the logo is quite similar!

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

robbyiq999 3y ago

Cynically awaiting an open sourced internal google product dealing with unikernel management and scaling which is woefully complex, utilizes its own nomenclature for simple concepts like 'input' and 'output'. Becomes foundational to can-you-even-scale-bro job interviews. Appears on every bootcampers resume. Now each job posting requires 10 years of experience in it which is more or less organizing its nonsensical convoluted yaml files.