Launch HN: Nestybox (YC S20) – Containers beyond microservices

That's funny ... brings back memories of the 90s :)

One thing I've noticed is that in modern IT infrastructure, there is usually two levels of sandboxing going on. At the low level you have VMs (sandboxed OS), and on top of it you have containers (sandboxed applications). Sysbox makes it easy replace that lower level with containers (which naturally leads to docker-in-docker or more accurately containers-in-containers).

To be clear I am not saying that containers are equivalent to VMs or that containers should always replace VMs. They are different beasts with different properties. But I am saying that in many scenarios it does make sense to use containers instead of VMs, particularly if your stack is all Linux, you don't need the isolation strength provided by VMs, and want the higher efficiency of the container.

Correct; Sysbox always enables the user-namespace in containers and manages the subuid/subgid allocation. In the open-source version, it assigns all containers the same subuid/subgid range, which is not ideal for cross-container isolation. In the enterprise-version (Sysbox-EE), it assigns an exclusive subuid/subgid range to each container automatically.

Is it by any chance that it will work with docker-nividia? I.e. support accessing the host's GPU insider the nested containers?

We use it a bit, mainly as a side-effect of infrastructure. For instance, our CI runs each job in a container; the spec for the container is checked into source control. That way its easy to add new software in CI, just change the Dockerfile in the project repo. Also easy to run CI jobs locally for debugging.

Then some of our integration tests themselves use Docker, for various things. And at that point, docker in docker comes in handy.

We just run regular docker-in-docker though, which is indeed a very leaky abstraction, lots of pitfalls.

We felt just providing enterprise support would not be sufficient to create a healthy business, given that Sysbox is designed to work under the covers (i.e., under docker/containerd) and does not require a lot of support. We opted for the open-core model as we felt it creates a good balance between contributing to the container ecosystem while still allowing us to sell some enterprise-level functionality (rather than just support).

Regarding the conflict of interest, we decided to handle it as follows: features that mainly benefit practitioners would go on the open-core, while features that mainly benefit enterprise deployments would not. Of course, there is still ambiguity there, but that will need to resolved on a feature by feature basis based on the feedback from practitioners and enterprises.

This is a learning process for us, but we understand this model is being used successfully by other IT infrastructure companies such as HashiCorp, so we opted for it.