[
Lists Home |
Date Index |
Thread Index
]
[Bill de hÓra]
>Because at any given time code is being written to get 2 endpoints
>communicating, not n endpoints. The developers are in a hurry working
>under unrealistic deadlines and expectations. So, for any 2 endpoints
>and given enough developer stress, an RPC is the right thing (it gets
>the network out of the way quickly, so you can pretend you're writing
>procedural code in a single thread of execution). Even if you had 3 or 4
>endpoints, you can always decompose the comms into pairs (divide and
>conquer as anti-pattern). Then one day you wake up to find you have
>_lots_ of pairs making RPC calls and trying to reorder of repurpose some
>of them (or heaven forbid, their databases) without breaking something
>else somewhere else is extremely difficult; there's too many
>permutations and the network is suddenly not the sum of its parts
>anymore. You're out of control of the code.
Yup. Its point-to-point versus hub. point-to-point is faster
for setting up bilateral communications but the number of
interconnects is O(n-squared). Hubs require more up-front
work - message taxonomies, routing etc. but scale
O(n).
Sean
|
