I remember studying Unikernels in college, they seemed very interesting but it felt like by 2016 or so they had already lost out to containerization as a way to package a slice of OS to run an application. It’s interesting to see them start to make a comeback in the research community!
I think one of the difficulties of unikernels is that the application has to spend a lot more effort on operability: metrics, diagnostics, debugging, all the stuff you get from running in a unix environment. Even if your container is stripped down, an operator can still in a pinch reach inside to work out what is going on.
It’s striking that this paper doesn’t have any sections on operational factors, as far as I could spot from a quick skim.
There’s a much bigger problem for unikernels: they don’t work well with cloud business models. Cloud providers like to do accouting in VCPUs and RAM GiBs. The benefit of a unikernel is that it can scale down far further than this. You can build a unikernel that runs in a few MiBs of RAM and needs a fraction of a VCPU over the course of a day.
The root problem is that they’re obsessed with catering to big customers who want (at least) hundreds of VMs, not customers who want to spend $1/year. I think that’s a huge business mistake because a company that needs thousands of nodes has the kind of economies of scale that mean that they get fairly small benefits from the cloud. In contrast, there are a lot of small companies that need less than a whole server and even more individuals who may benefit from $1-2/year of independent server.
As someone whose worked on https://nanos.org for a while now I can’t name a single one of our users/customers that utilize it in this manner.
Most of our users don’t care about things being small (in fact some of them provision very very large disks) and they have very little use for quick spin-up/spin-down times. Why? Cause practically every application they use a) takes a while to spin regardless of how fast the kernel starts (eg: something like elasticsearch or the hot new python AI framework can take tens of seconds) and b) they want it persistent and c) most clouds have single thread vms for a whopping $4/month. The whole serverless thing just doesn’t make any sense for these peoples actual use-cases.
I’ve found there is quite a large knowledge gap between people who actually use unikernels day to day vs those who talk about them on online forums. If anyone is interested in how people are actually using these things vs just reading about them online I’d highly encourage you to push one out to your preferred hosting provider. That will answer many of your questions a lot faster than reading speculation on a forum.
The benefit of a unikernel is that it can scale down far further than this. You can build a unikernel that runs in a few MiBs of RAM and needs a fraction of a VCPU over the course of a day.
This is basically the Functions-as-a-Service model, but without the extra kernel-mode complexity.
The root problem is that they’re obsessed with catering to big customers who want (at least) hundreds of VMs, not customers who want to spend $1/year. I think that’s a huge business mistake because a company that needs thousands of nodes has the kind of economies of scale that mean that they get fairly small benefits from the cloud. In contrast, there are a lot of small companies that need less than a whole server and even more individuals who may benefit from $1-2/year of independent server.
This is very true, and it’s why I think all the major cloud providers are in for a world of hurt when the big companies decide they need to start getting a little more efficient and move their workloads off of public cloud systems.
On the other hand, as stated above: this is just FaaS, and we see that the cloud providers simply increase the margin on these services proportionally such that it either costs them almost nothing or it makes them a ton of money if traffic explodes.
That is true for the server class rentals, but there’s the entire industry of serverless computing which is predicated on being able to run individual applications as compactly as possible, packed as tightly together as possible.
My understanding is that the business model of serverless is as a loss-leader, and the money is made off of the complementary goods (object stores, KV storage, databases) that developers of serverless apps end up using. In that case, the incentives to run as little as possible seems well-aligned.
there’s the entire industry of serverless computing which is predicated on being able to run individual applications as compactly as possible, packed as tightly together as possible.
I think that’s the deployment model that most (surviving) unikernels that I know try to target; I briefly worked on one of these way back and that was certainly the impression I got back then. I suspect (but I’m really out of my depth here) that the overlap between users for whom compute resource packing is that major a concern and users that can afford to manage serverless deployments at a massive scale is just small enough that this is still a niche. But the scale at which the latter operate makes it a surprisingly viable niche.
Almost all of the ‘serverless’ things are actually one VM per customer, running a Linux container with the language runtime for the function. The overhead is ludicrous. I worked with some Azure folks on possible paths to make it more efficient but there simply wasn’t the business interest because, if you could do it well, it would cannibalise the more profitable markets.
I remember studying Unikernels in college, they seemed very interesting but it felt like by 2016 or so they had already lost out to containerization as a way to package a slice of OS to run an application. It’s interesting to see them start to make a comeback in the research community!
I think one of the difficulties of unikernels is that the application has to spend a lot more effort on operability: metrics, diagnostics, debugging, all the stuff you get from running in a unix environment. Even if your container is stripped down, an operator can still in a pinch reach inside to work out what is going on.
It’s striking that this paper doesn’t have any sections on operational factors, as far as I could spot from a quick skim.
There’s a much bigger problem for unikernels: they don’t work well with cloud business models. Cloud providers like to do accouting in VCPUs and RAM GiBs. The benefit of a unikernel is that it can scale down far further than this. You can build a unikernel that runs in a few MiBs of RAM and needs a fraction of a VCPU over the course of a day.
The root problem is that they’re obsessed with catering to big customers who want (at least) hundreds of VMs, not customers who want to spend $1/year. I think that’s a huge business mistake because a company that needs thousands of nodes has the kind of economies of scale that mean that they get fairly small benefits from the cloud. In contrast, there are a lot of small companies that need less than a whole server and even more individuals who may benefit from $1-2/year of independent server.
As someone whose worked on https://nanos.org for a while now I can’t name a single one of our users/customers that utilize it in this manner.
Most of our users don’t care about things being small (in fact some of them provision very very large disks) and they have very little use for quick spin-up/spin-down times. Why? Cause practically every application they use a) takes a while to spin regardless of how fast the kernel starts (eg: something like elasticsearch or the hot new python AI framework can take tens of seconds) and b) they want it persistent and c) most clouds have single thread vms for a whopping $4/month. The whole serverless thing just doesn’t make any sense for these peoples actual use-cases.
There is quite a lot of activity in this space for persistent applications and as this paper mentions for databases - Andy Pavlo addressed this in his recent p99 talk too: https://www.p99conf.io/session/the-next-chapter-in-the-sordid-love-hate-relationship-between-dbs-and-oses/ .
I’ve found there is quite a large knowledge gap between people who actually use unikernels day to day vs those who talk about them on online forums. If anyone is interested in how people are actually using these things vs just reading about them online I’d highly encourage you to push one out to your preferred hosting provider. That will answer many of your questions a lot faster than reading speculation on a forum.
This is basically the Functions-as-a-Service model, but without the extra kernel-mode complexity.
This is very true, and it’s why I think all the major cloud providers are in for a world of hurt when the big companies decide they need to start getting a little more efficient and move their workloads off of public cloud systems.
On the other hand, as stated above: this is just FaaS, and we see that the cloud providers simply increase the margin on these services proportionally such that it either costs them almost nothing or it makes them a ton of money if traffic explodes.
That is true for the server class rentals, but there’s the entire industry of serverless computing which is predicated on being able to run individual applications as compactly as possible, packed as tightly together as possible.
My understanding is that the business model of serverless is as a loss-leader, and the money is made off of the complementary goods (object stores, KV storage, databases) that developers of serverless apps end up using. In that case, the incentives to run as little as possible seems well-aligned.
I think that’s the deployment model that most (surviving) unikernels that I know try to target; I briefly worked on one of these way back and that was certainly the impression I got back then. I suspect (but I’m really out of my depth here) that the overlap between users for whom compute resource packing is that major a concern and users that can afford to manage serverless deployments at a massive scale is just small enough that this is still a niche. But the scale at which the latter operate makes it a surprisingly viable niche.
Almost all of the ‘serverless’ things are actually one VM per customer, running a Linux container with the language runtime for the function. The overhead is ludicrous. I worked with some Azure folks on possible paths to make it more efficient but there simply wasn’t the business interest because, if you could do it well, it would cannibalise the more profitable markets.
Except the newer and “edge”-ier ones like Deno Deploy and Cloudflare Workers that use language runtime level isolation
Same perception here. Somehow they always reappear every couple of years: there is always someone enthusiastic thinking they’ll “make it work”