There needs to be a distinction - because people are making an honest conflation - between distributed computing and cloud computing. The list in the article applies to both, but the limits and performance variability can apply quicker - and with more effect - in the cloud.
mrkeen 5 hours ago [-]
A couple more that don't seem to be represented there. No mention of cause and effect, or the order in which different nodes perceive things happening? Anyway here's three which I think might be more relevant to designing and building software:
* Your system is not a distributed system
Multiple users connect, disconnect, and use your system at the same time, some of the code is running on your servers, some of it's in your partners' servers, some of it's in your storage layer, and some of it's running on your users' computers
* Your DB's ACID transactions are sufficient for distributed thinking
An ACID transaction lets you addUser() to your storage, either succeeding completely or failing completely, with no observable intermediate state. It does not let both your frontend and your storage layer addUser(), same with both your storage and your partner's storage.
* Your DB's transactions are ACID
Your DB vendors cannot build databases that are acceptably fast while running ACID. Therefore isolation is relaxed and transactions can commit through each other. Even if the DB itself was ACID, your ORM and/or programming style is likely breaking ACID independently of the DB configuration.
anax32 2 hours ago [-]
* You will have logs
Always gets me
rusk 3 hours ago [-]
> No mention of cause and effect, or the order in which different nodes perceive things happening?
8. The network is homogeneous
Often misconstrued as a recapitulation of “there is one administrator”
A homogenous system, such as a single node Java application, for instance usually provides very clear semantics for this.
jffhn 6 hours ago [-]
Also, the four fallacies of local computing:
- The CPU is infinitely fast.
- RAM is infinite.
- CPU caches don't exist.
- Cache lines don't exist.
mojuba 6 hours ago [-]
- The computer is plugged to an infinite source of unlimited power
This was big before the mobile era and is true to this day to an extent. Many mainstream languages created in the 1990s (I call them "the children of the 1990s") were designed with this fallacy plus the ones you listed as a basis: JavaScript, Python, Ruby, Java, etc.
gf000 3 hours ago [-]
Java is basically the "greenest" managed language out there, so not sure putting it into the same list for energy efficiency is warranted. Though of course energy efficiency is fundamentally linked to memory usage, not destructing/collecting dead objects will increase memory usage but increase efficiency.
Reading your link IMHO in today's world I would set a basic rule, if you're touching >20% of a Java codebase you should refactor to Rust. With AI-Native development practices it's worth the SDE time to refactor, replace the underlying subsytem and reduce your fleet by 50% or more.
rusk 3 hours ago [-]
Indeed, the Java mobile platform had power consciousness baked in 25 or so years ago.
rusk 3 hours ago [-]
Was big before the AMD athlon. First commodity GHz processor was also the first to make obscene power demands.
adornKey 5 hours ago [-]
Today even tiny CPUs are really fast. Locally you have to mess up badly to run into trouble. But of course people will do exactly that...
Most real world problems still can be solved with 32-bit software, so the last ~20 years running out of RAM always counted as "using defective hardware". AI workloads now make things interesting again, but it's not that easy to hit the ceiling with real world workload.
Cache is indeed very important. Optimisations like that are gone when you go for distributed computing. Sometimes adding a single nop can do wonders. I wonder how many percent of developers have something in their toolbox to profile for that.
rusk 3 hours ago [-]
Arguably cache concerns are distributed computing concepts moving closer to the core. Same with concurrency semantics. These were far more exotic concepts when the fallacies were first written.
Very easy to hit the 3GB limit imposed by 32-bit architecture for any non trivial data processing app but luckily 64-bit is firmly established for at least 10 years
necovek 6 hours ago [-]
Disk never gets filled up.
jrpelkonen 11 hours ago [-]
In this instance latency must’ve been 10 years, per my memory this paper came out in 1994
rusk 7 hours ago [-]
According to Wikipedia it was first shown to Scott McNeally, but according to Deutsch himself it was more like 92…
zephen 10 hours ago [-]
On the one hand, the list isn't wrong.
On the other hand, more fortunes have been made by assuming that physics will catch up (closely enough, anyway) to computational needs, than by assuming that every byte and every cycle and every nanosecond matters.
shermantanktop 10 hours ago [-]
Making money and being highly available are different goals.
rusk 7 hours ago [-]
Stock markets and commercial Telecomms beg to differ
randfur 8 hours ago [-]
Do people actually believe these dot points or are they just out of scope for most applications to tackle beyond letting the user try again?
rusk 7 hours ago [-]
Perfect demonstration of the fallacies in action! If you were used to developing applications on a self contained platform you would think something like “sure, if it fails the user can try again”
On a distributed system the user can only try again if the platform has remained stable, the failure is transient (*) and they have (crucially) have been given the information to retry.
The platform that provides a stable environment for the user to just try again has been built on these principles.
(*) there is one administrator assumes it is within the user’s power to resolve the issue
rusk 7 hours ago [-]
This article reiterates a lot of the Wikipedia stuff, while contradicting the main extant source which is Deutsch himself (https://se-radio.net/2021/07/episode-470-l-peter-deutsch-on-...). Nobody really knows who wrote the first four fallacies. They were just floating around it is Deutsch who pinned them down and it was Gosling’s endorsement that made them into the shibboleth that they are.
aussieguy1234 7 hours ago [-]
This is highly relevant to the recent craze over microservices, which has settled down now (after un-neccasarily complicating systems at multiple companies).
rusk 7 hours ago [-]
Micoserices or Monolith. It’s like being caught between the devil and the deep blue see. It’s a pity domain sockets never took off but I guess TCP/IP is the only truly cross platform IPC mechanism …
Rendered at 12:46:18 GMT+0000 (Coordinated Universal Time) with Vercel.
* Your system is not a distributed system
Multiple users connect, disconnect, and use your system at the same time, some of the code is running on your servers, some of it's in your partners' servers, some of it's in your storage layer, and some of it's running on your users' computers
* Your DB's ACID transactions are sufficient for distributed thinking
An ACID transaction lets you addUser() to your storage, either succeeding completely or failing completely, with no observable intermediate state. It does not let both your frontend and your storage layer addUser(), same with both your storage and your partner's storage.
* Your DB's transactions are ACID
Your DB vendors cannot build databases that are acceptably fast while running ACID. Therefore isolation is relaxed and transactions can commit through each other. Even if the DB itself was ACID, your ORM and/or programming style is likely breaking ACID independently of the DB configuration.
Always gets me
8. The network is homogeneous
Often misconstrued as a recapitulation of “there is one administrator”
A homogenous system, such as a single node Java application, for instance usually provides very clear semantics for this.
- The CPU is infinitely fast.
- RAM is infinite.
- CPU caches don't exist.
- Cache lines don't exist.
This was big before the mobile era and is true to this day to an extent. Many mainstream languages created in the 1990s (I call them "the children of the 1990s") were designed with this fallacy plus the ones you listed as a basis: JavaScript, Python, Ruby, Java, etc.
https://www.sciencedirect.com/science/article/pii/S016764232...
Most real world problems still can be solved with 32-bit software, so the last ~20 years running out of RAM always counted as "using defective hardware". AI workloads now make things interesting again, but it's not that easy to hit the ceiling with real world workload.
Cache is indeed very important. Optimisations like that are gone when you go for distributed computing. Sometimes adding a single nop can do wonders. I wonder how many percent of developers have something in their toolbox to profile for that.
Very easy to hit the 3GB limit imposed by 32-bit architecture for any non trivial data processing app but luckily 64-bit is firmly established for at least 10 years
On the other hand, more fortunes have been made by assuming that physics will catch up (closely enough, anyway) to computational needs, than by assuming that every byte and every cycle and every nanosecond matters.
On a distributed system the user can only try again if the platform has remained stable, the failure is transient (*) and they have (crucially) have been given the information to retry.
The platform that provides a stable environment for the user to just try again has been built on these principles.
(*) there is one administrator assumes it is within the user’s power to resolve the issue