> 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 bit of a strawman. The equivalent strawman criticism for microservices is that every function runs in its own networked service. Is that truly representative of the reality? Of course not, and neither is your breakdown of big ball of mud.
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 as a sort of blackboard approach [Buschmann 1996], but it more closely resembles a grab bag of undifferentiated state. Where state information is compartmentalized, it may be passed promiscuously about though Byzantine back channels that circumvent the system's original structure."
and
"Such code can become a personal fiefdom, since the author care barely understand it anymore, and no one else can come close. Once simple repairs become all day affairs, as the code turns to mud. It becomes increasingly difficult for management to tell how long such repairs ought to take. Simple objectives turn into trench warfare. Everyone becomes resigned to a turgid pace. Some even come to prefer it, hiding in their cozy foxholes, and making their two line-per-day repairs."
Superficially it may seem like these criticisms apply, but they don't.
Microservice architectures can't have big global variables typing things together, structurally. Even if "everything talks to everything" (which is actually unlikely, sarcasm aside, even the absolute worst systems have more structure than that in a microservice architecture), it does it through a defined mechanism of RPC. State can't be passed through "back channels" because no back channels exist; you must go over the network, which is the "front" channel, not a back channel.
By structural necessity, a microservice confines the scope of changes in the microservice code itself. There are then of course still scopes of changes that are even harder with microservices at the global level, but for refactorings that aren't behavior changes a microservice necessarily confines the scope of changes to the microservice itself, a small fraction of the whole. As long as the API accepts the same input and returns the same output, it can not blow up another service three layers away because it has no access. But that's a distinguishing characteristic of a Big Ball of Mud.
Big Ball of Mud isn't just a slur; it's a distinct pattern as described in that paper. At best a microservice architecture can be a lot of smaller "balls of mud" hooked together, and that's still a problem, but it is its own problem. This is proved by the fact that the solution to a Big Ball of Mud won't work for an microservices architecture disaster... indeed, they aren't even sensible. If two problems require separate solutions and the solution to one is not even conceivably applicable to the other (that is, not even a "bad" solution but simply no solution at all), they are clearly not the same problem.
You can have comparable problems with microservices. Those BBOM problems you highlight occur when good development practices are ignored. So if good development practices are ignored under microservices, what can happen?
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).
> which is actually unlikely, sarcasm aside, even the absolute worst systems have more structure than that in a microservice architecture
Nope, the absolute worst systems have the same complex circular dependencies as monolithic BBOMs, the microservices just call into each over the network rather as function calls (imagine for example an API request into service A that calls into service B that calls back into service A). You may argue that makes it not a true microservices architecture, but one could make the same claim about a modular monolith.
> Microservice architectures can't have big global variables typing things together, structurally.
Oh sure they can, just call it “the DB”. Shared state between services/components is the most debilitating mistake I’ve had to deal with over the years. It doesn’t matter if it’s a monolithic, shared memory desktop app or a highly distributed architecture with central storage.
This is bit of a strawman. The equivalent strawman criticism for microservices is that every function runs in its own networked service. Is that truly representative of the reality? Of course not, and neither is your breakdown of big ball of mud.
I think this is a fair analysis of the BBOM:
http://www.laputan.org/mud/mud.html