Microservices are hard
No, they aren&#x27;t. The entire point of the big ball of mud is that there are <i>no</i> 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.<p>Microservices are not a miracle cure or the solution to every problem, but they do <i>force</i> divisions within the code base. Every microservice defines an interface for its input and its output. It may be the sloppiest, crappiest definition every, with dynamic types and ill-defined APIs and bizarre side effects, but it is <i>some</i> sort of definition, and that means if necessary, the entire microservice could be entirely replaced with some new chunk of code without affecting the rest of the system, cleanly cut along the API lines. This microservice may sloppily call dozens of others, but that can be seen and replicated. It may be called by a sloppy combination of other services, but the incoming API could be replicated.<p>However bad the architecture of the microservice may be, however bad the overall architecture of the microservice-based system as a whole may be, this will be true by structural necessity. The network layer defines some sort of module.<p>They can create big balls of spaghetti, certainly. They can in total create a big mess; they are not magical architectural magic by any means. While a full replacement of a given microservice is practical and possible, if the boundaries are not drawn correctly to start with, fixing <i>that</i> can be much harder in a microservice architecture (with corresponding separation of teams) than a monolith.<p>But they fail to create the situation that is what I would consider the distinguishing characteristic of a &quot;Big Ball of Mud&quot;, where there are no partitions between anything at all. Big Balls of Mud have no equivalent of &quot;replace this microservice&quot;. Microservices by necessity, to be &quot;microservices&quot;, have partitions.