Earlier quoted context omitted.
> No, they aren't. The entire point of the big ball of mud is that there are no meaningful divisions in the code. Everything uses everything willy-nilly, at the smallest possible level of abstraction. There is, metaphorically if not always entirely literally, not a single line of code in the system that you can change without fear of bringing something else down that you may not have even known they existed. This is…
Funny, I was thinking of linking to that page myself in support and decided against it. I particularly was thinking of: "What does this muddy code look like to the programmers in the trenches who must confront it? Data structures may be haphazardly constructed, or even next to non-existent. Everything talks to everything else. Every shred of important state data may be global. There are those who might construe this…
Multiple, different services sharing the same database seems comparable to global state under BBOM. This shared database is a back channel.
Furthermore, as the article describes, if you don't define your domain boundaries correctly then changes are not necessarily confined to a single microservice.
As for blowing up a service three layers away, of course this can still happen. Just because you inserted the network between those layers doesn't mean that layer 1 can't produce outputs that triggers an edge case in layer 3 that wasn't properly tested. Similar failure modes are mostly all still there, it's just easier to violate certain good practices in a monolithic system. Maybe that means it happens more often in the BBOM, but that doesn't mean it doesn't happen at all with microservices.
I think the article broke this all down exactly right. Microservices pushes complexity into infrastructure, and sometimes that's good, but often you want that complexity in code and encapsulated in well-designed abstractions that are enforced by the language (like a good module system).