* 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.
* Hardware is cheap.
So many services and daemons are running on your system and most of them believe that they have all the hardware for themselves, while the opposite is true. Designing to capitalize whole hardware while they are other processes which are fighting to do the same never ends well.
OTOH, being a good citizen on a crowded system makes life for everyone better. Both maintenance and performance-wise.
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...
Rust has overly strict locking (otherwise it couldn't determine safety) that makes certain concurrent algorithms harder to implement, its concurrency model is significantly more complex (for an absolutely good reason, it's a low-level language where the developer should be in control), meanwhile for many applications Java can just have you write ordinary blocking code and they will automagically turn into non-blocking.
For most domains Java has a richer "industry-strength" library ecosystem, and absolutely not even close observability tools. So not really sure what would one win for e.g. a typical backend service doing web and db requests.
Internet pointz
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
These FTP sessions were running over WANs connecting Pennsylvania, Iowa, and Tennessee.
I ended up writing him an "until curl ftp://...; do echo it failed again; done" loop which calmed that particular issue down.
I don't miss that guy, not even 1%. Good riddance.
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
Later, when users are confused at failures and weird states. >ok now lets build a new system that tries to gather all this information on updates in "weird states" and let users fix them!
simplified example, but nightmare.
Either way, it’s no excuses for shipping slop, which is what you’ve done it your software only works under limited idealised circumstances
TFA is for you
Gosling still has them on his present day site https://nighthacks.com/jag/blog/401/index.html
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.
Reality: embedded systems are a thing. And there's (lots of!) money in that business too. There's maaaany applications where some (fixed) amount of compute does the job, and the simplest/cheapest device that does it wins out.
My biggest career horror was realizing how much the medical informatics concepts have been structured around billing and insurance rather than scientific, biomedical requirements.
These are large, highly profitable vertical markets.
The above remark is demonstrably foolish and ignorant.
Making money and being highly available often different goals.
Can you be highly available without making money?
And btw I've worked in both the industries you cite. It's hard to think of telecomms having amazing uptime when you have to write a restart script for a core security daemon because the sysadmin doesn't know how.
This is what they’re teaching kids in school now. Dawww conputerz
I don’t think either that or domain sockets are quite as ubiquitous as TCP sockets though.
The issue I see with domain sockets is that although they may be supported for example by spring, you can’t rely on a consistent cross platform experience which is perhaps (anachronistically?) a core ethic of the Java community.
I would favour domain sockets as to make a component go from being embedded to networked would require a small but significant implementation step.
But established best practice unfortunately disagrees with me.