> 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.

> 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.

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.

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.

"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.

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

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.

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?

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.

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

"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!