
IBM CTO Sees Smaller Container Platforms Ahead - eyberg
https://containerjournal.com/topics/container-ecosystems/ibm-cto-sees-smaller-container-platforms-ahead/
======
mmillin
> These advancements will be occurring in parallel to the rise of immutable
> databases in the form of blockchain platforms, applications capable of
> invoking quantum computing systems and artificial intelligence (AI)
> platforms, which are not only going to become more accessible but also
> certified to be trusted and secure, says Ferris.

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?

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

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

~~~
nordsieck
> 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](https://en.wikipedia.org/wiki/Data_Plane_Development_Kit)

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

------
rwmj
[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-...](https://next.redhat.com/2018/11/14/ukl-a-unikernel-based-on-linux/)

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.

~~~
lima
> 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?

~~~
pnako
In the cloud no one can hear you violate the GPL.

~~~
fourthark
This is why AGPL exists. I think it is agreed that deploying your app to the
cloud is not distribution and doesn’t run foul of plain GPL.

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

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

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

~~~
tybit
I agree.

I wonder whether they end up being language agnostic or not.

~~~
0x445442
They sort of already are: [https://github.com/newapplesho/aws-sdk-
smalltalk](https://github.com/newapplesho/aws-sdk-smalltalk)

------
moomin
Erm... this is corporate thinkpiece nonsense.

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

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

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

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

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

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

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

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

~~~
AzzieElbab
Unikernel should run directly on hypervisor. Not sure this plays along with
multiple levels of virtualization in today's clouds.

~~~
eyberg
It does to a degree but there is immense confusion on how it does. For example
with OPS [https://ops.city](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.

------
AzzieElbab
Personally I would never bet on anything alongside IBM, but this is
interesting

------
Edmond
3...2...1...and..a new hype cycle begins...or at least IBM hopes it does.

