> I think because they play very nicely with legacy software, without needing any modifications. i.e the demo has unmodified, off-the-shelf versions of nginx, mysql and php.
That's a good argument but seems to be one for rump being the past's future (unikernel-ifying legacy applications) rather than for it being the future itself.
I do see what you mean but asking people to re-write all the things isn't a successful strategy to achieve mass adoption.
Being able to build your unikernel (micro)services using legacy things and then swapping out certain services for clean-slate versions seems like a much more palatable approach. This is why unikernels fit so well with the microservices approach — you only have to re-write things one piece at a time if you choose to.
> Being able to build your unikernel (micro)services using legacy things and then swapping out certain services for clean-slate versions seems like a much more palatable approach. This is why unikernels fit so well with the microservices approach — you only have to re-write things one piece at a time if you choose to.
That's kind of my point, in that worldview rump kernels are not really the future they're a transitional phase bridging the present and the future.
you can't ignore "legacy" applications if your new technology needs acceptance and deployment first and foremost to get out of the toy stage.
besides, think of all the future cool stuff you can more easily build on top of rump kernel (almost a year in the IRC channel and I still can't recall how I'm supposed to refer to...it) rather than being "stuck" with just Erlang on LINC or Haskell on HalVM etc.
I'm not saying you can ignore legacy applications but "the future" implies it's the goal. If rump is only for legacy application until they're reworked or replaced it's not the future, it's a transitional tool, and the future doesn't contain rump.
That's a good argument but seems to be one for rump being the past's future (unikernel-ifying legacy applications) rather than for it being the future itself.