This blogpost is part of a larger blog post series. Get the overview of the content here.
Now that we are aware of the fallacies of distributed computing let us step back and look into a traditionally built distributed system.
We all have been once down that path. Why tried to apply layers and tiers and hoped by introducing “remote procedure like” technologies everything would be fine. We dreamed about separation of concerns putting the right stuff where it belonged, like business logic. But how many times did we simply use the layers to pass data from layer to layer? We dreamed about reusability but how many times have we reused business logic across applications? We dreamed about scalability but how many times have we successfully scaled layers and tiers over servers? Despite our dreams we usually ended up with monolithic or even worse with a big ball of mud design. The system grows in functionality and interdependence at the same time. The modules used in the system have such a tight coupling amongst each other that they have no independent existence.
How can we stop falling into these pitfalls? We need to understand the different aspects of coupling! Which is covered in this post.
[…] Monolithic and Big Ball of Mud Systems […]
RT @planetgeekch: Composite UI for Service Oriented Systems – Monolithic and Big Ball of Mud Systems http://t.co/z8D2Yuh8qr