IBM CTO Sees Smaller Container Platforms Ahead
containerjournal.com
containerjournal.com
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?
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.
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.
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.
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.
___
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.
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.
Also, something without TCP support of which every single unikernel I know of has sounds extremely limiting to me.
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?
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.
The requirement for HTTP workloads is mostly for control-plane APIs, and imo, Workers will work really well, for that.
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.
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.
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.
How does this work with proprietary applications and the kernel's GPL license?
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.
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.
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.
> 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.
"The Cloud" will drive the OS layer away into plain cloud services, and the mainframe language environments will be back.
I wonder whether they end up being language agnostic or not.
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.
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.
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.
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.
"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. "
IBM is no longer in the innovation business. They (along with Red Hat) are in the audit business.
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.