Parts of Pythomnic application therefore run on separate machines called "nodes", each part in its own separate Python process called "cage".

All cages are technically identical, although within your application each will likely perform its own specific functions clearly defined by the developer. Most likely, some cages will stay on "perimeter", accepting requests directly from the application clients (other applications or systems or from the users directly). Other cages will in turn perform background processing of the accepted requests. Yet other will interface to other systems whose services are required.

Some of the benefits of having the application partitioned like that are the following:

A cage can be migrated from one node to another by simply copying the files over, and all the other cages will become aware without any reconfiguration.

Although each cage is performing its own specific function, more than one instance of the same cage can be run, presumably on different nodes. This allows adding redundancy to the application very simply.

Separate processes, even more so running on separate machines, add significantly to the reliability of the application, allowing it to survive hardware failures or process crashes. This also helps when you have to stop one of the servers for maintenance.

Since multiple identical cages can be run simultaneously, each of them can be handling a share of a load. This load balancing is only a side effect and is not perfect or even.

Python supports hardware threads but is very ineffective with respect to multithreaded CPU-bound applications performance. Having more than one cage even at the same node will utilize the so hailed multiple cores at the expense of inter-process communication.