eyberg

Agreed. The vast majority of prod workloads are persistent services that we want running 24/7.

> I do wonder what kind of wins we're going to see from unikernels.

I come from security so I'm more disposed towards the benefits thereof, however, being a person that has had a commercial and open source unikernel presence for a while now - "ease of use" is probably the largest selling point that I see from most of our user base. There is nothing out there that gives you the performance, security and cost benefits from shipping your unikernels to AWS, GCP, etc. in seconds. Not lambda, not cloudflare, not any of the millions of microvm providers. You quote netlify right here (who actually don't use unikernels per-se but small little linux vms (big difference!)) but why would you even use them when you can do it cheaper by shipping straight to ec2?

That's what unikernels allow you to do.

Honestly, I think there is a lot of similarities between unikernels, at least the one I'm active with and qubes. The big difference to me is that qubes is more desktop/consumer focused and nanos (the one I'm involved with) is more server-focused but the same sort of ideology/principles gets exposed - just at varying levels and because of the end environment they get architected differently.

Reducing attack surface is definitely a plus but it is nowhere close to the number one security benefit of running unikernels.

That's why I never really liked talking about "reducing attack surface" that much because folk inevitably turn to lines and code, which while reducing is good, just simply doesn't communicate what the biggest problem truly is.

Vuln exploitation is the number one entry point for data breaches and os command injection is the number one CWE in CISA Kev from last year.

System intrusion was repeated something like 64 times in last year's DBIR.

The operating system itself is literally the problem as it's inherently meant to run many different programs whereas unikernels only run one.

Containers and security are oxymorons. The flood of page cache cves (which can always be escalated/weaponized to an escape) from the other month is making deploying containers to prod untenable.

As for orchestration - a lot of folks think you need a completely new orchestration system for dealing with vms but we just simply re-use the existing infrastructure that already exists - the public clouds. Those companies have tens of thousands of engineers that are much better than the average engineer at this stuff, custom hardware, custom protocols and close to several decades of existing deployment.

I can build and ship a vm from my laptop/ci to prod on AWS/GCP in ~tens of second. Granted I come from the camp that thinks deploying full blown general purpose operating systems to prod is an increasingly incredibly risky practice.

So first off - NVD has been sliding for a long time now. This has nothing to do with mythos. The amount of money that goes into this program for the output is straight up criminal.

For a very long time the security world has basically given up on defense and relies on prioritizing cves. This is wrong on so many different levels.

a) You can't scan for things you don't know that exist.

b) Malware, like all the supply chain issues in the past few months don't have cves to begin with but they are still massive security issues. That is to say the cves themselves don't really address everything. So you end up with IOCs but those are also totally worthless if it's the first time you are seeing something. You have to have proactive defense if you actually care.

c) There are quite a few cwes that you can outright prevent through various defensive means but for whatever reason organizations won't. This is an organizational issue - not a technical one. This might be one of the main benefits of the cve program in that it starts to penalize organizations through insurance and other means by tracking it and this is exactly how a lot of the security world operates.

I'm cautiously optimistic that the world is going to start looking at stronger proactive defensive measures rather than relying on this reactive scanning approach.

Except this is very clearly running linux.