IBM CTO Sees Smaller Container Platforms Ahead(containerjournal.com)
containerjournal.com
IBM CTO Sees Smaller Container Platforms Ahead
https://containerjournal.com/topics/container-ecosystems/ibm-cto-sees-smaller-container-platforms-ahead/
67 comments
> Article just seems buzzword soup, bringing up: Containers, Unikernels, Blockchain, AI, 5G, IoT, Edge Computing, Quantum Computing
IBM's business model is persuading people to pay them for their expertise/services.
Put yourself in the shoes of someone who doesn't really know much tech, but is trying to select their next vendor for something: search around for some keywords and up pops the IBM articles/releases and all your buzzwords are name-dropped along with some impressive-sounding other things you've not heard of/only vaguely aware of, so - BINGO - IBM goes on the shortlist and your fairly boring CRUD e-commerce project is now breathlessly mentioned along with AI/IoT/5G/FutureTech and suddenly seems more exciting (...and expensive/profitable) than it is. You can't blame them.
IBM's business model is persuading people to pay them for their expertise/services.
Put yourself in the shoes of someone who doesn't really know much tech, but is trying to select their next vendor for something: search around for some keywords and up pops the IBM articles/releases and all your buzzwords are name-dropped along with some impressive-sounding other things you've not heard of/only vaguely aware of, so - BINGO - IBM goes on the shortlist and your fairly boring CRUD e-commerce project is now breathlessly mentioned along with AI/IoT/5G/FutureTech and suddenly seems more exciting (...and expensive/profitable) than it is. You can't blame them.
> What does this even mean? Containers are built around sharing a kernel, and unikernels are all about having a kernel custom for your application. Seems the ideas are at odds.
I think the most charitable translation of this is that the OS inside the container (e.g. Alpine Linux) + application will be replaced with a single unified OS + application i.e. unikernel.
I don't think that this is true, but it's a seductive idea.
From what I can tell, as system complexity goes up, you need increased instrumentation in order to property debug your application. That is a lot of what modern OS's provide.
I do sympathize with people making efficiency arguments, but I always try to bet on the "strong horse". There is just so much money and effort going into Linux, that I think it'll get efficient faster than unikernels will get instrumented.
I think the most charitable translation of this is that the OS inside the container (e.g. Alpine Linux) + application will be replaced with a single unified OS + application i.e. unikernel.
I don't think that this is true, but it's a seductive idea.
From what I can tell, as system complexity goes up, you need increased instrumentation in order to property debug your application. That is a lot of what modern OS's provide.
I do sympathize with people making efficiency arguments, but I always try to bet on the "strong horse". There is just so much money and effort going into Linux, that I think it'll get efficient faster than unikernels will get instrumented.
99% of containers don't leverage OS instrumentation or really anything unique from the underlying platform. It's typically just run this Java/Python app and maybe run this database or infrastructure component.
And there is nothing inherently inefficient about the Linux kernel. It's more that once you pack on all of the userland components you do end up with a sizeable attack vector.
And there is nothing inherently inefficient about the Linux kernel. It's more that once you pack on all of the userland components you do end up with a sizeable attack vector.
> And there is nothing inherently inefficient about the Linux kernel.
The first thing that comes to my mind is the user space networking drivers for linux [1]. They aren't very ergonomic, but the massive speed increase that is possible shows how inefficient normal linux networking is.
The promise of unikernels is the speed of user space networking but with good ergonomics.
Like I said earlier, if I had to bet, I'd bet on Linux.
But there is work to be done.
___
1. https://en.wikipedia.org/wiki/Data_Plane_Development_Kit
The first thing that comes to my mind is the user space networking drivers for linux [1]. They aren't very ergonomic, but the massive speed increase that is possible shows how inefficient normal linux networking is.
The promise of unikernels is the speed of user space networking but with good ergonomics.
Like I said earlier, if I had to bet, I'd bet on Linux.
But there is work to be done.
___
1. https://en.wikipedia.org/wiki/Data_Plane_Development_Kit
As much as I like dpdk, XDP and eBPF can potentially hit the same rates as dpdk. But we're currently in a state where more driver support is needed.
[deleted]
"Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it."
putting an app in a unikernel may be about as clever as possible for a great many software engineers.
putting an app in a unikernel may be about as clever as possible for a great many software engineers.
> putting an app in a unikernel may be about as clever as possible for a great many software engineers.
I think the traditional argument is that, with a unikernel, you can cut out a lot of the traditional OS systems that you may not care about. In theory, this could reduce your overall system complexity.
This may not really be a difference in the future anyhow: with the success of BPF programs, it may be possible to get pretty close to a unikernel while still sticking with largely vanilla Linux.
I think the traditional argument is that, with a unikernel, you can cut out a lot of the traditional OS systems that you may not care about. In theory, this could reduce your overall system complexity.
This may not really be a difference in the future anyhow: with the success of BPF programs, it may be possible to get pretty close to a unikernel while still sticking with largely vanilla Linux.
if you understand, how containers work, this is something you can do with a statically linked executable today. That's basically what Go is built around. So, it seems like it's a not so futuristic idea.
Unsure about unikernels since they do suffer from inadequate tooling like monitoring, observability, debugability? Docker acquired MirageOS and are precisely doing what with it? I believe u/amirmc has left Docker and the Mirage project?
I'm more optimistic about the direction Cloudflare is taking with Workers [0]: They're simple, easy, capable (esp since Cloudflare now supports upto 10MiB against a single key in its edge KV store), cheap (no additional bandwidth charges), with super nice deployment and release models, coupled with a 100% uptime behind an Anycast IP served by 200+ datacenters. It is astonishing to me how wonderful it really is to work with as I experimented with it just this past week.
Workers can double up nicely as a HTTP(s) API Gateway though lack certain important primitives (like throttling rules, secrets management) out of the box.
If Workers were to ever support TCP/UDP with Bring Your Own App Server, I see it being a game changer, esp in terms of architecting a global scale service.
[0] https://news.ycombinator.com/item?id=15364896
I'm more optimistic about the direction Cloudflare is taking with Workers [0]: They're simple, easy, capable (esp since Cloudflare now supports upto 10MiB against a single key in its edge KV store), cheap (no additional bandwidth charges), with super nice deployment and release models, coupled with a 100% uptime behind an Anycast IP served by 200+ datacenters. It is astonishing to me how wonderful it really is to work with as I experimented with it just this past week.
Workers can double up nicely as a HTTP(s) API Gateway though lack certain important primitives (like throttling rules, secrets management) out of the box.
If Workers were to ever support TCP/UDP with Bring Your Own App Server, I see it being a game changer, esp in terms of architecting a global scale service.
[0] https://news.ycombinator.com/item?id=15364896
The observability/monitoring/debugability arguments are super old arguments that simply aren't true in today's (and most of yesterday's) unikernel world. Most of the current day observability tooling I see in use today like prometheus and such work out of the box.
Also, something without TCP support of which every single unikernel I know of has sounds extremely limiting to me.
Also, something without TCP support of which every single unikernel I know of has sounds extremely limiting to me.
Thanks. I'm admittedly out of touch. Now that I have your attention: What kind of startup times are we looking at with unikernels, say, to serve HTTP traffic with Nginx / Apache / Caddy or some such server in the front. I ask that because Workers start in 5ms or less: I see end-to-end response times as low as 25ms to complete the work my toy app's doing.
I'm genuinely interested in any low latency isolation tech that lets me build a multi-tenant solution. The point with Cloudflare Workers is, they've made it simple to deploy the code across all their PoPs. Are there Serverless / Unikernels at Edge providers that do something similar?
I'm genuinely interested in any low latency isolation tech that lets me build a multi-tenant solution. The point with Cloudflare Workers is, they've made it simple to deploy the code across all their PoPs. Are there Serverless / Unikernels at Edge providers that do something similar?
5ms happens to be a special number. NEC reports booting unikernels that fast:
http://cnp.neclab.eu/projects/lightvm/lightvm.pdf
If you're doing NFV type of workloads fast boot time might be interesting if you are booting up and shutting down things as fast as you can, however, if you are doing traditional cloud workloads ala jvm, rails, etc. I don't know if achieving fastest time to boot makes a ton of sense - at least for those app envs it takes a while just to start and would defeat the purpose of spinning up/down. Your example of web servers typically would indicate some form of db connection taking place - even if it's just a static webserver - why need to turn on/off so fast?
I'd be interested in hearing some specific usecases cause unikernels definitely hold promise here but I don't have a ton of use-cases outside of NFV.
The low latencies that typically get a lot of us excited are the low run-time latencies and high throughput promises unikernels have.
http://cnp.neclab.eu/projects/lightvm/lightvm.pdf
If you're doing NFV type of workloads fast boot time might be interesting if you are booting up and shutting down things as fast as you can, however, if you are doing traditional cloud workloads ala jvm, rails, etc. I don't know if achieving fastest time to boot makes a ton of sense - at least for those app envs it takes a while just to start and would defeat the purpose of spinning up/down. Your example of web servers typically would indicate some form of db connection taking place - even if it's just a static webserver - why need to turn on/off so fast?
I'd be interested in hearing some specific usecases cause unikernels definitely hold promise here but I don't have a ton of use-cases outside of NFV.
The low latencies that typically get a lot of us excited are the low run-time latencies and high throughput promises unikernels have.
I'm interested in IPv4 in IPv6 and vice versa, TCP in UDP and so on for the data-plane. Imagine something like TailScale.com [0] but managed and not P2P, or maybe running something like Wireguard from within a unikernel. I'm not even sure if it is a valid use-case to have long-running unikernels? Also, does that count as NFV/SDN? Currently, I run the data-plane workload isolated via VMs and they are always-on, even when the traffic is non-existent.
The requirement for HTTP workloads is mostly for control-plane APIs, and imo, Workers will work really well, for that.
[0] https://tailscale.com
The requirement for HTTP workloads is mostly for control-plane APIs, and imo, Workers will work really well, for that.
[0] https://tailscale.com
"Containers" has been stretched to mean a lot of different things, including VMs. I think "containers in the years ahead will be deployed on unikernel systems" is a very imprecise way of saying, "we expect a transition from containers to unikernel systems".
I don't think containers are defined by having a shared kernel. VM based containers, with the same API, have been around for a few years now. Cloud services serve up large numbers of these (see Fargate etc; many of these run a container inside a VM but its much the same).
That first paragraph you quoted rings all my “snake oil salesman” alarms. This is the sort of the problem they have with the Watson division – They have brilliant people doing great work but the lies and overhype in marketing makes all of it look like a big con.
AI, Blockchain, Quantum COK mputing... Bingo!
[Disclaimer: I work for Red Hat in this area, but don't speak for IBM or their CTO]
I think reading between the lines this is really about Kata Containers-style fast booting virtual machines which run containers and give you a bit more security. Development of this is very far along, expect to see this being deployed widely soon by enterprises and others who have security sensitive container workloads.
The unikernels stuff seems rather more speculative, and I don't know specifically what IBM is referring to, but I am [at Red Hat] working with a student at BU on turning Linux into a unikernel. You link your application directly to Linux and get a vmlinuz binary which can be run in a variety of places including on cloud VMs, in qemu, in a Kata Container [in theory - not actually tried this one], or even on baremetal. Old article here: https://next.redhat.com/2018/11/14/ukl-a-unikernel-based-on-...
Edit: I should say for completeness there is also KubeVirt, which lets you run your pet VMs in a pod on Kubernetes. Sort of the opposite of Kata.
I think reading between the lines this is really about Kata Containers-style fast booting virtual machines which run containers and give you a bit more security. Development of this is very far along, expect to see this being deployed widely soon by enterprises and others who have security sensitive container workloads.
The unikernels stuff seems rather more speculative, and I don't know specifically what IBM is referring to, but I am [at Red Hat] working with a student at BU on turning Linux into a unikernel. You link your application directly to Linux and get a vmlinuz binary which can be run in a variety of places including on cloud VMs, in qemu, in a Kata Container [in theory - not actually tried this one], or even on baremetal. Old article here: https://next.redhat.com/2018/11/14/ukl-a-unikernel-based-on-...
Edit: I should say for completeness there is also KubeVirt, which lets you run your pet VMs in a pod on Kubernetes. Sort of the opposite of Kata.
This feels like IBM/RedHat are playing the "me too" game with Kata or Firecracker. Or maybe, at a higher level, IBM needs something in this space to compete with what AWS has in their Nitro architecture. But, as you say, I'm not sure that "unikernel" means anything specifically at this point other than to, maybe, generate buzz. I don't understand these fluff pieces that sound interesting but are currently vaporware.
Red Hat works by following open source trends. With Kata we have been following it upstream very closely since the Clear Containers days, as well as having people being involved with the project, and now we're productizing it.
> You link your application directly to Linux and get a vmlinuz binary which can be run in a variety of places including on cloud VMs, in qemu, in a Kata Container [in theory - not actually tried this one], or even on baremetal.
sounds like the promise java made when they started. but java abstracted away the OS but not the hardware resources. right here the hardware is but not the OS.
very curious to see how this turns out.
sounds like the promise java made when they started. but java abstracted away the OS but not the hardware resources. right here the hardware is but not the OS.
very curious to see how this turns out.
so that's basically like putting the whole app in a initrd? One could have done that for some time...
No, it's nothing like that. See my other reply: https://news.ycombinator.com/item?id=21920909
Is what you're doing anything like MirageOS (NetBSD rump kernel linked with an OCaml application [Note, this was an error, see below])? It sounds really interesting – I wonder what advantages Linux vs *BSD have as unikernels, when most hardware details are out of the picture.
MirageOS does not link to the NetBSD rump kernel. It is a standalone unikernel.
Thanks for the correction :)
So if I understand correctly, you end up with some sort of binary, that you can run on top of some system that abstracts away the hardware and manages resources, correct?
You end up with a self-contained application binary which runs anywhere that you could run a Linux kernel.
However it's different from embedding an initrd into a kernel image in several ways: The kernel is minimal, containing only the bits which are needed by your application or drivers required to run on the hardware. The application runs in kernel space and is linked with the kernel which gives you a nice performance boost because you never context switch (which is the driver behind the whole project actually). You can also call kernel functions which aren't syscalls, eg. for specialized memory management.
However it's different from embedding an initrd into a kernel image in several ways: The kernel is minimal, containing only the bits which are needed by your application or drivers required to run on the hardware. The application runs in kernel space and is linked with the kernel which gives you a nice performance boost because you never context switch (which is the driver behind the whole project actually). You can also call kernel functions which aren't syscalls, eg. for specialized memory management.
What's so wrong with the context switch? You need to have some anyway if you want threads in your unikernel.
This is a common misunderstanding. There are many different types of context switching and you need the context (heh!) To compare apples to apples.
Kernel to userland, thread to thread, process to process, kernel thread vs user thread, etc. It's conflated because different threading models and different kernel/userland separations exist.
Generally speaking (in linux) threads perform much much faster than switching processes.
Kernel to userland, thread to thread, process to process, kernel thread vs user thread, etc. It's conflated because different threading models and different kernel/userland separations exist.
Generally speaking (in linux) threads perform much much faster than switching processes.
This is right, and the other mistake people make is measuring just the context switch, and not the many hundreds of thousands of cycles after the context switch spent repopulating the cache.
You should talk to the Nabla containers and related work team https://nabla-containers.github.io/people/ in IBM Research, that is where I believe most of the context of this article comes from.
They also have a slack team for nabla http://slack.nabla-containers.com/
> You link your application directly to Linux and get a vmlinuz binary
How does this work with proprietary applications and the kernel's GPL license?
How does this work with proprietary applications and the kernel's GPL license?
I assume all these Unikernels Are targeting the Cloud and Server Usage? Which is perfectly fine for GPL.
"Consult a lawyer" would be the best answer I could give here. The applications we're actually targeting are open source servers of various kinds (think memcached, apache, etc.) so it's not an issue we need to consider ourselves as the licenses will be compatible.
No one really knows if the Linux "userspace is not covered by GPL" applies if you link an application to the kernel. Or if you then apply link time optimisation.
In the cloud no one can hear you violate the GPL.
Title doesn't match the article and contradicts the article's contents. The article talks about using unikernels with containers, not instead of them.
BTW, I kind of assume they mean running unikernels inside containers as opposed to running containers on unikernels. The article seems a bit self-contradictory about that.
BTW, I kind of assume they mean running unikernels inside containers as opposed to running containers on unikernels. The article seems a bit self-contradictory about that.
IBM/redhat have a few unikernel related projects going on and I'm guessing this is referring to nabla containers (or he might be aware of ukl).
The only reason to stuff an unikernel into a container is to make the transition easier for k8s/container holdouts. You'll take a perf hit and still be stuck with all the security problems containers have. Other than that at least in my incredibly biased opinion it makes no sense.
The only reason to stuff an unikernel into a container is to make the transition easier for k8s/container holdouts. You'll take a perf hit and still be stuck with all the security problems containers have. Other than that at least in my incredibly biased opinion it makes no sense.
Quote from the article:
> At the same time, many containers in the years ahead will be deployed on unikernel systems, says Ferris
I however can't see how this would make sense.
> At the same time, many containers in the years ahead will be deployed on unikernel systems, says Ferris
I however can't see how this would make sense.
Same here, serveless computing and rich language runtimes don't care if they are running on top of an OS, container, or even bare metal.
"The Cloud" will drive the OS layer away into plain cloud services, and the mainframe language environments will be back.
"The Cloud" will drive the OS layer away into plain cloud services, and the mainframe language environments will be back.
I agree.
I wonder whether they end up being language agnostic or not.
I wonder whether they end up being language agnostic or not.
They sort of already are: https://github.com/newapplesho/aws-sdk-smalltalk
Erm... this is corporate thinkpiece nonsense.
Nope, nope and nope. This fad is as tone-deaf as Howard Schultz running for POTUS. Unikernels are TERRIBLE for operations. How do you have privilege separation? Separation of concerns? Processes? Users? Groups? Talk to a database or LDAP? Have a reliable filesystem? Drivers for hardware? Updates? Security audits?
They’re the “emperor’s new clothes” but they throw away ALL the generality, security, lessons and existing infrastructure by reinventing the wheel, badly. They were a fad years ago but failed for these and many reasons.
They’re the “emperor’s new clothes” but they throw away ALL the generality, security, lessons and existing infrastructure by reinventing the wheel, badly. They were a fad years ago but failed for these and many reasons.
For every single ? in your comment, the answer is "it's done at the hypervisor level". A unikernel is basically a single process, so privilege separation, users, groups etc are irrelevant. Drivers are much, much simpler (and I would argue, easier to audit) because they mostly only need to access virtualized, hypervisor-provided HAL APIs. Filesystem, DB, LDAP would be external - possibly provided by another VM on the same physical hardware.
Most unikernels dont have the notion of users, groups, or multiple processes on purpose for security and performance reasons.
Some unikernels use the best in class file systems available like zfs by default.
Containers have all of these. Containers aren't unikernels.
Drivers are way less of a concern cause all you need is a clock, a network driver and a disk driver, not 30 different USB drivers, half a dozen networking drivers and more. Half of linux is just drivers cause it's designed to run on real machines whereas unikernels are explicitly designed to run as vms.
Happy to engage with real life examples on these concerns but the best way to truly understand since there's all sorts of misunderstanding here is to just simply deploy one.
Containers have all of these. Containers aren't unikernels.
Drivers are way less of a concern cause all you need is a clock, a network driver and a disk driver, not 30 different USB drivers, half a dozen networking drivers and more. Half of linux is just drivers cause it's designed to run on real machines whereas unikernels are explicitly designed to run as vms.
Happy to engage with real life examples on these concerns but the best way to truly understand since there's all sorts of misunderstanding here is to just simply deploy one.
Quick question/idea about security: with all of the exploits today like Meltdown and Spectre, is anyone working on a truly secure container?
Something like a public website running on an Intel processor, and/or maybe subdomains running on AMD and other mainstream CPUs. They would each be running some number of containers (up to say 1000 to start) and anyone could log in anonymously and run whatever they want in a minimal OS like Ubuntu. They would probably just have access to a small filesystem and maybe some open ports for HTTP or SSL or whatever.
The challenge would be to break out and take over the host computer. If anyone does that, then the pwned container is flagged as not secure.
The idea here is that until this happens, we can't really run a container and allow public access. I'd like containers to be as ubiquitous as websites running Javascript in the browser's sandbox so that we can host our own REPLs. If companies are serious about this, they should also consider providing bounties, say $100,000 guaranteeing that their container is secure for users. If you get hacked, you get the money. Without something like that, I'm afraid that I can't believe that containers are secure on faith alone.
Something like a public website running on an Intel processor, and/or maybe subdomains running on AMD and other mainstream CPUs. They would each be running some number of containers (up to say 1000 to start) and anyone could log in anonymously and run whatever they want in a minimal OS like Ubuntu. They would probably just have access to a small filesystem and maybe some open ports for HTTP or SSL or whatever.
The challenge would be to break out and take over the host computer. If anyone does that, then the pwned container is flagged as not secure.
The idea here is that until this happens, we can't really run a container and allow public access. I'd like containers to be as ubiquitous as websites running Javascript in the browser's sandbox so that we can host our own REPLs. If companies are serious about this, they should also consider providing bounties, say $100,000 guaranteeing that their container is secure for users. If you get hacked, you get the money. Without something like that, I'm afraid that I can't believe that containers are secure on faith alone.
This doesn't work like that. Containers (like docker, LXC and other based on cgroups etc) are isolated by the kernel but they share the same kernel. This means that kernel exploit will make all those containers insecure by your definition. If you go further and try to embed containers in hardware virtualization layer (so basically mini VMs) you still don't have any guarantees because from time to time new exploit emerges that allows to break out from guest OS to hypervisor.
Then you have hardware layer and exploits based on speculative execution (Spectre, Meltdown and friends).
Truly secure container doesn't exist. You would need some kind of mathematical proof for whole hardware stack and all communications between different hardware subsystems + whole kernel + container runtime.
Hmmm that doesn't inspire a lot of confidence. I'd maybe be fine with a VM then, if containers fundamentally can't be made secure.
Short of a mathematical "proof" of security, the best I could come up with was to leave containers open for the hackers of the world to exploit. If a container survives, that's a fairly strong guarantee that it can't be escaped (for now).
What I am getting at is: if we know that hackers can break out of containers, then how are we ok with shared hosting running in containers? Once one gets owned, it's trivial to break into the others.
Edit: this might be a way to force maintainers to fix kernel exploits as well.
Short of a mathematical "proof" of security, the best I could come up with was to leave containers open for the hackers of the world to exploit. If a container survives, that's a fairly strong guarantee that it can't be escaped (for now).
What I am getting at is: if we know that hackers can break out of containers, then how are we ok with shared hosting running in containers? Once one gets owned, it's trivial to break into the others.
Edit: this might be a way to force maintainers to fix kernel exploits as well.
[deleted]
Is this below saying the kernel context executes within the container? A Hypervisor being communicated to via each container is a security nightmare. The idea is to isolate the container so it can't make any type of hypervisor calls by not making the HV API available to the running container.
"Unikernels consist of a specialized, single-address-space machine image constructed using only a modular stack of libraries required to run an application. That approach allows a secure, fixed-purpose image to run directly on a hypervisor or bare-metal hardware without an operating system such as Linux or Windows. "
"Unikernels consist of a specialized, single-address-space machine image constructed using only a modular stack of libraries required to run an application. That approach allows a secure, fixed-purpose image to run directly on a hypervisor or bare-metal hardware without an operating system such as Linux or Windows. "
[deleted]
Will they find a way to slip in the Watson brand?
IBM is no longer in the innovation business. They (along with Red Hat) are in the audit business.
IBM is no longer in the innovation business. They (along with Red Hat) are in the audit business.
containers are implemented via cgroups (and others) and share the kernel. I presume with a unikernel, you'll not be sharing the kernel, obviously..
So concept of a "container" is there and probably the orchestration via kubernetes is all still valid up the stack, so it makes sense to call that "containers" still.
Unikernel should run directly on hypervisor. Not sure this plays along with multiple levels of virtualization in today's clouds.
It does to a degree but there is immense confusion on how it does. For example with OPS https://ops.city (I'm associated with the project) we deploy directly to AWS or GCloud as an ami or cloud image not orchestrating qemu on top of an existing linux image. A lot of people until they have actually tried booting one are thoroughly confused on this process.
You could play on top of google nested virt or ami's 'bare metal' but both of those would have performance taxes.
I think in the coming years we'll see the big public clouds refactor their environments to support these in a better fashion.
You could play on top of google nested virt or ami's 'bare metal' but both of those would have performance taxes.
I think in the coming years we'll see the big public clouds refactor their environments to support these in a better fashion.
Personally I would never bet on anything alongside IBM, but this is interesting
3...2...1...and..a new hype cycle begins...or at least IBM hopes it does.
Article just seems buzzword soup, bringing up: Containers, Unikernels, Blockchain, AI, 5G, IoT, Edge Computing, Quantum Computing
> containers in the years ahead will be deployed on unikernel systems
What does this even mean? Containers are built around sharing a kernel, and unikernels are all about having a kernel custom for your application. Seems the ideas are at odds.
The most charitable view to me seems to be an orchestration platform for running "containers" which are actually VMs running unikernels, instead of contained processes?