My Master's thesis was on high performance distributed computing. And my conclusion was you likely don't have a problem that is hard enough to justify it. Thank you for promoting reality!
https://shopify.engineering/software-release-culture-shopify
"We split off 2 things in to small services because it made sense" is rather different. I mean, I don't really care if you call this 'microservices" I guess, but it is different, right?
Or create organizational problems.
- "Who owns the flip-flop service?"
- "That's Bob's team, we fired them last summer!".
"That's Bob's team..."
So unless you're using managed services e.g. RDS you're going to be exposed to the same complexities as distributed computing.
Especially with the cloud where instances can die at any point.
Edit: To be clear, I agree that this is an example of distributed, high-performance which is why the comment made little sense to me.
Nothing will run at that scale on a single VPS. All companies will have a wide range of languages used.
If this is not Rails supporting high traffic then what do we need more?
What you seem to be getting at, isn't distributed systems, but the totally self-inflicted pain of a service oriented architecture
Having spent the last 28 years building distributed network-connected systems, this comes across as wildly obtuse.
The point is that there are orders of magnitude differences in complexity when scaling a system with few communications paths and little distribution of state across process or network boundaries as there is when scaling one with many paths and state distributed in many locations. We don't tend to start talking about distributed systems when you have a tiered stack of a horizontally scalable component sandwiched between a load balancer and a database even though in a very strict technical sense already that is "distributed".
Once you start adding message queues etc., then it certainly becomes more and more reasonable to talk about a distributed system, but there is there as well a distinct grey area if dealing with e.g. queues just triggering jobs in the same code base against the same database with respect to the intent clearly expressed by the original comment.
Put another way, ignore the word "distributed", re-read the original comment, and consider that irrespective of which label you're comfortable with, what the comment is doing is drawing a distinction between two classes of systems with wildly different complexity in the distribution of responsibility and state. Where precisely you draw the line is entirely irrelevant.
> What you seem to be getting at, isn't distributed systems, but the totally self-inflicted pain of a service oriented architecture
No, it really was not. This separation between basic 2/3 tier apps and systems with a more complex data flow pre-dates the SOA buzzword literally by decades.