The Fallacies of Distributed Computing

Essentially everyone, when they first build a distributed application, makes the following eight assumptions. All prove to be false in the long run and all cause big trouble and painful learning experiences.

The canonical eight fallacies, as posted on James Gosling’s Website [0], which he attributes to Peter Deutsch:

  1. The network is reliable
  2. Latency is zero
  3. Bandwidth is infinite
  4. The network is secure
  5. Topology doesn’t change
  6. There is one administrator
  7. Transport cost is zero
  8. The network is homogeneous

Deutsch [1] attributes the first four - The Fallacies of Networked Computing” - to various Sun figures, including Bill Joy and the Lyon brothers [3], but there seems to be little on the record of these specific gentlemen ever discussing them in detail. There seems even to be little from Dr Gosling himself!

In Peter Deutsch’s account, the first four were already established lore when he joined Sun in the early ’90s. Deutsch was tasked with evaluating the challenges posed by the burgeoning mobile networking segment, and in his report he cited the first four fallacies along with four of his own to CEO Scott McNealy.

James Gosling (widely recognised as the creator of Java), it is reported had already codified the first four, and atop Deutsch’s contribution he added fallacy number 8. The fallacies have held a prominent position on James Gosling’s website, as far back as archive.org will go (which is 2004 [4]), up to 2024 where he posted details of his retirement.

Relevance

It’s hard not to look at these nowadays and feel a pang of impatience. The terminilogy seems a little non-specific and the awkward inverted phrasing as “fallacies” seems unhelpful, like the whole tone of discussion is pointing out problems rather than proposing a solution.

The language hails from a time when the Internet was a much smaller place, where technical discourse was dominated by a (relatively) small number of people with graduate school educations and in all likelihood one or more PhDs. It was a time when knowledge was passed between people in riddles, aping the academic sport of their tutelage. This might help explain how understanding even the problem the fallacies are trying to describe, is seemingly left in part as an exercise for the reader.

Our axioms for a reality we understand so well become delusions when faced with phenomena we don’t. Where our pre-existing knowledge crowds out our intuitions about something. We might call these “hallucinations” these days.

Yet they were of a different kind, The names that stilled your childish play, They have gone about the world like wind, But little time had they to pray

It is also important to remember, and hard to overstate, the kind of genius that was endemic to and concentrated in Sun Microsystems at that time. It cannot be stressed enough just how far ahead of the networked computing game they were.

When the Internet blew up in the early ’90s Sun had a good 10 year march on most competitors in that space. They had a technical vision, and the know-how with which to implement to a degree that is rarely seen outside of strategic public institutions. They were a business that had an almost quasi-academic status.

The past is a foreign country: they do things differently there

A lot has happened since the early ’90s though. Lots and lots of things have happened in the field of distributed computing and networking:

To the degree that issues around distributed computing actually occupy the public mind, the fallacies seem passe. Nobody goes onto their smartphone in 2026 and expects a seamless computing experience. We have all internalised many of these lessons at this stage, and most software engineering students will blow past these issues at undergraduate level.

These realities are well represented in most modern architectures, platforms and APIs. Anything that hits a system boundary, even exposure to concurrency, usually has some sort of guide rails to steer the user’s awareness. In Java this is usually signalled by checked exceptions. Python takes a structural approach with context managers. In JavaScript it’s common to use observable with callbacks and promises to handle network operations asynchronously. Understanding and planning for the hazards in these situations is essential to writing stable and responsive applications.

Context

By the early ’90s the business world, academia and the military had become accustomed to commonplace cheap, reliable, flexible and robust Local Area Networks (LANs). Ethernet is the best known of this generation of networking technologies, and it’s still in widespread use and the spiritual ancestor of Wi-Fi. Ethernet provided a reliable, low latency, high bandwidth multi-user surface, for the cost of simple runs of copper cable.

Most people at that time according to John Gage [2], that were flooding the industry out of universities, the military and the corporate world were familiar with modern high speed reliable networking. At the local level it was a solved problem. Reliable point-to-point links were also, arguably a solved problem.

False assumptions that programmers new to distributed applications invariably make.

But these things being solved problems didn’t mean that everybody (then as now) knew how to solve them, or understood the tradeoffs that made them work. Bill Joy, one of Sun’s founding luminaries implemented TCP for BSD, as well as coming up with “vi” and being a key contributor to NFS (Networked File System). He also brought internet to Aspen as a dramatic proof of concept that presumably also drummed up a nice wedge of investor cash.

TCP is a protocol that specifically trades off latency and a little bit of bandwidth for end-to-end reliability. TCP specifically, to this day underpins most of the application layer internet traffic. BSD was Berkeley University’s distribution of Unix that became the foundation of most networked operating systems today, mostly because it was the product of geniuses but in no small part I’d say because it was free.

The Fallacies of Networked Computing

"The Network is the Computer"

There is an undeniable resonance to Sun’s slogan “The Network is the Computer”. The first four fallacies, known as “The Fallacies of Networked Computing” emerged from the engineering culture at Sun during those first 10 years or so, as they upheld this vision of a seamless multi-terminal user experience. These first four fallacies propose that reliability, latency, bandwidth and security are four factors that become ever more important as you scale out from a single node to a distributed system.

Local computing literally takes place in a box: an electromagnetically shielded box that provides a secure, stable, controlled environment for all the interacting components to work together in a tightly coupled, highly predicatable and stable manner. Faults do occur, components malfunction, the system can lose power and pieces can be hotswapped.

Distributed computing by its very nature takes place across many boxes, each with their own set of problems, joined by links that have their own issues too. On a good day each node and link can be individually reliable but each can fail independently, and without the central coordination offered by the operating system, failure modes are unpredictable.

(1) The Network is Reliable

Everything is broken

Personal computers have been designed since time immemorial to fail well. The innate, mind boggling, deeply integrated and intimate coupling of these complex devices puts them beyond meaningful analysis and service by all but the most specialised technicians. For such complex and expensive devices to be viable they must have a predictable failure mode and straightforward path to recovery. Much thought has gone into making failure predictable and safe in the face of catastrophic conditions up to, including and beyond sudden power loss.

It is possible for many of the same problems that happen on a network to happen within a computer but, if a failure happens “in the box” it can be controlled and mitigated, and if it can’t the operating system can step in and terminate the process or halt the system. In the worst case scenario you can “turn it off and then on again”. There is a single locus of control.

Even if a network is reliable, it cannot provide the same kind of reliability that can be expected in the local computing environment even at the best of times; it cannot be relied upon to remain reliable over any significant period of time; and when it fails it cannot be relied upon to fail reliably.

That’s when everything is going well, on a lightly loaded, small co-located, well-configured network. If the characteristics of the network change: nodes come and go; adverse environments introduce noise; the network scales across multiple site; then things get remarkably worse.

The distributed nature of the system also, naturally makes troubleshooting and resolving faults more difficult as they arise. There isn’t one power switch where you can just “turn it off and then on again”, there could be a few power buttons, maybe locked in a server room, maybe on the other side of the world!

(2) Latency is zero

In the simplest case, the execution of a local function call usually takes a small number of cycles, with a latency of mere nanoseconds. More complex memory and disk access will have latency orders of magnitude apart. Once things get to the PCI bus life looks increasingly like a network [5] and latencies start to reflect that but there is still one locus of control, a single operating system tying everything together.

The networking stack is a sophisticated piece of machinery that upholds the illusion of network reliability. It is composed of protocols, software and hardware that all impose overhead, add latency and consume bandwidth.

An application may have to allocate and copy memory, and engage other system resources such as sockets, indirectly calling hundreds of functions, across multiple libraries and communicating back and forth with the operating system. The operating system communicates with the device drivers, and back and forth with the application a few times, accruing microseconds or even milliseconds before a single bit is sent.

Then back the other way again, when receiving data there’s the whole unpredictable nature of inbound traffic to deal with: error correction, interrupt handling, context switching, shared state and buffering. All these factors incur their own costs and add their own dimension of complexity at the application layer.

As we go about our business day to day we don’t really think too much about these internal latencies. Even the 8-bit generation, the heyday of gaming and personal computing could provide the user and application developer with an experience that felt effectively latency-free.

According to Waldo and Co [6] latency is one of the most immediately obvious issues with networked computing, and for all that the least insidious: an operation that has completed with a bit of a delay is at least an operation that has completed and we can stop worrying about it …

We will typically measure the latency of application operations on a local network in milliseconds. It doesn’t seem so bad. It seems like on a neat, lightly burdened, well managed network you could make that look transparent. But then consider that it’s not that unusual to be making more than thousands of operations and if you’re blocking on each and every one (as you would with a “local” function call) you’re starting to measure your latency in seconds.

In less ideal cases, things get worse quickly. Network structure can increase latency significantly, and once packets start getting routed over slower links, across continents, under the sea or even through outer space, latency can increase quite dramatically, by an order of magnitude or more.

Some links are inherently lossy, operate in noisy environments (machinery, poorly shielded electrical equipment), or are badly congested. All those aggregated latencies begin to add up very quickly and as soon as anything goes wrong things can cascade out of control. The reliability mechanisms provided by the stack start to kick in, detecting loss or corruption, retransmitting packets, signalling back and forth - all of which introduce more latency.

Most worryingly, the latencies introduced by reliability mechanisms are far less predictable, and are largely site- and situation-dependent. On a beleaguered link these latencies can cascade with timeouts leading to queueing issues leading to further timeouts and so on.

Under adverse conditions packets may be lost, or dropped by overloaded routers. At what point does your “transparent” network operation give up and accept that its response is not coming back? What is an application do, then, if handling network latency isn’t part of its design?

(3) Bandwidth is infinite

Never underestimate the bandwidth of a station wagon full of tapes hurtling down the highway.

Bandwidth is the maximum rate at which data can be transmitted over a link. It is typically measured in Mbps or Gbps (millions or billions of bits per second); as with latency, on a nice fast local network or link you might get away with not worrying about it. A link may be congested or may have multiple hops, and the hop with the least bandwidth (the “bottleneck”) will constrain the overall bandwidth.

Unlike latency, it’s something of a moving target. Latency has a lower bound linked to the speed of light. In the late ’90s you might get a 56kbps link to the Internet if you were lucky. Five years later we were talking megabits, and gigabit home internet links are fairly common in many parts of the world. A modern LAN can typically provide a gigabit connection, and 2.5 and even 5G LAN are becoming more common. We have seen similar trends in wireless and mobile data.

Yet the more bandwidth we get, the more uses we have for that bandwidth, but even with multiple video streams you might struggle to exhaust many modern home internet services. The foregoing statement perhaps even being an instance of this fallacy, were I to base my reasoning on the assumption that most people have fast internet.

So it’s easy to see how, when you’re writing an application, one might not consider the bandwidth of your connection, or your impact upon it. Parallel to latency issues, the often unexpected scale of computing and the nature of shared network resources can lead to unpredictable consequences. As networks get congested, latency increases as traffic gets buffered. Packets get dropped and the retransmissions consume additional bandwidth, which causes yet more congestion.

I think it’s safe to say many of us (as I try to carefully steer around the fallacy) have been at a public event where the local cell tower is overloaded, and mobile devices can’t connect in any meaningful way. If the site has not been provisioned for all this extra footfall - perhaps by adding new cells, and additional backhaul bandwidth - the system’s modest bandwidth is exceeded at some point.

Anyone, anywhere that has ever used unmetered public Wi-Fi ever, will appreciate this. Because there is no disincentive to access, aggregate utilisation increases to the point where the multitude devices are scrapping it out for every little bit of bandwidth, consuming yet more and more bandwidth with retransmissions, increasing latency to the point where the network becomes sluggish and unusable.

(4) The network is secure

It would be hard to find somebody nowadays that hasn’t some notion of network security. Internet security takes up a significant proportion of the news cycle: usually some sort of data breach, compromised institution or scam warning. Terms like ransomware, viruses, phishing, spam are all part of the public lexicon. There is this extra burden that goes with technology use nowadays, where you just always have to maintain awareness of security hazards, know how to spot scams, and steer clear of getting hacked.

In the early ’90s, the security landscape wasn’t quite so vibrant. Hacks and viruses were a real and present threat, but things weren’t as interconnected as they are now. Encryption was in use but local networking relied to a large degree on physical security. At that time, global “enterprise” networks were forming, linking various sites in Wide Area Networks, and these went some way to present an illusion of a homogeneous global network. Security at this scale was a factor, but usually once you were in you were in.

It’s strange to think how lax everyone was about security for many years after that. The original 802.11 release of Wi-Fi had ridiculously poor security and it was commonly known how to crack a neighbours’s key to get free internet. A lot of people didn’t even secure their Wi-Fi anyway, or even update well-known default router passwords. It would have been understood that HTTPS was essential for online shopping or banking, and the browser lock symbol came to mean “safe”. There was a security awareness, but it was selective, perhaps complacent.

There was of course a continuum of security, and business environments were more readily embracing security, in particular as global enterprise increased the heterogeneity of corporate networks. In the public space people had experienced deceptive software such as BonziBuddy, aggressive adware, “pop-ups” and other progressively worse kinds of malware, as well as the ever-present worms and viruses. A general level of security awareness was growing perhaps linearly as the Internet and communications technology became ever more pervasive and ubiquitous.

The big inflection point however, was the WikiLeaks publications and Snowden disclosures that revealed how all those niggling little security holes that people were dimly aware of and really weren’t anything to worry about anyway were being exploited by state actors at industrial scale, with apparently little compartmentalisation. People naturally asked the question that if Snowden was able to access all this information and disseminate it, then who else had access and was being more discreet about it?

Wave after wave of institutional hacks, data breaches and SMS scams have intensified public awareness. Vulnerability tracking and remediation is a routine part of business nowadays. A proliferation of detection tools makes it easy to scan applications and detect published vulnerabilities. Keeping pace with the security landscape and keeping organisations aligned with best practices and new legal and regulatory obligations driven by Schrems II, GDPR and DORA is a big part of modern business.

Nowadays it’s common to have HTTPS everywhere, and the browser lock symbol is just one of numerous hygiene signals. Unsecured websites are now actively discouraged by popular search engines and show as “insecure” in modern web browsers. Zero trust, layered security practices and the “defence in depth” principle don’t confer trust based simply on already being in the system: all network connections must be secured, even connections within the same machine aren’t automatically trusted, which actually isn’t as bad as it sounds, once you take into account network transparency and the nature of software evolution.

The Organisational Fallacies

Though attributed to Deutsch by Gosling, Deutsch only takes credit exclusively for the following three. It’s helpful to read these in a different voice. If the first four are the howling restless spirits of Sun Microsystems then this is a calm, singular voice of an experienced principal, explaining organisational realities.

(5) Topology doesn’t change

Topology is the structure or layout of the network. It determines the routes that traffic may take between nodes, it influences bandwidth, latency, cost, reliability and in some cases can even be a matter of security and compliance. Topology can be logical (determined by routing rules, quality of service policy or cost) and topology can be physical, which relates to the actual structure of the cabling, interconnects and wireless coverage.

These days it doesn’t seem that unusual that network topology can change. Cellular phones are built on the very principles of accepting and managing active, continuous topology change. Not only can UE (User Equipment) move between cells, but they can effortlessly move between networks (roaming), and live calls and data streams can be handed over between cells without interruption.

Back in the ’90s when Deutsch formulated this fallacy, specifically couched in the problem space of mobile networks, cellular technology was established but it was very limited. Cellular networks had been established around metropolitan areas. These were not very sophisticated devices by today’s standards, basically full-duplex walkie-talkies but they solved the fundamental problem of how to set up a voice circuit to a device that may change location?

Wireless data was a few years off in the cellular space at that time. Well-read users might point out the University of Hawaii’s “ALOHAnet”. A spiritual ancestor of Ethernet, it used wireless as a shared medium, but didn’t really concern itself with matters of mobility or location. But regular wired Ethernet and the evolving corporate enterprise space provided fuel for the imagination.

At that time business networks were growing quite rapidly around the world, with global links broadening the scope of the network day by day. As these networks grew and expanded, topology change at the macro level was a natural fact of life. The flexible, ad hoc nature of Ethernet also meant that local network topology on the ground was flexible and dynamic. Topology change was a necessary feature of the evolving business technology landscape at that time.

According to Deutsch, the Internet Protocol doesn’t really handle topology change well [1]. The notion of an IP address, by its very nature linked to the local “subnetwork” does not lend itself to portability, and so you must have a dynamic pool of addresses in each subnet that will be mapped to inbound roaming devices. In the classical stack, the dynamic nature of the network is supported better by the Domain Name System (DNS), so the recommendation is that applications should refer to nodes by their hostname, rather than their address.

There are better ways to do this now: IPv6 has a much larger address space that permits globally unique addresses, but is still network dependent in terms of routing. Mobile IP adds mobility features on top of classical IP and IPv6, with support for continuity and routing between networks.

In modern mobile networks (GSM, UMTS, LTE and 5G) UE-oriented routing has always been the norm, with a “Home Location Register” (a high-availability subscriber location database) managing the routing to a globally unique IMSI (International Mobile Subscriber Identity) embedded in the subscriber’s SIM card. A VLR (Visitor Location Register) manages guest roamers in a network, and communicates back to a subscriber’s home network’s HLR. Later generations split out the mobility function to a more dynamic and scalable Mobility Management Entity (MME) and Access and Mobility Function for LTE/4G and 5G respectively.

(6) There is one administrator

Save me Jebus

We have all received that message before: “contact the administrator” - and the implication is always the same “I give up. Find someone who knows what’s going on and get them to fix it”. If we can determine who that person is we could usually find them away from their desk, attending some other crisis.

“Turn it off and then on again” might be their weary advice. It might seem like a silly punchline from an old comedy show but it is sound technical advice for a single node device that has failed.

In such a situation the implication is clear. There is one administrator, the user and they are on their own. It is up to you to reset the box and run the gauntlet of possible data corruption. In one fell swoop the slate is cleaned: state is cleared and the machine’s automatic recovery routines kick in.

For the networked application things may not be so straightforward. Application state may be spread across multiple systems, each one at least in principle with its own power button. Processes may be running on different nodes that might be confused by collaborators suddenly disappearing or rejoining as though nothing has happened.

In the early days of networking it might have been feasible to have a single administrator sitting over a single local network, managing the cabling, setting up the switches and managing the devices on the network. Even at that level you’re already demanding a fairly adaptable, hands-on skillset with a diverse set of competencies. It wasn’t uncommon to see sites with admin team specialised towards separate Windows and Unix estates.

As networks spread out across the globe linking sites then you had to have site-based admins, and as more and more people used networks and the workload increased teams began to form and coalesce into the “IT organisation”, a shadow organisation within the enterprise culture. As networks matured and developed around specific business support services the IT organisation fragmented further into dedicated application support silos. Now where the lines have blurred is IT service companies “vendoring” into organisations providing their own staff to people the corporate structure.

In the current digital services landscape it is common to have multiple accounts across various network links. At the front we have our mobile phone service, TV and Internet services. Sometimes these are fused together in a bundle but when you have an issue you will get routed to different personnel.

Then we have OTT services like our messaging apps, music streaming, news, AI and search, etc and we understand that these can all have outages separately and we know there is no point calling up our mobile phone provider if our messaging or streaming app is down.

To support the possible many admins, or lone user (zero admins), it’s important to provide enough information to determine application health, and diagnose issues and to make that easily accessible. It is also important to provide some sort of control surface to manage application lifecycle and accessible configuration.

To these ends, the original TCP/IP suite of protocols included SNMP (Simple Network Management Protocol) and Java introduced JMX for exporting counters and events, and providing an object-oriented control and configuration API. Observability has always been important for network equipment, but historically has been a bit more patchy in the enterprise space, with logging used for diagnostics rather than monitoring.

The last ten years, though have seen observability elevated from the system domain up to the level of enterprise applications. Ingestion and indexing with ELK (Elasticsearch, Logstash & Kibana) provide a platform for proactive monitoring. Spring Boot provides lightweight low-effort observability through actuator end points, and these hook into Kubernetes’s own health monitoring features. Prometheus is another popular option for observability, and Grafana is hugely popular for operational dashboards.

(7) Transport cost is zero

Everybody owes, everybody pays, that’s how you stand up, in the rising of the tide

Lots of people have trouble with this one, because many people get flat-rate high-speed uncapped data access at home, at work and on their mobile device. Businesses and academia have similarly had high bandwidth access for many years. We as end users don’t have to come to terms with the costs of our data. But somebody somewhere is paying for it, and it’s mostly probably not for charity.

But apart from actual monetary costs, there are other costs to consider. For mobile and most remote use cases, power consumption is a factor, and unmoderated radio transmission can really drain a battery. Some devices only come on sporadically, for seconds at a time, a few times a day. Anything in outer space, or on another planet, really has to watch its bandwidth budget.

There are also the bandwidth constraints discussed earlier, and indeed latency increases too, which can have a cost in terms of user experience.

There are lots of interesting remote scenarios that act on constrained expensive links. Anything with a satellite uplink, or anything that needs its own cable or line-of-sight antenna. Backhaul for wireless operators forms a significant part of operating costs, and there are many other types of businesses that buy, sell and arbitrate bandwidth costs.

It really doesn’t seem that long ago (perhaps 2010, or so) that tethering your mobile phone was a neat trick, that could bankrupt you if you weren’t careful. Downloading the Irish Times front page alone could cost a couple of euro, but it was competitive for text messaging when the cost of a single SMS was 15 cents or more.

Even going abroad now, which used to cause palpitations as we checked and double-checked to make sure our data roaming was off, or bought pre-paid roaming minutes as part of the pre-holiday ritual, is a relatively stress-free privilege, as most networks have pretty competitive roaming packages now.

Maritime mobile service is still quite expensive. It’s not uncommon to see eye-watering tariffs (e.g. 2c per megabyte; €2.99 per minute). Receiving such a tariff notification SMS can induce some old-style panic as we scramble to disable data roaming, even cellular data altogether.

When out at sea, out of range of the terrestrial networks, data must be routed over a more expensive link, typically satellite. There also aren’t the same rules around billing when connecting to a non-terrestrial link, so users are actively disincentivised from using the service except in desperate circumstances. It might comfort the reader to know that some consumer protections may still apply around billing transparency and charging ceiling in that case.

The elimination of punitive charging, and the establishment of reasonable roaming charges were actual institutional policy for many telecomms regulators across Europe and beyond (“Bill Shock” and “Roam Like at Home” were active EU policies). The rationale was to address an economic deadweight: consumers were afraid to use online services due to the financial risk exposure, which led to less dynamism in digital services.

Think of all the money that has been saved for businesses by people dealing with them online. Think of all the new business opportunities, all the online stores, all that frictionless economic activity on our mobile devices. All that economic growth, all that extra value accrued to businesses, the workforce and investors. There you go now.

Metered billing is still a thing in many parts of the world, and that’s something I’d like to look into and expand upon shortly. In particular, in emerging economies where mobile wireless forms a nascent digital infrastructure, and as communities reap the benefits, the underlying costs become a part of daily life.

Away from the consumer space, at the coal face of data transport there is a lot of work that goes into upholding the transparent, flat-rate experience. Long distance links may be time-metered or charged based on reserved capacities, so aggregating traffic to maximise utilisation is a serious business concern. Similarly satellite bandwidth is expensive as we discussed, and network operators bear the capital costs of building their network, and the operational costs of maintaining it. A lot of thought goes into cost optimisation on one end, and ensuring profitability on the other. Merely buying and selling capacity, and arbitrating costs between links is itself big business.

The implications of this fallacy are that one must “check their privilege” when it comes to network use: unlike local activity we must account for the cost of our network use. This goes hand in glove with bandwidth, which we can consider the cost ceiling, but we must also consider frequency of access, and volume overall as these have implications for power usage and perhaps even cost for the user, the network operator or your business.

The Eighth Fallacy

Who are these bozos

There is a slight bit of confusion around fallacy number 8. In a 2021 interview [1] Deutsch does not dispute the canonical 8, but he does present an alternative fallacy. It seems likely to me that the eighth fallacy as it stands was intended to be a more general (perhaps less pugnacious) form, where homogeneity may be thought to include Deutsch’s trust concerns, as well as more commonly considered system factors as interoperability, performance and access. Although this may seem a little clumsy at first glance, it makes a neat statement about the integrated nature of security, at every layer.

(8a) We all trust each other

Considered an extension of fallacy 4 (The network is secure), this fallacy captures the concern that, even though the link is secured, what’s going on at either end may not be. It also captures the defence-in-depth principle that “in a layered system, security can be lost at any level” [1]; it proposes that all parties to a secure exchange may not all “be on the same team”.

The concept of a secure connection does not extend to malicious, or uncareful users, or a compromised user acting under duress. End-to-end encryption may shield you from “man-in-the-middle” attacks, but it doesn’t protect against a compromised endpoint, unsecured backups or unauthorised recipients. Attackers can gain access to accounts, or use social engineering techniques to access authorised channels.

Deutsch says that we go to all this trouble to ensure that the link is secure, and the payload is untouched, but then we also have to think about what’s in the payload [1]. Questions arise such as whether it is carrying malware? Is it leaking sensitive information inadvertently? Who is sending or receiving the data, and are they who they say they are? If they are, then do we know where they are? Is that location secure? Is this traffic facilitating malicious intent, and who decides what that is?

(8b) The network is homogeneous

variety is the spice of life

Insofar as I believe James Gosling’s addition to the fallacies to be a generalisation of Deutsch’s original security concerns (i.e. the user-base is homogeneous and trusted), the popular interpretation of fallacy 8 does not appear to follow this and relates more to interoperability.

We might imagine a homogeneous system, at the most extreme end as being a tightly integrated, tightly coupled system with identical or similar nodes or devices all using an identical set of protocols, operating system and application stack. In such a system concerns about interoperability would go away, and you could expect to have a uniform and “correct” way of doing things and all the actors would provide a similar set of features, reliability, diagnostics and failure modes.

This is at odds with our modern experience of the network, where all sorts of devices based on Windows, Mac, Linux, Android, Tizen, EPOC, ond whatever is running on all those little IoT devices. These all typically communicate using well known standards such as Ethernet, Wi-Fi or Zigbee at the physical layer and various well known and established transport and application layer protocols (TCP, UCP, SCTP, RTSP, HTTP, TLS etc).

It’s not hard to imagine a homogeneous environment though. Perhaps a LAN with only Windows PCs, or a home network with only apple devices. A business solution built entirely on a single stack might also qualify for this classification.

Supporting heterogeneity though brings about a whole other set of virtues however. Thinking about how applications integrate forces us to think about interactions and how those can be managed and controlled. It brings about standards that are reviewed in the open and makes a whole panorama of observability and transparency possible. It provides a platform for growth as different vendors can come together to suit different specialisations.

The downsides of a homogeneous approach (Eric S. Raymond’s “Cathedral”) is you are typically tied to a closed platform and you are tied to whomever is providing or certifying that. Opportunities for extension and when it comes to diagnostics and monitoring you are largely dependent on the good grace of the vendor or consortium that provides the technology.

There is also an impact to reliability. The lack of community oversight permits short cuts, tight coupling, and system flaws can be reproduced right across the network. One situation that comes to mind is around Mac OS Mavericks where Apple rewrite the DNS service and apparently did a terrible job of it. The issues with the DNS service affected not only individual macs but also seeped across the network confusing other apple devices with its botched value-add features. Heterogeneous networks were less affected.

There is strength in diversity. Supporting diversity promotes openness which is good for transparency. The essence of the Internet is its heterogeneity, built on simple open protocols. Local, and wireless networks all support a variety of different classes of device over simple, open protocols.

It is fitting that this last fallacy is attributed to Gosling. Arguably Java’s “write once, run anywhere” philosophy provides a homogenisation layer over all the different hardware and networking stacks. It brings things back together again in a coherent systems architecture that provides many of the advantages of a homogeneous architecture while actively ensuring the heterogeneous underpinnings all work as expected.

Later Fallacies

A distributed system is one in which the failure of a computer you didn’t even know existed can render your own computer unusable.

References

Further Reading

I highly recommend the Oxide podcast series, to hear some great war stories from various personalities from this time of heroes.

Thank You!

For reading this far. I’m enjoying putting this together and there is more detail to come I promise ;-)

AI Statement

This article is my own words and analysis. Insights developed as I researched this “the old fashioned way” using Google, Wikipedia and archive.org. I used ChatGPT to help fill holes in my understanding where I couldn’t otherwise, and I used it for proofing.