My experience of using NixOps as an Ansible user
blog.wearewizards.io
blog.wearewizards.io
I would love to get to the point where I could do immutable deploys in real life. We're getting closer by using Docker, but we're encountering a number of hard problems, one of which is simply finding ways to keep all of the images up-to-date with all of the recent packages.
That said, convincing a company to use Nix (which is still relatively immature, in the grand scheme of things) is going to be an uphill battle. When you can stand up a fresh VM using Ansible in a few minutes, the value of being able to roll a server back easily is hard to justify.
It's also hard to justify when you have to wait for a third party to decide to update their core packages. It took nix two days to build new packages for heartbleed, Ubuntu and CentOS were updated that day. How much longer could you be waiting on a fix which wasn't so broadly publicized?
That said, I think the benefits of Nix are real. The existing configuration management systems do not have the ability to fully understand the system. Nix does, because everything about the system is contained in the configuration file. As a consequence, you can up and down grade servers without fear of breaking everything. You can check to see exactly what changes between different versions. There is much more control and more assurance that the nodes are in the proper state.
One part of your comment which I do not understand is:
> When you can stand up a fresh VM using Ansible in a few minutes, the value of being able to roll a server back easily is hard to justify.
Isn't this also true for Nix? You just launch the image and push your desired configuration? If you mean time to write a new ansible playbook/role then in my experience, although I am fairly productive with ansible, I would not put it at "a few minutes" from nothing to a new service. Maybe you are talking about the learning curve? Nix definitely seems steeper so a clear win for ansible on that front.
Check out bosh: http://bosh.cloudfoundry.org/ . It has a somewhat similar philosophy with respect to immutable instances and systems at large, and has strong corporate backing.
Nix predates all the other technologies you listed, with the possible exception of Chef, which I can't pinpoint a concrete date or even year of origin.
That's not to say that we never have configuration issues, but mostly they come from weirdness in 3-party packages. For example, recent versions of `node-pg` (postgresql bindings for node) have an implicit dependency: if you want to use the native library instead of the pure-Javascript implementation, you must also install `pg-native` alongside pg. That's just in the README, though, there's no peerDependency declared in pg's package.json file, so npm2nix can't generate the appropriate nix expressions.
Using nix definitely gives you the sense of swimming upstream, because the rest of the world doesn't understand this stuff and doesn't care. But for us, it's been worth it.
The remaining build step, then, is copying the new closure of the environment to the machine on deploy, which can take some time depending on your network. Instead I think what you'd probably do is use Hydra (a CI server) to actually build the packages/closure of your network on every commit to your repository, and then add that server to your actual deployment server's binary caches - that way when you deploy things after CI allows it, the needed assets will already be on the remote (faster) binary cache, within your network.
I used Radmind and for all it's old school complexity and faults you could roll back production changes really easily. That was hugely powerful.