6 ms·

Big upvotes for this article. I'm glad it was written, because I've seen nothing but hype for Unikernels on Hacker News (and in ACM, etc.) for the last 2 years

by chubot 11y ago

Big upvotes for this article. I'm glad it was written, because I've seen nothing but hype for Unikernels on Hacker News (and in ACM, etc.) for the last 2 years. It's great to see the other side of the story. The biggest problem with Unikernels like Mirage is the single language constraint (mentioned in the article). I actually love OCaml, but it's only suitable for very specific things... e.g. I need to run linear algebra in production. I'm not going to rewrite everything in OCaml. That's a nonstarter. An I entirely agree with the point that Unikernel simplicity is mostly a result of their immaturity. A kernel like seL4 is also simple, because like unikernels, it doesn't have that many features. If you want secure foundations, something like seL4 might be better to start from than Unikernels. We should be looking at the fundamental architectural characteristics, which I think this post does a great job on. It seems to me that unikernels are fundamentally MORE complex than containers with the Linux kernel. Because you can't run Xen by itself -- you run Xen along with Linux for its drivers. The only thing I disagree with in the article is debugging vs. restarting. In the old model, where you have a sys admin per box, yes you might want to log in and manually tweak things. In big distributed systems, code should be designed to be restarted (i.e. prefer statelessness). That is your first line of defense, and a very effective one.

justincormack 11y ago
Running unikernels on SEL4 is a perfectly sane thing to do. SEL4 does not provide the network stack, or much application interface, so a unikernel is a great thing to put on top.
- tonyhb 11y ago
  This would be awesome. Running unikernels on top of a formally verified layer sounds really interesting.
- hinkley 11y ago
  I really do feel like at the end of this container experiment we're going to reinvent microkernels. Possibly badly, but I'm hopeful that it won't work out that way.
  - pjmlp 11y ago
    Same here.
_wmd 11y ago
> The biggest problem with Unikernels like Mirage is the single language constraint Do you write all your software in C? Of course not. The single language constraint doesn't exist, for the same reasons we can write Go software that runs on the Linux kernel
- lmm 11y ago
  Non-C programs on Linux either implement the C ABI (or the Linux system call interface) or run via interpreters that do. Can your preferred language link to the OCaml ABI? Do you have an interpreter written in OCaml for it?
  - Guvante 11y ago
    Are we talking about microservices that talk over TCP of some sort? If that is the case it is a moot point as the other end need not even compile against a unikernel at all, it can sit on a traditional OS.
    - nickpsecurity 11y ago
      Exactly. They seem to be creating unsolvable, strawman problems instead of assuming we start with the middleware approach to getting things to work together. And there's both very efficient and very robust tooling available for that these days.
    - lmm 11y ago
      No, we're talking about running things under unikernels. I mean yes, you could have some of your app implemented in OCaml and then it talks over TCP to some Fortran running on Linux to do linear algebra, but that approach has its own problems.
      - Guvante 11y ago
        You are splitting the problem at the wrong place. Microservices is a well known thing and is what is providing the fire under unikernel research, you cannot simply ignore the aspect of "do the hard thing in a different environment" when talking about microservices.
bahamat 11y ago
> The only thing I disagree with in the article is debugging vs. restarting. In the old model, where you have a sys admin per box, yes you might want to log in and manually tweak things. In big distributed systems, code should be designed to be restarted (i.e. prefer statelessness). That is your first line of defense, and a very effective one. But if you never understand why it was a bad state in the first place you're doomed to repeat it. Pathologies need to be understood before they can be corrected. Dumping core and restarting a process is sometimes appropriate. But some events, even with stateless services, need in-production, live, interactive debugging in order to be understood.
- Guvante 11y ago
  > But some events, even with stateless services, need in-production, live, interactive debugging in order to be understood. The question then becomes if it is reproducible since "debuggable when not running normally" seems to be the common thread of unikernels, such as being able to host the runtime in Linux directly rather than on a VM. I think it if you try a low level language these kinds of things are going to bite you, but a fleshed out unikernel implementation could be interesting for high level languages, since they typically don't require the low level debugging steps in the actual production environment. In either case unikernels have a lot of ground to cover before they can be considered for production.
- vidarh 11y ago
  You don't need to be able to log in to be able to support a remote debugging stub, though.
nickpsecurity 11y ago
" I'm glad it was written, because I've seen nothing but hype for Unikernels on Hacker News (and in ACM, etc.) for the last 2 years. " That much is true. I'm countering what I can where it gets overblown. Just part of something going mainstream... crowd effects and so on... "The only thing I disagree with in the article is debugging vs. restarting. In the old model, where you have a sys admin per box, yes you might want to log in and manually tweak things. In big distributed systems, code should be designed to be restarted (i.e. prefer statelessness). That is your first line of defense, and a very effective one." Additionally, there's no inherent reason that I see that unikernels are impossible to debug. We can debug everything from live hardware up to apps with existing tooling. So, if unikernels are lacking, it just means they're still young and nobody has adapted proven techniques to debugging them. I imagine the simple ones on simpler HW will make that even easier.
- chris_wot 11y ago
  Apparently, you can't Google search for them: https://twitter.com/bcantrill/status/690580959981211648 https://twitter.com/bcantrill/status/690580959981211648 #enoughsaid
  - nickpsecurity 11y ago
    Enough said about what? That there's no current debugging (my claim) or that it's impossible (his)? "Now, could one implement production debugging tooling in unikernels? In a word, no" That's a lie: you could implement it. Debugging has been implemented for everything from ASIC's to kernel mode to apps in other categories. Whether unikernel crowd wants to or will is another question. Not looking good there per Google. Him talking like it's impossible shows he has an agenda, though. I'm guessing he didn't tell everyone to ditch the entire concept of Joylent's offering early on because they were lacking some important features or properties. Just a guess but I'd bet on it. EDIT: Changing search terms to "debugging" "xen" "guests" got me two results showing foundations are already built. Weak compared to UNIX but there. https://www.kernel.org/doc/ols/2006/ols2006v2-pages-9-24.pdf https://www.kernel.org/doc/ols/2006/ols2006v2-pages-9-24.pdf http://www-archive.xenproject.org/files/xensummitboston08/Mukesh%20xendbg-present.pdf http://www-archive.xenproject.org/files/xensummitboston08/Mu...

by chubot 11y ago

justincormack 11y ago

Running unikernels on SEL4 is a perfectly sane thing to do. SEL4 does not provide the network stack, or much application interface, so a unikernel is a great thing to put on top.

tonyhb 11y ago
This would be awesome. Running unikernels on top of a formally verified layer sounds really interesting.
hinkley 11y ago
I really do feel like at the end of this container experiment we're going to reinvent microkernels. Possibly badly, but I'm hopeful that it won't work out that way.
- pjmlp 11y ago
  Same here.

_wmd 11y ago

> The biggest problem with Unikernels like Mirage is the single language constraint Do you write all your software in C? Of course not. The single language constraint doesn't exist, for the same reasons we can write Go software that runs on the Linux kernel

lmm 11y ago
Non-C programs on Linux either implement the C ABI (or the Linux system call interface) or run via interpreters that do. Can your preferred language link to the OCaml ABI? Do you have an interpreter written in OCaml for it?
- Guvante 11y ago
  Are we talking about microservices that talk over TCP of some sort? If that is the case it is a moot point as the other end need not even compile against a unikernel at all, it can sit on a traditional OS.
  - nickpsecurity 11y ago
    Exactly. They seem to be creating unsolvable, strawman problems instead of assuming we start with the middleware approach to getting things to work together. And there's both very efficient and very robust tooling available for that these days.
  - lmm 11y ago
    No, we're talking about running things under unikernels. I mean yes, you could have some of your app implemented in OCaml and then it talks over TCP to some Fortran running on Linux to do linear algebra, but that approach has its own problems.
    - Guvante 11y ago
      You are splitting the problem at the wrong place. Microservices is a well known thing and is what is providing the fire under unikernel research, you cannot simply ignore the aspect of "do the hard thing in a different environment" when talking about microservices.

bahamat 11y ago

> The only thing I disagree with in the article is debugging vs. restarting. In the old model, where you have a sys admin per box, yes you might want to log in and manually tweak things. In big distributed systems, code should be designed to be restarted (i.e. prefer statelessness). That is your first line of defense, and a very effective one. But if you never understand why it was a bad state in the first place you're doomed to repeat it. Pathologies need to be understood before they can be corrected. Dumping core and restarting a process is sometimes appropriate. But some events, even with stateless services, need in-production, live, interactive debugging in order to be understood.

Guvante 11y ago
> But some events, even with stateless services, need in-production, live, interactive debugging in order to be understood. The question then becomes if it is reproducible since "debuggable when not running normally" seems to be the common thread of unikernels, such as being able to host the runtime in Linux directly rather than on a VM. I think it if you try a low level language these kinds of things are going to bite you, but a fleshed out unikernel implementation could be interesting for high level languages, since they typically don't require the low level debugging steps in the actual production environment. In either case unikernels have a lot of ground to cover before they can be considered for production.
vidarh 11y ago
You don't need to be able to log in to be able to support a remote debugging stub, though.

nickpsecurity 11y ago

" I'm glad it was written, because I've seen nothing but hype for Unikernels on Hacker News (and in ACM, etc.) for the last 2 years. " That much is true. I'm countering what I can where it gets overblown. Just part of something going mainstream... crowd effects and so on... "The only thing I disagree with in the article is debugging vs. restarting. In the old model, where you have a sys admin per box, yes you might want to log in and manually tweak things. In big distributed systems, code should be designed to be restarted (i.e. prefer statelessness). That is your first line of defense, and a very effective one." Additionally, there's no inherent reason that I see that unikernels are impossible to debug. We can debug everything from live hardware up to apps with existing tooling. So, if unikernels are lacking, it just means they're still young and nobody has adapted proven techniques to debugging them. I imagine the simple ones on simpler HW will make that even easier.

chris_wot 11y ago
Apparently, you can't Google search for them: https://twitter.com/bcantrill/status/690580959981211648 https://twitter.com/bcantrill/status/690580959981211648 #enoughsaid
- nickpsecurity 11y ago
  Enough said about what? That there's no current debugging (my claim) or that it's impossible (his)? "Now, could one implement production debugging tooling in unikernels? In a word, no" That's a lie: you could implement it. Debugging has been implemented for everything from ASIC's to kernel mode to apps in other categories. Whether unikernel crowd wants to or will is another question. Not looking good there per Google. Him talking like it's impossible shows he has an agenda, though. I'm guessing he didn't tell everyone to ditch the entire concept of Joylent's offering early on because they were lacking some important features or properties. Just a guess but I'd bet on it. EDIT: Changing search terms to "debugging" "xen" "guests" got me two results showing foundations are already built. Weak compared to UNIX but there. https://www.kernel.org/doc/ols/2006/ols2006v2-pages-9-24.pdf https://www.kernel.org/doc/ols/2006/ols2006v2-pages-9-24.pdf http://www-archive.xenproject.org/files/xensummitboston08/Mukesh%20xendbg-present.pdf http://www-archive.xenproject.org/files/xensummitboston08/Mu...