4 ms·
5ms happens to be a special number. NEC reports booting unikernels that fast: http://cnp.neclab.eu/projects/lightvm/lightvm.pdf http://cnp.neclab.eu/projects/l
by eyberg 7y ago
5ms happens to be a special number. NEC reports booting unikernels that fast:
http://cnp.neclab.eu/projects/lightvm/lightvm.pdf http://cnp.neclab.eu/projects/lightvm/lightvm.pdf
If you're doing NFV type of workloads fast boot time might be interesting if you are booting up and shutting down things as fast as you can, however, if you are doing traditional cloud workloads ala jvm, rails, etc. I don't know if achieving fastest time to boot makes a ton of sense - at least for those app envs it takes a while just to start and would defeat the purpose of spinning up/down. Your example of web servers typically would indicate some form of db connection taking place - even if it's just a static webserver - why need to turn on/off so fast?
I'd be interested in hearing some specific usecases cause unikernels definitely hold promise here but I don't have a ton of use-cases outside of NFV.
The low latencies that typically get a lot of us excited are the low run-time latencies and high throughput promises unikernels have.
- ignoramous 7y agoI'm interested in IPv4 in IPv6 and vice versa, TCP in UDP and so on for the data-plane. Imagine something like TailScale.com [0] but managed and not P2P, or maybe running something like Wireguard from within a unikernel. I'm not even sure if it is a valid use-case to have long-running unikernels? Also, does that count as NFV/SDN? Currently, I run the data-plane workload isolated via VMs and they are always-on, even when the traffic is non-existent. The requirement for HTTP workloads is mostly for control-plane APIs, and imo, Workers will work really well, for that. [0] https://tailscale.com https://tailscale.com