OSv Unikernel – Optimizing Guest OS to Run Stateless and Serverless Apps
p99conf.io
p99conf.io
That said, at my current company we recently open sourced[1] some work we did a couple years back which is more or less an attempt at the basic foundations for blending the seL4 microkernel with fairly normal no_std Rust application development and assembling them all together to make a purpose built OS/application to deploy directly to hardware or within a VM. We have some work to do to keep building it up as a foundation for broader use, but we're looking into partnering with the seL4 Foundation (now under the Linux Foundation) to iterate on it further with some of our other mutual partners. The developer experience is much closer to that of developing for an RTOS than it is like typical general purpose computing development.
I'm of course biased, but I think there's a lot of room to innovate in the space of use case specific software stacks where the domain and constraints are well understood and too many degrees of freedom are actually a hindrance and a liability, not an advantage. Unikernels or otherwise.
As for tooling this might've been true 4-5 years ago but I don't think it's the case anymore, but being someone that works at a unikernel company I'm clearly 100% biased.
As for the scripting languages that you might be alluding to here, you are quite correct that performance has never been a strong suit with them as they are inherently shackled to single process/single thread execution. The reason why is that you could write a 2000 line ruby class named Dog and instantly rename it in one fell swoop to an integer with the value of 42. However, this is the same thing with unikernels and lots of languages such as python/ruby/node/etc. work out of the box - scaling is done differently though. Instead of firing up X app workers behind a reverse proxy you fire up X vms and put that behind a load balancer.
Does anyone who knows this stuff, know if there is something like Docker, but lightweight (capable of running thousands of processes with couple hundred MB memory) and doesn't require being deployed on bare-metal or an orchestration tool?
I was looking for the equivalent of IE Knative/OpenFaaS, without needing Kubernetes or k3d. Users can write functions/handlers in whatever language, and deploy them on the platform, and the whole thing is either run as something as convenient as a container or a single static binary.
I tried to find something, read up on Firecracker, emailed some people a lot smarter than me. Nothing fitting this bill seemed to exist, so I opted to build my own using GraalVM.
(Which is working, but isn't as flexible about application packaging as a Dockerfile. It imposes some restrictions on how things need to be written to deploy on my platform.)
Just curious if something like this DOES exist and I just didn't manage to find it. Building something yourself is always the worst answer, unless you're smarter than everyone in your field. Or you know something other people don't.
Which I am not/do not.
I guess I could make a Docker image that had a CGI-compliant server and an admin endpoint where you POST'ed file contents?
The current design I went with is that you upload a .zip or .tar.gz file that contains a "manifest.json" and then your source code.
The "manifest.json" points to the entrypoint file for each function you want to deploy, and says what HTTP endpoint it should live at, and what language it is.
It supports JS/TS, Python, Ruby, WASM, and LLVM langs (C/C++/Rust/Swift/Haskell/etc):
{
"version": 1,
"handlers": [
{
"name": "javascript-signup",
"language": "JAVASCRIPT",
"endpoint": "/api/signup",
"entrypoint_file": "src/signup.js"
},
{
"name": "python-login",
"language": "PYTHON",
"endpoint": "/api/login",
"entrypoint_file": "src/login.py"
},
]
}
I’d say the base is CGI + chroot, and then you grow over this base.
If you want to rebuild AWS Lambda, though, check their documentation on custom runtimes and some “how to make your own docker using cgroups” guides.
Firecracker is used to improve workload/tenant isolation, but if all you’re running is trusted, you might skip this part.
IE, OSv is not something I would put on my $5 Digital Ocean droplet, or use to run a general application. As opposed to something like, a Golang/Rust binary, or a Docker Container. I was looking for something I could give to users to let them self-host this Function-as-a-Service platform. Whether that's locally on their laptop for testing, or running somewhere as a cloud service (but probably as a very cheap one).
When I asked the founder of a container-based startup about whether Firecracker would be useful for a scenario like this replacing Docker, he told me:
"... this confuses me a bit as they are very different things. Firecracker is a hypervisor to run MicroVM's (IE: hardware virtualization)"
---
tl;dr = "Can I put this in a container and give it to people to run?" I guess haha
What is confusing to a lot of people that haven't deployed these things yet is there is no traditional user-land they are familiar (eg: ssh in and run lots of things) with so then the question of 'orchestration' comes up. If you're deploying to the public cloud or your digital ocean instance they are typically deployed as vms and push the orchestration onto the cloud provider of choice that way you don't have to manage networking/storage/etc. It's actually very straight-forward - we can deploy them to AWS in tens of seconds for instance.
Your friend is not incorrect though. If you want to own the "orchestration" layer you'll want/need to put it on bare metal. This is for performance reasons as even nested virtualization is slow and if you are going for the unikernel performance benefit it would get removed.
As for throwing it in a container - technically you can but it's an extra layer that most people wouldn't do in actual practice.
Maybe I ought to do more reading in this area. Based on what you're saying, it sounds like there is a possibility to target them towards this usecase.
Somehow it is kind of ironic to see how the industry goes in circles.
I'm too young to know though.
"There's nothing new under the sun."
i dont understand, except from a purely market position perspective why 'hypervisor images' and 'containers' are such radically different things.
In general public clouds don't play well with unikernels because they can't/won't support microVMs and/or their control plane overhead swamps the boot time benefit. You can always build your own orchestration system on bare metal but then you have an inner platform.
Both https://nanos.org and https://ops.city are Go unikernels running on Google Cloud. (I'm with NanoVMs that is the maintainer of these projects.)