Great job and nice to see Romania featuring in the news!
To those who just spent the last two years retraining your teams and retooling your infrastructure explicitly for docker (who may show up in this thread embracing and enhancing with a large marketing budget shortly), do take this opportunity to learn the architectural and management/maintenance value of abstraction. ;)
VM's tend to lose the overlay layered filesystem which can dramatically reduce disk usage. Having the filesystem reset to a clean state for every new container is a huge feature of containers. And VM's tend to need predefined dedicated resources for things like memory. A process in a container would only allocate memory when it needs and can free up for other processes to use. It's not all about the startup speed.
That said, VM's have their place, and docker has the option to switch out backends. It's entirely possible to replace runc with some other tool that starts VM's instead of containers. (That's already happening today with Windows containers.)
An example for such an alternative backend would be runv, which can apparently be used with Docker (though I couldn't get it to work well, but that was probably just my fault)
Xen is very much inspired by exokernels (you could even make the argument that it is an exokernel), so it makes sense that someone would push it more in that direction.
That being said, if you're going to go that way,it's to bad that there isn't more inspiration from the past 20 years of OS design. A capability based security/object management interface would nice. I also really like Akaros's VM threads model; IMO that'll be the way we end up running what we currently call unikernels.
Unikernels are mentioned in passing, but are not the cause of the speedup. The main point of the paper is instead the introduction of "LightVM, a complete re-design of the basic Xen control plane optimized to provide lightweight virtualization".
[+] [-] contingencies|8 years ago|reply
To those who just spent the last two years retraining your teams and retooling your infrastructure explicitly for docker (who may show up in this thread embracing and enhancing with a large marketing budget shortly), do take this opportunity to learn the architectural and management/maintenance value of abstraction. ;)
[+] [-] tinco|8 years ago|reply
[+] [-] bmitch3020|8 years ago|reply
That said, VM's have their place, and docker has the option to switch out backends. It's entirely possible to replace runc with some other tool that starts VM's instead of containers. (That's already happening today with Windows containers.)
[+] [-] tilpner|8 years ago|reply
https://github.com/hyperhq/runv#run-it-with-docker
[+] [-] jpalomaki|8 years ago|reply
Could you use file system snapshots for this? Maybe also for the layers?
[+] [-] monocasa|8 years ago|reply
That being said, if you're going to go that way,it's to bad that there isn't more inspiration from the past 20 years of OS design. A capability based security/object management interface would nice. I also really like Akaros's VM threads model; IMO that'll be the way we end up running what we currently call unikernels.
[+] [-] CalChris|8 years ago|reply
Agreed and seL4 comes to mind. It's capability based, quite fast and secure. For that matter, it's also quite small.
[+] [-] Rusky|8 years ago|reply
[+] [-] jeromegn|8 years ago|reply
[+] [-] mapsnapps|8 years ago|reply
[+] [-] tyingq|8 years ago|reply
[+] [-] wkz|8 years ago|reply
[+] [-] lbotos|8 years ago|reply
[+] [-] est|8 years ago|reply
https://lwn.net/Articles/644675/
[+] [-] ConfucianNardin|8 years ago|reply
It doesn't help that the name was already in use (by a minimal X11 server).
[+] [-] citrin_ru|8 years ago|reply
One problems with unikernels is a lack of debugging/tracing tools (like Dtrace/eBPF): https://www.joyent.com/blog/unikernels-are-unfit-for-product...
[+] [-] nickik|8 years ago|reply
See discussions here: https://news.ycombinator.com/item?id=10953766
[+] [-] davidthewatson|8 years ago|reply
http://www.zerovm.org/
[+] [-] burgerdev|8 years ago|reply
[+] [-] detaro|8 years ago|reply
[+] [-] unknown|8 years ago|reply
[deleted]
[+] [-] nwrk|8 years ago|reply
[+] [-] grabcocque|8 years ago|reply
[+] [-] detaro|8 years ago|reply
[+] [-] detaro|8 years ago|reply
[+] [-] sctb|8 years ago|reply
[+] [-] michaelmior|8 years ago|reply
[+] [-] robert_foss|8 years ago|reply
[+] [-] bildung|8 years ago|reply
[+] [-] equalunique|8 years ago|reply
[+] [-] metalliqaz|8 years ago|reply
[+] [-] sitkack|8 years ago|reply
[+] [-] debpoulami_123|8 years ago|reply
[deleted]