3 ms·

It's strange to me that Alpine Linux won over Unikernels. I guess it makes sense, once you add logging, observability, printf-debugging (just kidding) to your u

It's strange to me that Alpine Linux won over Unikernels. I guess it makes sense, once you add logging, observability, printf-debugging (just kidding) to your unikernel, you basically have a full OS anyway.

lmm 3y ago
It's just familiarity and path-dependence. People expect everything to work like it does on their MacBook and if there's a bit of overhead to doing that, oh well.
- mustache_kimono 3y ago
  > logging, observability, printf-debugging (just kidding) to your unikernel, you basically have a full OS anyway. I mean -- isn't that all the good stuff? Like -- I boot this thing and I don't really have a filesystem in the way we know it. First of all, that's confusing (I say this as a ZFS devotee). Second, I have no idea why this is acting crazy in production, or in testing, compared to the Linux version? Etc., etc.
  - eyberg 3y ago
    > I don't really have a filesystem in the way we know it. This is a rather common misconception. Nanos (and many other unikernel projects) have filesystems. Most of the applications we target are webapp servers, databases, etc. They all want to, at the very least, write to a tmp file and more commonly want to load lots of files. What they don't have is an interactive userland.
  - lmm 3y ago
    > I mean -- isn't that all the good stuff? Logging and observability are valuable. But running a full multiuser OS with kernel and userland for your one process, adding extra context switches and what have you to everything you do, just for the rare occasions where you log in and run a few commands, seems crazy to me. As long as it can output logs/traces/etc. to a collector (which is what I'd want to do anyway, no-one wants to have to SSH to each separate instance to look at log files on the local filesystem) and there's a way to attach a debugger (e.g. the Java style where your debugger connects to it on a given port), I don't see any advantage from having e.g. a filesystem per se. Likewise being able to run it locally the same way as production is important, but that doesn't have to mean running it as a Linux process - people are happy running Docker images for local dev, running a unikernel in a VM isn't a lot different from that.
  - pjmlp 3y ago
    Exactly the same way as a kubernetes has a files system, and you log just the same way.
Gabrys1 3y ago
Might be due to not having a shell inside the "container" severely limits the use of your previously-acquired observability and debugging skills.
- silon42 3y ago
  I've typically used full ubuntu or some other base image... it's tremendously useful to do apt update / apt install some other tool,
  - cchance 3y ago
    Same i do that and then just wipe/reset the container when i've fixed in my app whatever was wrong
fulafel 3y ago
It's not in the same category, Alpine is just a regular Linux distribution on the userspace side, and you have a traditional big generic kernel with your app running in userspace.
antihero 3y ago
Well docker based stuff seems to have a lot more of an ecosystem on the orchestration side of things. If I want to have a bunch of instances scaled up and wired together network wise and defined in a nice yaml file, kubernetes makes this easy and replicable and I just have to push a container image somewhere like GHCR and have it all rolled out with CI. You can deploy almost the same system on top of the managed kubernetes offerings from any of the big cloud providers, so other than working out a few differences generally your config will work on anything. If I want to do this with unikernels I'm lost, would I do it with AWS services like EC2 and auto scaling groups or something? How do I get it all wired together and configured? Perhaps terraform but I'm not sure. It's all about the maturity of the glue and the architectures, not to mention training and familiarity. Does (mystery unikernels solution) have the equivalent of custom controllers somewhere in that stack? K8s provides an abstraction layer over resources and lets you define your system holistically. If this exists in a mature and flexible state for unikernels I'm all ears. What real advantage is there to using unikernels over alpine linux + k8s (or whatever) orchestration?
- eyberg 3y ago
  > If I want to do this with unikernels I'm lost, would I do it with AWS services like EC2 and auto scaling groups or something? This is a key point that many many people struggle with until they actually push their unikernels out to the cloud. It is one thing to run ops locally but try doing a 'ops image create -t aws' followed by 'ops instance create -t aws' and then you'll understand how we manage to push a lot of the scheduling work back onto the cloud provider itself.
  - antihero 3y ago
    Yeah I've popped my image onto AWS and got it running in an instance, I figure the next port of call is the terraform part of the docs to see how you'd put something out in production. It would be cool to write some sort of book like, ops for k8s people, where it takes a lot of the common concepts in k8s and explains how you'd do them with this system. ops seems like decent a CLI to get things done but as far as I can see not really an orchestration system in the same way as k8s? Perhaps I misunderstood.

lmm 3y ago

It's just familiarity and path-dependence. People expect everything to work like it does on their MacBook and if there's a bit of overhead to doing that, oh well.

mustache_kimono 3y ago
> logging, observability, printf-debugging (just kidding) to your unikernel, you basically have a full OS anyway. I mean -- isn't that all the good stuff? Like -- I boot this thing and I don't really have a filesystem in the way we know it. First of all, that's confusing (I say this as a ZFS devotee). Second, I have no idea why this is acting crazy in production, or in testing, compared to the Linux version? Etc., etc.
- eyberg 3y ago
  > I don't really have a filesystem in the way we know it. This is a rather common misconception. Nanos (and many other unikernel projects) have filesystems. Most of the applications we target are webapp servers, databases, etc. They all want to, at the very least, write to a tmp file and more commonly want to load lots of files. What they don't have is an interactive userland.
- lmm 3y ago
  > I mean -- isn't that all the good stuff? Logging and observability are valuable. But running a full multiuser OS with kernel and userland for your one process, adding extra context switches and what have you to everything you do, just for the rare occasions where you log in and run a few commands, seems crazy to me. As long as it can output logs/traces/etc. to a collector (which is what I'd want to do anyway, no-one wants to have to SSH to each separate instance to look at log files on the local filesystem) and there's a way to attach a debugger (e.g. the Java style where your debugger connects to it on a given port), I don't see any advantage from having e.g. a filesystem per se. Likewise being able to run it locally the same way as production is important, but that doesn't have to mean running it as a Linux process - people are happy running Docker images for local dev, running a unikernel in a VM isn't a lot different from that.
- pjmlp 3y ago
  Exactly the same way as a kubernetes has a files system, and you log just the same way.

Gabrys1 3y ago

Might be due to not having a shell inside the "container" severely limits the use of your previously-acquired observability and debugging skills.

silon42 3y ago
I've typically used full ubuntu or some other base image... it's tremendously useful to do apt update / apt install some other tool,
- cchance 3y ago
  Same i do that and then just wipe/reset the container when i've fixed in my app whatever was wrong

fulafel 3y ago

It's not in the same category, Alpine is just a regular Linux distribution on the userspace side, and you have a traditional big generic kernel with your app running in userspace.

antihero 3y ago

Well docker based stuff seems to have a lot more of an ecosystem on the orchestration side of things. If I want to have a bunch of instances scaled up and wired together network wise and defined in a nice yaml file, kubernetes makes this easy and replicable and I just have to push a container image somewhere like GHCR and have it all rolled out with CI. You can deploy almost the same system on top of the managed kubernetes offerings from any of the big cloud providers, so other than working out a few differences generally your config will work on anything. If I want to do this with unikernels I'm lost, would I do it with AWS services like EC2 and auto scaling groups or something? How do I get it all wired together and configured? Perhaps terraform but I'm not sure. It's all about the maturity of the glue and the architectures, not to mention training and familiarity. Does (mystery unikernels solution) have the equivalent of custom controllers somewhere in that stack? K8s provides an abstraction layer over resources and lets you define your system holistically. If this exists in a mature and flexible state for unikernels I'm all ears. What real advantage is there to using unikernels over alpine linux + k8s (or whatever) orchestration?

eyberg 3y ago
> If I want to do this with unikernels I'm lost, would I do it with AWS services like EC2 and auto scaling groups or something? This is a key point that many many people struggle with until they actually push their unikernels out to the cloud. It is one thing to run ops locally but try doing a 'ops image create -t aws' followed by 'ops instance create -t aws' and then you'll understand how we manage to push a lot of the scheduling work back onto the cloud provider itself.
- antihero 3y ago
  Yeah I've popped my image onto AWS and got it running in an instance, I figure the next port of call is the terraform part of the docs to see how you'd put something out in production. It would be cool to write some sort of book like, ops for k8s people, where it takes a lot of the common concepts in k8s and explains how you'd do them with this system. ops seems like decent a CLI to get things done but as far as I can see not really an orchestration system in the same way as k8s? Perhaps I misunderstood.