I saw today this article about uni-kernels and I would like to ask:
If any member of the community have already played with uni-kernels?
Is this something where the BEAM can run on top? (sorry if I am asking something dumb here…)
It seems like the DevOps world is consistently refactoring it’s existence yet at the same time smashing into other domains of the business. Recently, security has been one of those domains creating the new discipline of DevSecOps — that is, applying DevOps principles towards security. This has created an opportunity for an obscure infrastructure paradigm to start to take hold.
Unikernels are an emerging infrastructure deployment pattern that is going in every direction very fast. What is a unikernel though? Simply put, unikernels are the equivalent of deploying your application as it’s own operating system. Since developers predominately deploy their applications on top of Linux virtual machines, unikernels are a way to package your application as it’s own virtual machine in lieu of sitting on top of something like Linux. Is it like a container? Well, there are a few definitions but the concept is relatively old.
There was LING (earlier known as Erlang On Xen) but it seems dead. Unfortunately unikernel idea was killed by containerisation (in form of Docker), however I still count that one day it will come back as an great idea it is. Right now the nearest we can get to the unikernel in BEAM world is Nerves I believe.
This is interesting - as I signed up to this forum to find out a little more about using rebar3 build tools from mix. The reason is that we have a plugin for rebar3 that takes an Erlang/OTP release and turns it into a unikernel image ready to run onto of Xen, KVM, AWS etc. I’m curious as to how to support elixir - I can see how to generate an OTP release using distillery, but the next step isn’t clear.
We’re actually using OSv and running the beam ontop of that. There are a couple of gotchas - there’s no fork() in OSv as its a true unikernel, so we use a slightly modified Erlang/OTP release (just to be included in the unikernel image, you use your normal toolchain when compiling). The rebar3_osv plugin includes a bare OSv image which is then spun up and the Erlang/OTP release pushed into it.
The result is a unikernel image which runs under a bunch of hypervisors. On startup it can use cloud-init to modified startup files, then the erlang application is started. There’s no kernel/user space split but almost everything works as you’d expect. The main missing feature is ports (which would require fork()).
