Move cloud to a unikernel on runtime.js

mollyling commented 8 years ago

Unikernels can be substantially smaller than docker images, as they avoid having a kernel or userspace filesystem at all. As an example, a Tor bridge node fits in 9MB (http://www.infoq.com/presentations/tor-haskell). There's a unikernel for javascript called runtime.js that may do what we want for this.

It's node "inspired", so perhaps we should target something that works on both.

I think @jab mentioned something on these lines.

Possible advantages:

Substantially smaller footprint could lead to using smaller VM images
Easier to scale many uproxy-cloud instances on a single box/account
Faster setup, as it's a much smaller download.
Lower network latency, as we have one less scheduling hop (hyperviser -> kernel -> process goes down to hypervisor -> process).

mollyling commented 8 years ago

ref: @trevj

jab commented 8 years ago

Very cool @mollyling! (FWIW https://mirage.io/ is the project I had come across, via this presentation which I thought was fantastic)

agallant commented 8 years ago

mirage.io is really cool (OCaml is pretty fun to work with - some similarities to Typescript actually imo, or really vice-versa), but an issue I've encountered in lightly playing with these things is the commercial hosting ecosystem isn't quite there yet. They try to make it sound easy ("just use Xen!"), but not all cloud providers use Xen, and not all Xen hosts expose the functionality needed to run your own kernel. It looks like runtime.js is actually KVM instead - not sure if that'll be better or worse in terms of hosting ecosystem compatibility, but whatever it is it'll be worse than just running Docker on Ubuntu.

Not trying to talk this down though, I think it'd be cool and definitely a good idea both from footprint and security perspective (here's a blog post that highlights this, as well as mentions a bit about the difficulty in getting hosting). And related-but-unrelated, http://nymote.org/ is a project attempting to do the whole unikernel-personal-cloud thing.

mollyling commented 8 years ago

Someone's written a shell script for HaLVM images (like mirage, but Haskell) to make them Amazon EC2 images. It's little more than making a full filesystem image with grub setup to boot to the image. https://github.com/AFDudley/ec2-halvm

On Mar 16, 2016 5:00 PM, "soycode" notifications@github.com wrote:

mirage.io is really cool (OCaml is pretty fun to work with - some similarities to Typescript actually imo, or really vice-versa), but an issue I've encountered in lightly playing with these things is the commercial hosting ecosystem isn't quite there yet. They try to make it sound easy ("just use Xen!"), but not all cloud providers use Xen, and not all Xen hosts expose the functionality needed to run your own kernel. It looks like runtime.js is actually KVM instead - not sure if that'll be better or worse in terms of hosting ecosystem compatibility, but whatever it is it'll be worse than just running Docker on Ubuntu.

Not trying to talk this down though, I think it'd be cool and definitely a good idea both from footprint and security perspective (here's a blog post that highlights this https://www.somerandomidiot.com/blog/2014/03/14/its-a-mirage/, as well as mentions a bit about the difficulty in getting hosting). And related-but-unrelated, http://nymote.org/ is a project attempting to do the whole unikernel-personal-cloud thing.

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/uProxy/uproxy/issues/2307#issuecomment-197547776

trevj commented 8 years ago

Seems like the ecosystem is not as developed as Docker right now but I can see that changing. Nice idea!

mollyling commented 8 years ago

https://github.com/rumpkernel/rumprun-packages/tree/master/nodejs

It looks like ndoejs is actually running pretty well. The rumpkernel here is actually a NetBSD kernel + C library (4MB!). So, add nodejs to that for binary size and we have something potentially quite small.

agallant commented 8 years ago

Very cool stuff - I still think the main blocking issue will be ease of deployment/cloud provider compatibility. AWS and GCE allow for custom kernels, but easier/lighter hosts like Digital Ocean are more limited. For instance, DO does support custom images, but they have to be based off their Linux templates (https://www.packer.io/docs/builders/digitalocean.html), which precludes custom kernels. I found a potential workaround (https://mescanef.net/blog/2014/06/booting-custom-kernel-in-digitalocean-vm-instance-aka-droplet/) but it would require a multistep process that would likely significantly lengthen install time.

If it gets to the point where DO (or a DO-like provider) is making it easy to push and host unikernels, then this would be a very exciting direction (as well as facilitate all sorts of other cool things). Until then, I think our main target should be slimming down cloud by getting it running on freedom-for-node (https://github.com/uProxy/uproxy/issues/587) and then possibly slimming further by switching images to Alpine (https://github.com/uProxy/uproxy/issues/2376). This could get us quite small (I'd hope <100mb) while still being compatible with more traditional Docker/Linux hosts.

agallant commented 8 years ago

Still in beta and just once service, but it does look like a commercial unikernel hosting may be budding: https://deferpanic.com/blog/gone-full-unikernel/

UWNetworksLab / uProxy-p2p

Move cloud to a unikernel on runtime.js #2307