Traditionally, references in programs are "linked" so that they execute as sequential instructions. E.g., a function is invoked in a single instruction which, to the CPU, looks no different than any other instruction/opcode.
DLLs defer the linkage to run-time but essentially use a similar mechanism (with a level of indirection interposed that is "filled in" by the loader before the program actually starts running.
As I compartmentalize to a very high degree, the "function" call is actually to a bit of code in another process container. So, the OS has to get involved to bridge the protection domains (with client and server -side stubs to marshal/unmarshal).
[Remote Procedure Call / Remote Method Invocation]Because of this, there is an opportunity to interrupt this process, selectively. So, instead of directing the RMI to process #457 (which is the process that handled it a few instructions prior), it can now be redirected to process #962 -- which, by careful design, has exactly the same ABI as process #457.
So, to install an update, you start the updated process. Then, tell the OS to direct any NEW requests to *it* instead of the previous process -- which may still be running and handling some OTHER requests.
When the previous process has finished whatever work it was performing, you can terminate it and reclaim its resources -- the "new/updated" process taking over its previous functionality.
So, there is no real cost penalty beyond whatever cost difference there is in the new version of the process vs. the old version.
If I choose to migrate the process (or its replacement/update) to another node, then the client-side stub (for the updated process) forwards the request to that other node, over the wire. In this case, there is a higher invocation cost (in terms of time) but it gives you the flexibility of moving processes to nodes that have more resources available to provide those services.
When you contact a web site, you have no idea which physical machine will be handling your request *or* whether or not it has seen components updated in the interval from the previous request you issued seconds earlier. You don't care. As long as the interface to the site doesn't change...
"Components" can also be chunks of software. E.g., I can change the implementation of a particular function/module and the "user" need be none the wiser -- as long as I maintain the contract specified in the ABI.
Traditionally, software isn't designed with these sorts of mechanisms in place as they have higher invocation overheads. No free lunch.
But, the approach is considerably more scalable, robust and easier to develop (as well as deploy). (Most enterprises use a similar approach -- "microservices")