4 ms·
What would that look like? AFAIK, today, you can already build your unikernel app into an AMI and run it on EC2. No? Is there a service which would be more us
by twic 6y ago
What would that look like?
AFAIK, today, you can already build your unikernel app into an AMI and run it on EC2. No?
Is there a service which would be more useful for unikernels than this?
One thing would be for there to be an official AWS unikernel SDK - basically, a rump operating system that has everything you need to run nicely on EC2, and nothing else.
- pjmlp 6y agoFor example app services for language runtimes like Java and .NET.
- rjsw 6y agoAre there TCP/IP network stacks available for Java or .NET ?
- skuenzer 6y agoWith Unikraft as being a librarized unikernel system you can actually choose if the OS layer should provide you a network stack (likely written in C/C++) for your runtime or if you prefer doing it in a higher-level language. Similar to this the MirageOS folks developed a network stack in OCaml.
- pjmlp 6y agoSure, there are even bare metal deployments available for embedded development. PTC and Aicas on Java's case for example, or nanoFramework for .NET.
- skuenzer 6y agoThis is true, there are a number of embedded frameworks that you could use as well and even run it as virtual machine too. In contrast to this we want to make it as seamless as possible by still providing you the Linux-OS-like layers if you need them. The goal is that a previously developed app for Linux should be seamless to port. The OS interfaces in the higher-level language should be the same as you have it on Linux, so no code changes.
- skuenzer 6y agoYes, we have first experiments to run on AWS [1], we are currently up-streaming the left pieces so that everyone can try it by themselves. In my point of view, a main difference to rump is the finer grained modularity of our libraries. In theory every library (which implement OS primitives, like thread schedulers, heap management and APIs/ABIs (e.g., Linux-Syscall ABI) can be individually selected and replaced. This is following our specialization vision: Take only components that you need and choose the best fitting ones for your use case. This could mean that for a virtual network appliance, you may end up writing code to the virtual NIC drivers as close as possible. Basically you won't use a standard network stack or a VFS, you may even want to get rid of any noise caused by a guest-OS scheduler. [1] https://www.linux.com/news/cut-your-cloud-computing-costs-by-half-with-unikraft/ https://www.linux.com/news/cut-your-cloud-computing-costs-by...
- anonymousDan 6y agoHow maintainable do you think this is in the long run in comparison to e.g. using a Linux based unikernel? Do you think you can keep pace with the speed at which features are added to Linux?
- marcus_holmes 6y agoThis is my dream. Embed all my templates, configuration files and everything into a single static Go binary. Deploy it onto a unikernel that has basically zero attack surface because it just runs this one binary and nothing else. Connect it to a database service (via a config setting with the connection string embedded in the binary). I can almost do this on AWS at the moment, I think, though I haven't tried yet and it looks like a big learning cliff from here. Something to make this easier would be a huge win.