Have you looked into Habitat? It provides a similar result with a complete build workflow that works across technologies and platforms: https://www.habitat.sh/
There's a rapidly growing library of libraries and services packaged with it: https://bldr.habitat.sh
Seems like Habitat (which looks awesome by the way) relies on Docker. Which, if you consider performance heuristics in the article (size, cold/hot start time), may be a non-starter for what they're trying to do.
It does not rely on Docker. On a Linux system you can use the build tools and there's no dependence on Docker at all, it uses chroot's for its isolated "studio" build environments. The mac and windows habitat clients use Docker to create a Linux-like environment
One of the key innovations in habitat is that it gives you reliable dependency isolation WITHOUT needing the runtime isolation of containers to achieve it. Containers become optional.
A habitat build artifact can be installed and run natively on nearly _any_ POSIX system, the state of the system doesn't matter and you get the same behavior top-to-bottom. There are a number of "exporters" available to repackage build artifacts into different runtime formats -- Docker container is just one option
Well, there is the overhead of creating and removing namespaces each time a container is ran, or communicating with the Docker daemon.
I think to most people it would be negligible, but fb operates at a scale where these normally insignificant pieces matter. I would be interested to hear more about the _why_ of a system like this over containerization.
edit: rwmj's comment has a good discussion over the benefits of this over containerization.
There's a rapidly growing library of libraries and services packaged with it: https://bldr.habitat.sh
Its build artifacts can be exported to a number of formats including container images and tarballs, maybe a XAR exporter could be built: https://github.com/habitat-sh/habitat/tree/master/components...