Comment by nderjung | Hacker News Reader

Comment by nderjung | Hacker News Reader

One way to reduce compute costs significantly is by using a much lighter stack. Typical deployments to the cloud are based on the traditional OS model, and more often than not are a container-in-a-VM solution to deploy some service. The reality here is that there is so much unused, unnecessary and wasted compute resources. Why deploy a full OS and kernel which will only ever serve static web content, for example. And then there's the attack surface that comes with a full OS, running additional services like SSH which may only ever be used once.

Major vendors like Amazon and Google are happy to provide this to anyone and with simple on-boarding, but, as is clear in the article, it's expensive. With Unikraft[0], you can completely re-package your application as a unikernel, automatically. It's a single VM image and does nothing more than just running the application. It boots straight to the main application, it doesn't have a shell, and has nothing else running along side it. The result is a huge cost saving (up to 50%), since you're no longer having to pay for these extra resources just to run the a full traditional OS image plus your application.

[0]: https://unikraft.io

Maybe you should also mention that you are affiliated with this project. This reads like an ad.

Whoops :) Yes I am affiliated, I can't update my comment but I'll make sure to indicate this if/when I write a comment which discusses anything about Unikraft.

The V8 isolates used by Deno Deploy and Cloudflare Workers are also promising in that regard. It doesn‘t get much lighter then that.

It's really cool work the folks at CloudFlare are working on. The trade-off there though is that it's still a process isolated by the OS and so relies on OS-level security via the use of syscalls. Even if context-switching is reduced with Deno, making privileged calls to, say for instance `open()` or `socket()`, still impose wasted CPU cycles as the OS checks whether the process is allowed to perform this action. With unikernels, the call is allowed (and no extra CPU cycles / instructions are called) since the unikernel is its own VM and is isolated by physical hardware separation.

50% compared to what? AWS EC2? Lambda? Google Cloud Run?

Those sort of numbers without even having a pricing page give me 0 confidence sorry.

We are launching a pricing page in the next month as we are gearing up for launch :)

One example of recieving a 50% cost saving is from Amazon Machine Images (AMIs). We compared the cheapest official NGINX AMI available on the Amazon Marketplace[0] and then also ran an NGINX+Unikraft AMI. We ran the same workload using wrk[1] and then checked the bill at the end of the month, roughly $80 vs $40.

[0]: https://aws.amazon.com/marketplace/pp/prodview-xogyq23b3mfge

[1]: https://github.com/wg/wrk

Really?

Most of the costs for using the NGINX AMI + t2.nano come from software (0.29/hr), not EC2 (0.006/hr).

That's like the worst instance you could pick to prove anything about the performance of your platform. At most you're telling me your AMI costs half of NGINX's... Which still is a lot more than just running Ubuntu with a free AMI.

This is true, but the same principle applies to EC2 instance. We also tried renting an m3.medium and installed Debian+NGINX on one and Unikraft+NGINX on another and experienced the same cost savings with, in addition, twice the performance (roughly 12K req/s vs. 26K req/s).

i've always thought this is collecting pennies in front of a steam roller: you save 50% only to go out of business when a black swan hits and you can't debug an issue in production in any way. i guess this changed?

There are many ways to debug unikernels in production, particularly, we have in-kernel monitoring (e.g. ability to enable fine-grain memory, scheduling, and resource monitors. These work also any included libraries). You can also produce flame-graphs of the entire unikernel image which show the entire kernel stack and the application. There is also remote GDB support (which come with additional scripting tools for automation) for debug-images which are built along-side the production image.

Reply on news.ycombinator.com