a non-concrete configuration, also known as a module (or profile sometimes), which is just a lambda ({ lib, ... }: etc) or an attribute set with values for options.
or, a fully instantiated, concrete nixosConfigurations.${x}, constructed with nixosSystem
You can go from the prior to the latter, but not back.
NixOps is a dynamic deployment tool in the sense that some configuration isn’t statically known, or at least in general it is not, as it supports the creation of new machines whose statically unknown metadata can be accessed in the configuration. Crucially, NixOps will call an equivalent of nixosSystem for you with extra modules.
nixos-rebuild on the other hand is a deployment tool that needs one of these fully concrete configurations. It will not call nixosSystem for you.
It used to be that nixos-rebuild worked on modules instead of already-nixosSystem-ed configurations, so this is still a bit of a new phenomenon between NixOS and NixOps.
Modules are still as reusable as they ever were, so if you really want to use both nixops and nixos-rebuild, you could achieve that by moving your configuration into nixosModules first, refactoring it into a structure as I’ve suggested here.
A simpler setup perhaps is to use just one tool. nixos-rebuild is arguably the simpler one, but it can do remote deployments too! Use nixos-rebuild --target-host some-ssh-host.
If you’re allocating machines or using other cloud resources, I’d recommend to stick to nixops.
I’d read that a few times, but it didn’t really click until the more in-depth explanation you provided here. Now it makes sense.
Certainly simpler, but at this stage in my nix journey I’m exploring the options available
With an improved mental model I was able to come up with a satisfactory configuration that is pretty DRY, allows me to reuse my existing infrastructure for local machines, and also have a nixops-able configuration for one remote machine: