I think we need to add a fallacy about serialization and protocol changes, but I'm not sure how to summarize it in a simple sentence.<p>Specifically, "magic" serializers often have problems interoperating with different languages; or with different versions of a protocol.<p>I've come across serious problems where:<p>- An application's deserializer can't handle a new value included in a new version of a protocol, and thus crashes.<p>- A server needs to forward part of a serialized object unmodified to another server. It strips out unrecognized values, thus requiring that we upgrade all three pieces of software instead of only two.<p>- A server's serializer is so rigid that we can't add xml tags / attributes without lots of involvement with the team that works on the server; even though there's no real reason for them to be involved in all the details
I don't recall seeing this explanation before, though I'm pretty sure I've read a version of it.<p>What I noticed immediately was what I felt was something missing in explanation of fallacy #1 (The network is reliable), something I predicted decades ago when the network gear salesmen first came around to try and convince us to replace our aging concentrators (multiport hubs) with fancy new switches: losing the backpressure mechanism of collisions would lead to bandwidth-related failures.<p>The article's explanation mentions the reliablity of modern switches but makes a fairly shallow dismissal of this by referencing things like pulled power cords but spends most of the text actually talking about WAN reliability.<p>What I've seen in practice is, including with (maybe even especially with) distributed computing environments, is the scenario I proposed to the salesperson way back when: What happens when two servers send data out of their network ports at full line speed (100Mb/s) each, at the same time, for a total of 200Mb/s, to another server's network port that can only receive 100Mb/s?<p>Of course, once the switch's buffer fills up, half the packets get dropped, and it's not practically deterministic which half. In a distribute environment, where the number of sources greater than 2 and the number of sinks is greater than 1, it gets even less so and often more intermittent.