I thought this article about Apple’s new containers was interesting.
In particular, the author points out that these containers are each run in their own lightweight virtual machine and don’t share a kernel. This is a significant improvement in security.
Traditional container runtimes share the host kernel among all containers, creating potential attack vectors through kernel exploits or container escape vulnerabilities. By placing each container in its own lightweight VM, Apple eliminates the shared attack surface that has plagued container security for over a decade.
The open source nature of the framework also signals Apple’s commitment to broader ecosystem adoption. Apple aims to provide an open source framework that takes advantage of its Swift programming language, which is optimized for its Apple Silicon chips and minimizes security risks.
The obvious problem here is that this is a desktop product. And, there is no obvious server software or attempt to scale at this time.
That said, the sponsor of the New Stack articles does offer isolated x64 containers for Kubernetes. So, that might be one option.
I thought this was a cool new feature to see in the latest macOS (that will be the first not support my Mac). Good to hear they’re more secure than the typical containers by being isolated.
I do wonder what people would end up using them for, though. The advantage of macOS is that it gives you access to pretty much everything you can get on Linux. I’ve never wanted something I couldn’t use on macOS.
This was my immediate thought, of course. I only use macOS and Windows on occasion, and I thought of these containers as an analogue to WSL. But it seems like the container framework is actually an alternative to Docker? I thought Docker containers were only gimped on Windows and were perfectly normal on macOS and Linux.
Don’t get me wrong, this sounds great for a server use case…but as you said, Mike, it’s a desktop product. I’m not sure I get it.
They might be useful for running NPM projects as they’re more isolated. I really don’t trust those packages on my live system. I’ve read about someone who does crazy stuff like develop entirely in Virtual Machines over SSH with Neovim.
I don’t see why I would ship something to users that I don’t trust on my own system, but alas. The Javascript ecosystem is just the way it is and there’s no fixing it.
I do development with Docker on Linux, but I’ve never seen a reason to care much about isolation in a development environment because I don’t work in the Javascript ecosystem. I trust all the packages I work with. I would be running them natively if containers didn’t make my work environment a little cleaner.
Maybe I’m missing something. Though, if I were developing on a Mac, of course I would use the more performant native containers that gets me closer to a real Linux system. (Of course, I would rather just run a Linux system with native Linux containers…)
Isolated containers do not solve a problem for any desktop user because the only reason to use a server technology on the desktop is for software development.
Isolated containers do address problems with actual servers that are used by multiple cloud customers and are public-facing. Namely: What happens when one of the containers is hacked? As outlined in the article, today, a very large piece of hardware can be compromised when a single container is compromised. Taking that server or cluster offline to remove the exploit can mean that the vendor and customers lose hundreds of thousands of dollars. The same exploit in an isolated container would only affect that virtual machine, which could easily be discarded. The impact on the cluster then goes from 100% of the cluster is offline, to 0% of the cluster is offline. As you know, containers are routinely discarded as part of normal operations.
I think the confusion comes when we try to make sense of isolated containers on the desktop.
But, if you keep in mind that, with isolated containers, one tenant’s bad code now only affects them, or an infected container no longer threatens the vendor’s infrastructure; isolated containers can be worth billions of dollars in savings over the long term.
So, what makes sense to me is that Apple wanted to introduce isolated containers. And, giving developers a server product for their desktop is a good way to test without much risk.
Also, since this is a macOS technology, I assume that Apple is either bringing back Server or creating their own SaaS. Otherwise, it doesn’t make sense to spend millions of dollars recreating a server technology if there is nowhere to run it.
Podman is a partial attempt at addressing some of the problems with Docker containers, like rootless containers. And it allows for cool desktop use cases like Toolbox and Distrobox, which are what make immutable distributions like Fedora Silverblue worthwhile for developers and users who need more software.
Podman has a few incompatibilities and issues to work out nonetheless that make it a hassle to use on servers.
But Apple’s container framework sounds like a full solution to the big security issues that have been around for years. It would definitely be…interesting, to see macOS servers make a comeback. Maybe they finally want a slice of the very rich Cloud pie. As you say, it is a valuable proposition. And native containers let macOS leverage the expansive Linux ecosystem that has kept Microsoft servers relegated to Exchange, Active Directory, and little else. I could actually see it happening.
It does remind me a bit of Game Porting Toolkit. It signaled that Apple was going to develop some sort of Proton/Wine-like solution for gaming on macOS with the backing of a megacorporation, though they presented as “a way for developers to test Windows builds of their games on macOS” (not entirely sure what the point of that is). And then…they just didn’t do anything else. I guess they still don’t care about gaming on macOS.