Since this system is based on NixOS and the Nix package manager, immutable is implied. Any change you make to a Nix/NixOS system results in a full rebuild of the system, and pointers to the new system updated. Current and all prior builds remain immutable.
Keep in mind that all large-scale systems work based on deploying container images. If it's not in a container image, it's not getting deployed.
It's like the difference between shipping an app and shipping an OS with the app-preinstalled, except in this case neither has any external dependencies to worry about.
(Dockerfiles are not the only way to build images, of course, but they are a common one).
Installing packages is only a small part of building a typical container image, especially for custom apps being built to run in the cloud. Even if you have your dependencies, you need to compile, run tests, and potentially customize the files inside the container, typically using the programs already installed in the container.
So since you're already running a pipeline of scripts in a container right after installing package deps, I'm not sure why one would use Nix for this when Debian works just as well?
So say that you need to make a Docker container running nginx hosting a static website that you build with Jekyll. At a high level you'd write a Nix file like (very much pseudocode):
with let site = buildWithJekyll src={"./src";}; let mynginx = nginx { wwwroot = site; }; docker.buildLayeredImage { inputs: mynginx, entrypoint: "./nginx" }
Nix will run Jekyll to build the site, hash the build output and "site" gets that path. Then Nix takes Jekyll and writes a configuration file that sets wwwroot to the Jekyll output. Then Nix builds a container that runs nginx when it starts. If you just change the Nginx config it won't rerun Jekyll because it knows Jekyll's build inputs haven't changed.
Nix is a build system that runs other build systems. Comparing Nix to Debian doesn't really make sense, it's like comparing build pipelines to makefiles.
I think the main advantage is the builds are actually deterministic. Any Dockerfile with the equivalent of
apt-get update
But I believe NixOPs is the canonical way to do what you're describing in production/at scale:
https://github.com/NixOS/nixops
https://nixos.org/nixops/manual/
(more below)
If you want a more experienced answer, I suggest asking on the NixOS forum or subreddit, people are quick to answer in both places.
https://www.reddit.com/r/NixOS/
----
More useful NixOPs guides
https://www.thedroneely.com/posts/nixops-towards-the-final-f...
Our industry shamelessly imitates of the limping, stagnant, service economy in doing these things, and we call ourselves the future!
Nix is more (or less) than a container. It depends, what you are targeting with your nix-project. You can either build a minimal NixOS, that has only a kernel, the minimum required user land and your project and its dependencies.
Or build a stand alone docker (etc.) image and spin it up.
Or you can use the nix shell to replicate just the dependencies of your project in that sub shell for other developers or testing.
I just recently saw a convincing video about nix, comparing it to docker.
In fact, I will predict right now the death of Linux as a dominant backend computing platform. It's sort of happened already. Sure, Linux is the kernel that runs the host machines that the cloud runs on. But the services are increasingly serverless/kernel-less, or run on micro-vms running either Linux or another kernel, or run in containers made of a half dozen different base distros. All the Linux I/O is just passed to an outer layer with a universal adapter, so you can mix and match networking, filesystems, logging platforms, policy governance, orchestration, scheduling, etc. I spend nearly all of my time building systems by tuning software and services that have almost nothing to do with Linux.
Linux distros will still be around in one form or another. But long gone are the days where most people define their system or security based on a particular distro. Hell, most of the software used in the cloud today isn't even packaged by distros. Linux has become just a kernel again, the distros just a fancy installer for GNU tools.
They're using a lot of advanced tech and advertising having to "maintain fewer virtual computers", whatever that means. But it also seems their tech is more complex and less compatible with existing components. There's no clear idea of how a developer's supposed to take their code on their laptop, test it, and ship it to production as one immutable image. If it's not as simple as containers, it's not going to replace them.
Also, it's interesting that they seem to allude to immutability, but don't mention the principle by name at all. It seems like whomever is developing this doesn't run large distributed systems.