3 ms·

I tried and failed to bring unikernels to my former work when I was at Visa. Specifically, LING. There just wasn't enough of an ecosystem of support for the tec

I tried and failed to bring unikernels to my former work when I was at Visa. Specifically, LING. There just wasn't enough of an ecosystem of support for the technology to place big bets on it for what we needed to do. That said, at my current company we recently open sourced[1] some work we did a couple years back which is more or less an attempt at the basic foundations for blending the seL4 microkernel with fairly normal no_std Rust application development and assembling them all together to make a purpose built OS/application to deploy directly to hardware or within a VM. We have some work to do to keep building it up as a foundation for broader use, but we're looking into partnering with the seL4 Foundation (now under the Linux Foundation) to iterate on it further with some of our other mutual partners. The developer experience is much closer to that of developing for an RTOS than it is like typical general purpose computing development. I'm of course biased, but I think there's a lot of room to innovate in the space of use case specific software stacks where the domain and constraints are well understood and too many degrees of freedom are actually a hindrance and a liability, not an advantage. Unikernels or otherwise. [1] https://github.com/auxoncorp/ferros https://github.com/auxoncorp/ferros

phendrenad2 5y ago
I think it's very much the 80/20 rule. You can get 80% optimal performance with 20% of the effort (just use Alpine Linux). If you want the last 20% you need to do the other 80% of the work. (Replace "performance" with "security" and it's the same story). Using unikernels isn't easy, especially with modern software development so focused on higher-level languages. Memory management is a foreign concept. The hype around Rust isn't generating low-level-capable engineers fast enough. Plus, high-level pays better.
- eyberg 5y ago
  I've never heard of performance being one of Alpine's benefits - in fact quite the opposite. There are many blogposts talking about run-time perf being dramatically slower. Also, you lose some security benefits with Alpine as well because of the use of musl. As for tooling this might've been true 4-5 years ago but I don't think it's the case anymore, but being someone that works at a unikernel company I'm clearly 100% biased. As for the scripting languages that you might be alluding to here, you are quite correct that performance has never been a strong suit with them as they are inherently shackled to single process/single thread execution. The reason why is that you could write a 2000 line ruby class named Dog and instantly rename it in one fell swoop to an integer with the value of 42. However, this is the same thing with unikernels and lots of languages such as python/ruby/node/etc. work out of the box - scaling is done differently though. Instead of firing up X app workers behind a reverse proxy you fire up X vms and put that behind a load balancer.

phendrenad2 5y ago

I think it's very much the 80/20 rule. You can get 80% optimal performance with 20% of the effort (just use Alpine Linux). If you want the last 20% you need to do the other 80% of the work. (Replace "performance" with "security" and it's the same story). Using unikernels isn't easy, especially with modern software development so focused on higher-level languages. Memory management is a foreign concept. The hype around Rust isn't generating low-level-capable engineers fast enough. Plus, high-level pays better.

eyberg 5y ago
I've never heard of performance being one of Alpine's benefits - in fact quite the opposite. There are many blogposts talking about run-time perf being dramatically slower. Also, you lose some security benefits with Alpine as well because of the use of musl. As for tooling this might've been true 4-5 years ago but I don't think it's the case anymore, but being someone that works at a unikernel company I'm clearly 100% biased. As for the scripting languages that you might be alluding to here, you are quite correct that performance has never been a strong suit with them as they are inherently shackled to single process/single thread execution. The reason why is that you could write a 2000 line ruby class named Dog and instantly rename it in one fell swoop to an integer with the value of 42. However, this is the same thing with unikernels and lots of languages such as python/ruby/node/etc. work out of the box - scaling is done differently though. Instead of firing up X app workers behind a reverse proxy you fire up X vms and put that behind a load balancer.