What I want to do first is basically a portability experiment. I've done nothing hands-on yet so my apologies for sounding like an idiot. Can this be done?
This is all good exploration -- no question is too basic when it comes to unikernel deployment (where features you might expect be available simply aren't because the appropriate library hasn't been constructed yet -- but can be done so increasingly easily).
1 - Create a workload. A web service is good, but anything that I can test both locally and in the cloud will do. Is something ready-rolled on OPAM?
Two things to check in one are: - the self-hosting websites: `opam install mirage-www` and then checkout https://github.com/mirage/mirage-www and build it in DHCP/Xen mode (cd src && DHCP=1 mirage configure --xen && make). 2 - Move the workload from a personal device to the cloud. I don't want to use configuration management tools. I want to move the local software stack to a remote provider. * local architecture - cubiboard * remote architecture - AWS I see work has been done here, but I'm not sure how much Xen homogenizes the platforms.
There is an interesting thing to do here. There is an automated GitHub workflow for building x86 unikernels right now; see :
What these do is to turn the source code repositories into deployment repositories like:
You *could* make it such that an ARM Cubie builds an ARM equivalent and uploads both unikernels to the same deployment repo. Then you just need some way to spin up both the ARM kernels (locally) and the x86 kernels (on the cloud) and use a DNS server to redirect you appropriately.
Magnus Skjegstad and I are working on the DNS bits for local->remote redirection. I'll drop a mail here when that's done, but you can just do it manually through DNS assignment for now.
3 - Automate the process. Build an orchestrator into the workload (so the workload transfers itself) or into a privileged space that can see the workload.
If this is OK, I can move onto next steps.
A while ago I experimented with a Dreamplug and a LAMP stack. The journey was littered with device driver issues. The end result was slow and not portable.
Yeah, here the problem shifts to one of orchestration, which is much more tractable I think.
-anil | 
