8 ms·

Why unikernels might kill containers in five years

76 points by ngrilly 11y ago

ngrilly 11y ago
Interesting, but I’m not convinced. Size: Each unikernel image contains a kernel specially compiled for the application. A container image properly optimized contains just the application (the kernel is shared by all containers). It’s possible to create Docker containers under 10 MB: see http://blog.xebia.com/2014/07/04/create-the-smallest-possible-docker-container/ http://blog.xebia.com/2014/07/04/create-the-smallest-possibl... and http://blog.xebia.com/2015/06/30/how-to-create-the-smallest-possible-docker-container-of-any-image/ http://blog.xebia.com/2015/06/30/how-to-create-the-smallest-.... Security: Reusing a well known and largely deployed Linux kernel (without all the surrounding provided by the “larger” OS) sounds at least as secure as compiling its own specialized unikernel. Compatibility: The compatibility story sounds better for containers because your app will work by default without doing anything.
- mlieberman85 11y ago
  As far as security is concerned a unikernel with lower attack surface will beat out a general kernel. A unikernel for AppX will have a completely different attack surface from AppY so most generalized attacks just won't work. Shell attacks like heartbleed won't work because there is no shell. Given that there's a single process, even if you did compromise the system there's not a whole lot you can do with it.
  - binarycrusader 11y ago
    I think the poster's point is that a unikernel may have an overall lower attack surface, but it now has a different, unique attack surface. That seems like it might be a legitimate concern. There's also support considerations to taken into account as well from a vendor perspective.
  - tedunangst 11y ago
    I think you mean shellshock, but people were only vulnerable to shellshock if they were actually using bash for something. And anybody using bash is, by necessity, going to include it in their virtualunicontainerimage.
  - steego 11y ago
    > A unikernel for AppX will have a completely different attack surface from AppY so most generalized attacks just won't work. If unikernal systems do become popular, it's very likely this would not be true because AppX and AppY would likely share a popular library that they've both been statically linked against. (Ex: An HTTP library with TLS). Granted, the footprint of exploitable features would be considerably smaller I agree more with the the latter point that a compromised system would probably offer very little for an attacker to leverage.
    - Sanddancer 11y ago
      I imagine that a unikernel management system would have all the modules -- http, tls, the user facing app, etc -- just as object files, so that an update of the TLS library would entail little more than relinking and restarting the new unikernels.
  - detrino 11y ago
    Can't you already achieve this with seccomp-bpf?
- mtgx 11y ago
  Apparently unikernel images can be as small as 200KB. http://blog.acolyer.org/2015/01/13/unikernels-library-operating-systems-for-the-cloud/ http://blog.acolyer.org/2015/01/13/unikernels-library-operat... That might be only for niche cases, though, but others seem to say it can be under 5MB for more general uses, too: http://www.techrepublic.com/article/unikernels-offer-a-stripped-down-alternative-to-linux/ http://www.techrepublic.com/article/unikernels-offer-a-strip... This is a nice talk on unikernels: https://www.youtube.com/watch?v=oHcHTFleNtg https://www.youtube.com/watch?v=oHcHTFleNtg
- rjsw 11y ago
  A unikernel can be pretty small, the sample one that comes with Xen builds to 230KB. Some of the OpenMirage builds are around 25MB.
- jdc 11y ago
  Regarding security, any distro install is going to have an attack surface several orders of magnitude higher than a unikernel. Does anyone know how the quantity of exploitable vulnerabilities varies with attack surface (ie. SLOC)?
- pflanze 11y ago
  The original poster says: "Given that unikernels compile only which is necessary into the applications, the surface area is very small." I think this is a somewhat strange statement. You don't lower the surface area by not compiling in dead code--unless you're offering a way to run arbitrary code, in which case it can help implementing the anti-features the attacker wants. But to me it seems the primary innovation of unikernels is that they are not implemented in C, but in a higher-level language like Ocaml, Erlang, etc. Those languages, if their compilers and runtimes are implemented correctly, don't allow buffer overflows, and have also other features to prevent arbitrary code execution (type system, or secure process isolation). Those kernels have (given the same attention to quality) the potential of being more secure than the Linux kernel by using such languages. Also, by not having to be a general OS kernel, they are simpler to implement, hence reducing the number of bugs likely to be around. It's not the "compiling into the application", it's the "implementation of the algorithms" that's smaller. Perhaps that's what the original poster meant, but it sounded strange to me.
- deleted 11y ago
  [deleted]
- axelfontaine 11y ago
  At Boxfuse (https://boxfuse.com https://boxfuse.com) we decided to combine the best of both worlds: dynamically generated minimal Linux-based images. They are just a few MBs in size, generated in seconds and start almost instantly, yet retain the tried and true quality and compatibility of the Linux kernel. We coupled that with a secure repository and blue/green AWS deployments for a great out of the box experience.
thoman23 11y ago
Does this mean if I wait long enough, I won't ever need to figure out what exactly Docker is?
- alexro 11y ago
  Sure. With the true AI around the horizon if you wait long enough you won't have to figure anything - it will do it for you.
  - amorphid 11y ago
    I wonder when AIs will start outsourcing work to humans.
    - dinesh_babu 11y ago
      AI is smart enough to not do that.
    - SEJeff 11y ago
      s/Mechanical Turk/Mechanical Human/
- nostrademons 11y ago
  That's the case with most technologies. I managed to skip the whole Angular/Mongo hype, and now that I'm actually getting back into frontend development, it's all about React. Can't say I missed it. I remember telling my boss at my very first job "Yeah, I want to learn MFC and COM". His response was "Why? By the time you're out of college, everything will be .NET." It turned out he had underestimated: by the time I graduated from college, MFC & COM had been replaced by .NET, which had been replaced by webapps running under J2EE, which were just about to be replaced by Rails & Django.
  - jcranmer 11y ago
    Actually, J2EE (December 12, 1999, if the Great Wiki is to believed) predates .NET (February 13, 2002, same source). .NET and J2EE (or C# and Java) never really replaced each other--at best, .NET was MS's attempt to upgrade the MFC/COM stuff to the Java VM world after J++ fell apart. They're more or less the same model, one's just the Windows Server flavor while the other is the Linux/Unix flavor.
ori_b 11y ago
Now, I'm waiting for someone to discover that unikernels can be optimized if they have some sort of way of directly requesting the host operating system to do things for them. A call to the system, you may say.
- joveian 11y ago
  You joke but one nice use of them is a simplified system interface which can allow a traditional OS to give such processes significantly lower privileges, e.g. to sandbox something like mplayer. Unikernels make it possible to play with where you put a bunch of code that would otherwise need to be in the kernel or reimplemented.
haberman 11y ago
Container images (like in Docker) contain an OS? That's news to me. I thought they avoided having an OS, and instead just have binaries that are run in a very isolated environment. It sounds like unikernels are still based around hardware virtualization. That seems like a mistake to me. If your image includes the code to switch an x86 processor from real mode into protected mode, you're doing it wrong (IMO).
- wakwanza 11y ago
  Would depend on the choice of unikernel and how theyr doing their stuff osv.io for example basically run the app in kernel space on top of a hypervisor and inherently as hardware agnostic as possible.
- bjt 11y ago
  Container images don't have a kernel, but they do have userland portions of an OS (e.g. libc).
  - cpeterso 11y ago
    Won't each unikernel image running on a hyper visor also include redundant copies of libraries like libc?
- rumcajz 11y ago
  AFAIU the whole thing runs in ring 0.
api 11y ago
Are we essentially witnessing the death of the operating system? Docker builds what amounts to giant statically linked binaries including images of an OS as support, while unikernels relegate the OS to library status. In both cases this is starting to look like the way you deploy to embedded devices: build image, flash image to device. I mean that is some serious full-circle going on there... we've been trying to get away from that kind of thing since computers were invented.
- vezzy-fnord 11y ago
  Unikernels are essentially the far less interesting cousin of exokernels, in that they nominally preserve the libOS angle but are limited to application deployment under a bare-metal hypervisor. Much of the motivation for microkernel research, too, was for applications to be able to control their workloads at a finer granularity while retaining a full OS environment. Scout and SPIN were such examples. Something as simple as making page replacement and eviction a userland server where each library or application can implement its own policy over the RPC interface, can yield great benefits.
- lotyrin 11y ago
  No, just realising the ones we have based on assumptions from the 70s don't match what we really want. My phone has an operating system that mostly pretends that it's a mainframe. With just a little hardware, I could hook some circa 1978 VT100s up to it and a team of average *nix web backend developers could even be productive. My "workstation" pretends to be several tens of machines doing all sorts of different things. These boundaries exist for no reason other than to map to organizational concerns -- my CPU does all kinds of computational gymnastics so I can "keep things tidy". The model is just wrong. Things are immutable that shouldn't be. Things are mutable that shouldn't be. Things aren't distributed that should be. Things aren't durable that should be. Things are shared that shouldn't be. Things are isolated that shouldn't be. Config management, containers, orchestration, stuff like adding BPF to the kernel, Docker, Hadoop, Mesos -- all very cool, but all very much bandaids. We're working on it but because we're human we can't go straight for the goalpost, we have to play politics, cheat by modeling the future using what we already have today and lead by example.
rossf7 11y ago
I think the reduced attack surface and faster startup times will have a big impact eventually. At the moment language choice is a blocker for me. I don't want to have to learn OCaml to play with unikernels. LING looks interesting since its based on Erlang. If I could develop on Elixir that would make a big difference.
gtrubetskoy 11y ago
I think the author is confusing containers and full virtualization which runs a separate kernel.
kylek 11y ago
I don't know...the big win (IMO) with containers is all of the nifty orchestration software in the ecosystem. I wonder about the possibility of "hybrid" approach by launching a unikernel (via kvm/xen?) inside of a docker container, orchestrated by kubernetes/mesos/etc.
marcosdumay 11y ago
I still don't get it. Yep, unikernels can get away without the security boundary between user and kernel modes... except if you want any security at all in your installation, because at kernel mode people can break out of the container. They can also get away without process scheduling and IPC, but if you want any multiprocessing on the application, you'll need to bring it either on the kernel or the userland. Ditto for user management. They can't really get away without device drivers. Ok, except for devices that you won't use, just like any other kernel. What is that kernel feature that people take away? Or are they just talking about a stripped down Linux without the device drivers (that fit a floppy disk)? The same applies to the services. What are those services that people gain so much from removing from containers, and why don't people remove them from VMs and real machines too?
- wakwanza 11y ago
  Id point you to osv.io havent really played arounf with iy much though the concept is pretty intriguing .Being able to run the kernel directly on the hypervisor , and containing only your app and whats needed to run , thus obviatibg the need for device drivers with everything running in the kernel address space.Also check out LING for the erlangVM
- nostrademons 11y ago
  The idea is that your security boundary is at the VM. The VM hypervisor presents a virtual CPU; malicious code cannot jump out of the box. Many common server frameworks build in multiprocessing to the language runtime: Node.js mandates an event-driven callback style, Go has goroutines, etc. So it already exists in userland. Unikernels avoid duplicating that functionality at the kernel level, so the two systems don't fight each other. The hypervisor proxies device drivers through from the host operating system (running in Dom0) to the guest operating systems. The idea is to run eg. Node, or Postgres, or memcached on bare metal. So instead of write() trapping into the operating system, it becomes a library function that directly talks to the underlying device driver. The only process the VM runs would be that one application, and you'd rely on the hypervisor to schedule multiple applications on one physical box.
  - 11y ago
powera 11y ago
This page is a direct copy of https://gigaom.com/2015/10/09/why-unikernels-will-kill-containers-in-five-years/ https://gigaom.com/2015/10/09/why-unikernels-will-kill-conta... , fix the link?
nwmcsween 11y ago
I'm torn between a programming language that is safe enough to allow a complete ring0 os to the beauty that is an exokernel. I predict within 10-20 years syscall overhead will dominate anything to the point that mitigation measures will have to be developed - batching, etc.
hodgesrm 11y ago
I like the idea of the small attack service and minimal image size. However, having a different kernel image for each service seems likely to trigger some extremely hard-to-diagnose bugs, which have to include performance problems. As least with conventional OS you have a chance to get in and figure out what's going on. With Unikernels it sounds as if you may end up with either a core dump (how?) or a misbehaving service you can't access to diagnose problems.
- talex5 11y ago
  Mirage can be configured to write trace data to a ring buffer shared with another VM, where you can run a visualisation tool to explore it. For an example, see: https://mirage.io/wiki/profiling https://mirage.io/wiki/profiling Of course, having such a small (and legacy-free) OS makes debugging vastly easier in the first place.
  - hodgesrm 11y ago
    You are right about simplification and I considered that point. Yet the fact that each application is developed on a general purpose platform, then compiled down to a unique production OS image seems to open up a lot of new corner cases involving long tail bugs. We had a similar phase in during the Java transition to JIT in the late 1990s, though that's obviously an antithetical technology approach. Either way you get a lot of ugly crashes. The key for industrial use is extremely robust dev and management tools. Unikernels are thought-provoking but on their own do not appear to be anywhere near enough to solve the problem they are taking on.
michaelcampbell 11y ago
> If you look at the size of a container instance – hundreds of megabytes, if not gigabytes, in size Or... 10's.

76 points by ngrilly 11y ago

Interesting, but I’m not convinced. Size: Each unikernel image contains a kernel specially compiled for the application. A container image properly optimized contains just the application (the kernel is shared by all containers). It’s possible to create Docker containers under 10 MB: see http://blog.xebia.com/2014/07/04/create-the-smallest-possible-docker-container/ http://blog.xebia.com/2014/07/04/create-the-smallest-possibl... and http://blog.xebia.com/2015/06/30/how-to-create-the-smallest-possible-docker-container-of-any-image/ http://blog.xebia.com/2015/06/30/how-to-create-the-smallest-.... Security: Reusing a well known and largely deployed Linux kernel (without all the surrounding provided by the “larger” OS) sounds at least as secure as compiling its own specialized unikernel. Compatibility: The compatibility story sounds better for containers because your app will work by default without doing anything.

mlieberman85 11y ago
As far as security is concerned a unikernel with lower attack surface will beat out a general kernel. A unikernel for AppX will have a completely different attack surface from AppY so most generalized attacks just won't work. Shell attacks like heartbleed won't work because there is no shell. Given that there's a single process, even if you did compromise the system there's not a whole lot you can do with it.
- binarycrusader 11y ago
  I think the poster's point is that a unikernel may have an overall lower attack surface, but it now has a different, unique attack surface. That seems like it might be a legitimate concern. There's also support considerations to taken into account as well from a vendor perspective.
- tedunangst 11y ago
  I think you mean shellshock, but people were only vulnerable to shellshock if they were actually using bash for something. And anybody using bash is, by necessity, going to include it in their virtualunicontainerimage.
- steego 11y ago
  > A unikernel for AppX will have a completely different attack surface from AppY so most generalized attacks just won't work. If unikernal systems do become popular, it's very likely this would not be true because AppX and AppY would likely share a popular library that they've both been statically linked against. (Ex: An HTTP library with TLS). Granted, the footprint of exploitable features would be considerably smaller I agree more with the the latter point that a compromised system would probably offer very little for an attacker to leverage.
  - Sanddancer 11y ago
    I imagine that a unikernel management system would have all the modules -- http, tls, the user facing app, etc -- just as object files, so that an update of the TLS library would entail little more than relinking and restarting the new unikernels.
- detrino 11y ago
  Can't you already achieve this with seccomp-bpf?
mtgx 11y ago
Apparently unikernel images can be as small as 200KB. http://blog.acolyer.org/2015/01/13/unikernels-library-operating-systems-for-the-cloud/ http://blog.acolyer.org/2015/01/13/unikernels-library-operat... That might be only for niche cases, though, but others seem to say it can be under 5MB for more general uses, too: http://www.techrepublic.com/article/unikernels-offer-a-stripped-down-alternative-to-linux/ http://www.techrepublic.com/article/unikernels-offer-a-strip... This is a nice talk on unikernels: https://www.youtube.com/watch?v=oHcHTFleNtg https://www.youtube.com/watch?v=oHcHTFleNtg
rjsw 11y ago
A unikernel can be pretty small, the sample one that comes with Xen builds to 230KB. Some of the OpenMirage builds are around 25MB.
jdc 11y ago
Regarding security, any distro install is going to have an attack surface several orders of magnitude higher than a unikernel. Does anyone know how the quantity of exploitable vulnerabilities varies with attack surface (ie. SLOC)?
pflanze 11y ago
The original poster says: "Given that unikernels compile only which is necessary into the applications, the surface area is very small." I think this is a somewhat strange statement. You don't lower the surface area by not compiling in dead code--unless you're offering a way to run arbitrary code, in which case it can help implementing the anti-features the attacker wants. But to me it seems the primary innovation of unikernels is that they are not implemented in C, but in a higher-level language like Ocaml, Erlang, etc. Those languages, if their compilers and runtimes are implemented correctly, don't allow buffer overflows, and have also other features to prevent arbitrary code execution (type system, or secure process isolation). Those kernels have (given the same attention to quality) the potential of being more secure than the Linux kernel by using such languages. Also, by not having to be a general OS kernel, they are simpler to implement, hence reducing the number of bugs likely to be around. It's not the "compiling into the application", it's the "implementation of the algorithms" that's smaller. Perhaps that's what the original poster meant, but it sounded strange to me.
deleted 11y ago
[deleted]
axelfontaine 11y ago
At Boxfuse (https://boxfuse.com https://boxfuse.com) we decided to combine the best of both worlds: dynamically generated minimal Linux-based images. They are just a few MBs in size, generated in seconds and start almost instantly, yet retain the tried and true quality and compatibility of the Linux kernel. We coupled that with a secure repository and blue/green AWS deployments for a great out of the box experience.

thoman23 11y ago

Does this mean if I wait long enough, I won't ever need to figure out what exactly Docker is?

alexro 11y ago
Sure. With the true AI around the horizon if you wait long enough you won't have to figure anything - it will do it for you.
- amorphid 11y ago
  I wonder when AIs will start outsourcing work to humans.
  - dinesh_babu 11y ago
    AI is smart enough to not do that.
  - SEJeff 11y ago
    s/Mechanical Turk/Mechanical Human/
nostrademons 11y ago
That's the case with most technologies. I managed to skip the whole Angular/Mongo hype, and now that I'm actually getting back into frontend development, it's all about React. Can't say I missed it. I remember telling my boss at my very first job "Yeah, I want to learn MFC and COM". His response was "Why? By the time you're out of college, everything will be .NET." It turned out he had underestimated: by the time I graduated from college, MFC & COM had been replaced by .NET, which had been replaced by webapps running under J2EE, which were just about to be replaced by Rails & Django.
- jcranmer 11y ago
  Actually, J2EE (December 12, 1999, if the Great Wiki is to believed) predates .NET (February 13, 2002, same source). .NET and J2EE (or C# and Java) never really replaced each other--at best, .NET was MS's attempt to upgrade the MFC/COM stuff to the Java VM world after J++ fell apart. They're more or less the same model, one's just the Windows Server flavor while the other is the Linux/Unix flavor.

ori_b 11y ago

Now, I'm waiting for someone to discover that unikernels can be optimized if they have some sort of way of directly requesting the host operating system to do things for them. A call to the system, you may say.

joveian 11y ago
You joke but one nice use of them is a simplified system interface which can allow a traditional OS to give such processes significantly lower privileges, e.g. to sandbox something like mplayer. Unikernels make it possible to play with where you put a bunch of code that would otherwise need to be in the kernel or reimplemented.

haberman 11y ago

Container images (like in Docker) contain an OS? That's news to me. I thought they avoided having an OS, and instead just have binaries that are run in a very isolated environment. It sounds like unikernels are still based around hardware virtualization. That seems like a mistake to me. If your image includes the code to switch an x86 processor from real mode into protected mode, you're doing it wrong (IMO).

wakwanza 11y ago
Would depend on the choice of unikernel and how theyr doing their stuff osv.io for example basically run the app in kernel space on top of a hypervisor and inherently as hardware agnostic as possible.
bjt 11y ago
Container images don't have a kernel, but they do have userland portions of an OS (e.g. libc).
- cpeterso 11y ago
  Won't each unikernel image running on a hyper visor also include redundant copies of libraries like libc?
rumcajz 11y ago
AFAIU the whole thing runs in ring 0.

api 11y ago

Are we essentially witnessing the death of the operating system? Docker builds what amounts to giant statically linked binaries including images of an OS as support, while unikernels relegate the OS to library status. In both cases this is starting to look like the way you deploy to embedded devices: build image, flash image to device. I mean that is some serious full-circle going on there... we've been trying to get away from that kind of thing since computers were invented.

vezzy-fnord 11y ago
Unikernels are essentially the far less interesting cousin of exokernels, in that they nominally preserve the libOS angle but are limited to application deployment under a bare-metal hypervisor. Much of the motivation for microkernel research, too, was for applications to be able to control their workloads at a finer granularity while retaining a full OS environment. Scout and SPIN were such examples. Something as simple as making page replacement and eviction a userland server where each library or application can implement its own policy over the RPC interface, can yield great benefits.
lotyrin 11y ago
No, just realising the ones we have based on assumptions from the 70s don't match what we really want. My phone has an operating system that mostly pretends that it's a mainframe. With just a little hardware, I could hook some circa 1978 VT100s up to it and a team of average *nix web backend developers could even be productive. My "workstation" pretends to be several tens of machines doing all sorts of different things. These boundaries exist for no reason other than to map to organizational concerns -- my CPU does all kinds of computational gymnastics so I can "keep things tidy". The model is just wrong. Things are immutable that shouldn't be. Things are mutable that shouldn't be. Things aren't distributed that should be. Things aren't durable that should be. Things are shared that shouldn't be. Things are isolated that shouldn't be. Config management, containers, orchestration, stuff like adding BPF to the kernel, Docker, Hadoop, Mesos -- all very cool, but all very much bandaids. We're working on it but because we're human we can't go straight for the goalpost, we have to play politics, cheat by modeling the future using what we already have today and lead by example.

rossf7 11y ago

I think the reduced attack surface and faster startup times will have a big impact eventually. At the moment language choice is a blocker for me. I don't want to have to learn OCaml to play with unikernels. LING looks interesting since its based on Erlang. If I could develop on Elixir that would make a big difference.

gtrubetskoy 11y ago

I think the author is confusing containers and full virtualization which runs a separate kernel.

kylek 11y ago

I don't know...the big win (IMO) with containers is all of the nifty orchestration software in the ecosystem. I wonder about the possibility of "hybrid" approach by launching a unikernel (via kvm/xen?) inside of a docker container, orchestrated by kubernetes/mesos/etc.

marcosdumay 11y ago

I still don't get it. Yep, unikernels can get away without the security boundary between user and kernel modes... except if you want any security at all in your installation, because at kernel mode people can break out of the container. They can also get away without process scheduling and IPC, but if you want any multiprocessing on the application, you'll need to bring it either on the kernel or the userland. Ditto for user management. They can't really get away without device drivers. Ok, except for devices that you won't use, just like any other kernel. What is that kernel feature that people take away? Or are they just talking about a stripped down Linux without the device drivers (that fit a floppy disk)? The same applies to the services. What are those services that people gain so much from removing from containers, and why don't people remove them from VMs and real machines too?

wakwanza 11y ago
Id point you to osv.io havent really played arounf with iy much though the concept is pretty intriguing .Being able to run the kernel directly on the hypervisor , and containing only your app and whats needed to run , thus obviatibg the need for device drivers with everything running in the kernel address space.Also check out LING for the erlangVM
nostrademons 11y ago
The idea is that your security boundary is at the VM. The VM hypervisor presents a virtual CPU; malicious code cannot jump out of the box. Many common server frameworks build in multiprocessing to the language runtime: Node.js mandates an event-driven callback style, Go has goroutines, etc. So it already exists in userland. Unikernels avoid duplicating that functionality at the kernel level, so the two systems don't fight each other. The hypervisor proxies device drivers through from the host operating system (running in Dom0) to the guest operating systems. The idea is to run eg. Node, or Postgres, or memcached on bare metal. So instead of write() trapping into the operating system, it becomes a library function that directly talks to the underlying device driver. The only process the VM runs would be that one application, and you'd rely on the hypervisor to schedule multiple applications on one physical box.
- 11y ago

powera 11y ago

This page is a direct copy of https://gigaom.com/2015/10/09/why-unikernels-will-kill-containers-in-five-years/ https://gigaom.com/2015/10/09/why-unikernels-will-kill-conta... , fix the link?

nwmcsween 11y ago

I'm torn between a programming language that is safe enough to allow a complete ring0 os to the beauty that is an exokernel. I predict within 10-20 years syscall overhead will dominate anything to the point that mitigation measures will have to be developed - batching, etc.

hodgesrm 11y ago

I like the idea of the small attack service and minimal image size. However, having a different kernel image for each service seems likely to trigger some extremely hard-to-diagnose bugs, which have to include performance problems. As least with conventional OS you have a chance to get in and figure out what's going on. With Unikernels it sounds as if you may end up with either a core dump (how?) or a misbehaving service you can't access to diagnose problems.

talex5 11y ago
Mirage can be configured to write trace data to a ring buffer shared with another VM, where you can run a visualisation tool to explore it. For an example, see: https://mirage.io/wiki/profiling https://mirage.io/wiki/profiling Of course, having such a small (and legacy-free) OS makes debugging vastly easier in the first place.
- hodgesrm 11y ago
  You are right about simplification and I considered that point. Yet the fact that each application is developed on a general purpose platform, then compiled down to a unique production OS image seems to open up a lot of new corner cases involving long tail bugs. We had a similar phase in during the Java transition to JIT in the late 1990s, though that's obviously an antithetical technology approach. Either way you get a lot of ugly crashes. The key for industrial use is extremely robust dev and management tools. Unikernels are thought-provoking but on their own do not appear to be anywhere near enough to solve the problem they are taking on.

michaelcampbell 11y ago

> If you look at the size of a container instance – hundreds of megabytes, if not gigabytes, in size Or... 10's.