NixCon2024 Enabling incremental adoption of NixOS with module contracts

2024-10-26 13:45-14:25
Speaker: Pierre Penninckx
I personally believe NixOS to be the ultimate server management tool. But how to convince others? We must let them try NixOS!
Currently, the only way to try out NixOS is to go all-in. There's no way to get a feel for it by just replacing one small piece of an existing infrastructure. To ease and accelerate adoption of NixOS, this must change.
This talk goes over why module contracts is the essential and (yet!) missing piece that will help us spread adoption of NixOS.
Take the Nextcloud module. It is a wonderful module and I am one of its happy users. In a few options, it sets up a complicated beast of infrastructure in an elegant way. It even let's you choose which database you want to use!
There's a caveat, though. Like most of the modules in NixOS, it assumes ownership of its runtime dependencies. This makes it impossible to tell the module to use a database on another host, for example. One could modify the module to add this use case, but this quickly becomes not maintainable. It would make the module even bigger, even harder to test. Also, other modules could benefit from this nice feature and we can't just add this to all of them by copy pasting code around.
What if instead, the Nextcloud module did not own its runtime dependencies. What if the user, you, were in charge of spinning up a database and letting the Nextcloud module configure its database on that instance. Same for the Nextcloud cache, the reverse proxy, the backup service, etc. This dependency inversion is what module contracts is about.
This talk explores what a world with NixOS modules relying on contracts would look like. We'll see how one would configure a Nextcloud module using contracts. Also what it would look like to test it in their current infrastructure. We'll also go over other benefits of contracts. Finally, I'll showcase my project which explores contracts and what is already possible today and what the future plans are.

[@kinjalbasu1999]

It is very interesting how similar this is to the 'Worlds' concept currently being pursued by the Webassembly folks for their modules-based redesign of WASI.

[@TheSelfHoster]

(Presenter here) I agree it looks pretty similar. Another comparison I heard was it’s similar to Kubernetes which has the same kind of concepts.

[@kinjalbasu1999]

@@TheSelfHoster Thanks for the reply. What do you think about the updating scenario? How do authors of the software declare breaking changes? Can the community enforce ABI changes from the contract side?

[@TheSelfHoster]

@@kinjalbasu1999 that’s a good question. I suppose there’s no way around coordinating with all parties involved. This will probably mean it’s harder to update contracts, at least for backward incompatible changes. I don’t think it’s necessarily a bad thing though. One important design principle for these contracts is that they should be small and tailored for one use case. For example I’m currently implementing one such contract for backup of files and backup of database. I ended up splitting those into two separate contracts and the code is much cleaner now.

[@kinjalbasu1999]

@@TheSelfHoster The main benefit of nix/nixos that I see is that it makes "distro" maintainers redundant. If the software developer can guarantee hermetic builds then they don't need to coordinate with any distro packager and directly share the binary. I hope nixpkgs doesn't become another .deb or .rpm alternative and instead eliminates the need for middle-men who compile and maintain packages.

[@TheSelfHoster]

@kinjalbasu1999 I’m definitely not the expert in that area but related to your point, the difference I see with other distro packages is that nixpkgs is directly dealing with how to compile a binary and then how to package it and make it available in an uniform way. So nixpkgs’ source is the source code directly. But then one doesn’t need to recompile everything on their machine since we use cached builds. So the middlemen you’re talking about are included inside nixpkgs, in a way.

[@MartinCharles]

this is starting to look like kubernetes hmm