Comment by gavinray | Hacker News Reader

Comment by gavinray | Hacker News Reader

On the topic of Unikernels and MicroVM's:

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.

PHP & Perl come to mind. You write your program, scp it and it's dependencies to your www/cgi-bin folder on your server, and then navigate to the URL.

Yeah that's pretty much it -- "CGI, except containerized/as a single binary".

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"
      },
    ]
  }

The platform runs as a single static binary, or a JVM application (can be in a container), and it does a bunch of magic with GraalVM to convert the source code into executable functions, perform any kind of bundling/dependency library installation, etc, and finally creates the HTTP endpoints.

Check out this project: https://github.com/reddec/trusted-cgi

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.

Thank you!

Were you able to watch Waldek's talk that this links to? It's only 20min so not that long but in it he shows doing precisely this by booting 1800 instances a second.

I had a read through the repo docs, and briefly skimmed the video -- maybe I'm slow, but my understanding was that Unikernels and MicroVM's are meant to be run on bare metal?

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

But again, I have no clue about this stuff. Hence why I asked

---

tl;dr = "Can I put this in a container and give it to people to run?" I guess haha

Actually it's the opposite. Most unikernels out there are meant for vms not bare metal. Bare metal in this definition would be actual real hardware - not a base linux vm. There are a handful though do go to bare metal though.

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.

Ah, I think my mental picture of how exactly this works is very ill-formed then. Appreciate the thought-out response.

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.

Basically they are quite similar to just upload an EAR into an application server, they just have more languages to play with other than just Java.

Somehow it is kind of ironic to see how the industry goes in circles.

This is why I make the assumption that whatever thing I'm trying to accomplish has at one point been thought of, specified and executed thoroughly, and then potentially forgotten about.

I'm too young to know though.

"There's nothing new under the sun."

why wouldn't you take a vm image that boots-to-service and put in on your droplet? or give it to someone else to run? or build tooling around that (ala nanos) to make it easy to package applications this way.

i dont understand, except from a purely market position perspective why 'hypervisor images' and 'containers' are such radically different things.

If you have a workload comprised of 10x 100MB unikernels (which unikernel people love to do), do you want to run that in 10x 1GB droplets (wasting 90% of your money) or 1 droplet?

Resources, and the price per unit.

In theory you could use nested virtualization, e.g. https://jvns.ca/blog/2021/01/23/firecracker--start-a-vm-in-l...

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.

This isn't true.

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

Reply on news.ycombinator.com