5 ms·

The projects themselves have progressed since this article and MirageOS is doing pretty well [1]. There was also a recent HN discussion on an experiment to crea

by amirmc 12y ago

The projects themselves have progressed since this article and MirageOS is doing pretty well [1]. There was also a recent HN discussion on an experiment to create (and run) one VM per URL, which was built via MirageOS [2]. Although there are many applications of the unikernel approach, a longer term goal that I'm particularly keen to work towards is the idea of distributed personal clouds. Enabling people to run their own infrastructure, without becoming sysadmins, would be pretty cool [3]. Of course, there are other ways to achieve this but unikernels offer certain benefits. [1] http://openmirage.org http://openmirage.org (I'm involved with the project). [2] https://news.ycombinator.com/item?id=9263146 https://news.ycombinator.com/item?id=9263146 [3] http://nymote.org/blog/2015/brewing-miso-to-serve-nymote/ http://nymote.org/blog/2015/brewing-miso-to-serve-nymote/

deleted 12y ago
[deleted]
- amirmc 12y ago
  Edit: the comment I replied to has been deleted. It referred to legacy code and linked to OSv. I'll leave this comment here anyway. ----- The nice thing with multiple Unikernel approaches is that you get to choose your trade-offs. MirageOS takes a clean-slate approach and generally concerns itself with safety and security. OSv allows you to work with legacy code, and Rump Kernels help to break up the existing stacks. There are also others that have a preference for speed etc. Depending on the task at hand, you could choose whichever suits your needs/problem-domain. The upfront cost you refer to only comes from having to port legacy code. However, building new services this way doesn't carry that cost (apart from potentially learning a new language -- but I hope people see that as a useful skill, regardless).
jsprogrammer 12y ago
Regarding #3, I'm working on a project [0][1] that might be able to achieve that. It's not a direct goal of the project, but could be a subset of the primary goal. The primary goal is to be able to take a system description and be able to run it anywhere, be it public clouds or private hardware. The base image is CoreOS (so, not a uni-kernel, but still pretty sweet). You can search Docker Hub for containers and create multi-datacenter, (and soon) multi-provider clouds. I do think uni-kernels may be the way to go, but AFAICT the proper tooling just doesn't exist yet. It's still in pre-alpha, so there are many amenities that I plan to add that don't exist yet, but it will launch clouds (what I'm calling a set of related CoreOS clusters), create fleet units, and start your applications. If anyone's interested in helping work on it, let me know or send a PR. All the code is free (MIT) and on github (link on top-right of site). [0] http://www.cloud-launcher.io http://www.cloud-launcher.io [1] http://www.cloud-launcher.io?simulator http://www.cloud-launcher.io?simulator | Just a simulation; won't create machines; any credentials will be valid

by amirmc 12y ago

deleted 12y ago

[deleted]

amirmc 12y ago
Edit: the comment I replied to has been deleted. It referred to legacy code and linked to OSv. I'll leave this comment here anyway. ----- The nice thing with multiple Unikernel approaches is that you get to choose your trade-offs. MirageOS takes a clean-slate approach and generally concerns itself with safety and security. OSv allows you to work with legacy code, and Rump Kernels help to break up the existing stacks. There are also others that have a preference for speed etc. Depending on the task at hand, you could choose whichever suits your needs/problem-domain. The upfront cost you refer to only comes from having to port legacy code. However, building new services this way doesn't carry that cost (apart from potentially learning a new language -- but I hope people see that as a useful skill, regardless).

jsprogrammer 12y ago

Regarding #3, I'm working on a project [0][1] that might be able to achieve that. It's not a direct goal of the project, but could be a subset of the primary goal. The primary goal is to be able to take a system description and be able to run it anywhere, be it public clouds or private hardware. The base image is CoreOS (so, not a uni-kernel, but still pretty sweet). You can search Docker Hub for containers and create multi-datacenter, (and soon) multi-provider clouds. I do think uni-kernels may be the way to go, but AFAICT the proper tooling just doesn't exist yet. It's still in pre-alpha, so there are many amenities that I plan to add that don't exist yet, but it will launch clouds (what I'm calling a set of related CoreOS clusters), create fleet units, and start your applications. If anyone's interested in helping work on it, let me know or send a PR. All the code is free (MIT) and on github (link on top-right of site). [0] http://www.cloud-launcher.io http://www.cloud-launcher.io [1] http://www.cloud-launcher.io?simulator http://www.cloud-launcher.io?simulator | Just a simulation; won't create machines; any credentials will be valid