distributed monolith: how teams and organizations undo the advantages and benefits of distributed systems?

Syed Khader
February 12, 2020

Distributed Monolith: How teams and organizations undo the advantages and benefits of distributed systems build using micro-services, micro-frontends or any similar architectural pattern and convert those systems to Distributed Monolith?

We all might have heard, read and used micro-services, micro-fontends, FaaS.etc. and know their advantages, disadvantages, pros and cons. This article is not about how good are micro-services or micro-frontends or any other distributed architectural patterns. It is on a practice to encourage a team or organization that started to use and adapt these patterns then stick to their teachings and purpose. There are multiple scenarios that can create the side-effect which we are referring to and in this article let us focus only on shared dependencies.

Teams and Organizations might have adapted these patterns mainly because of their advantages and to add business value. However, one main factor that we forget to adapt is mindset change. We start clean but go back to the same patterns of shared components or libraries, shared sub-systems or central Design systems. etc. As an example if multiple systems share same libraries or sub-systems or components managed by central team or by some other means then those distributed systems are compromised and can be referred as Distributed Monolith.

Creating these shared/common components, libraries and other sub-systems, too early is one of the many things that can go wrong easily. It is natural to think standards, practices and tempting to create Foundation Frameworks and Design Systems, with all common functionality abstracted out into central library(s) that may be used across all applications or some. However, experience gives us evidence that it’s difficult to guess what other systems need before one have real-world usage of them, which results in a lot of upfront design and development in the early life of a component or library. For that reason, prefer to let teams create their own components and libraries within their codebases as they needed them, even if that causes some duplication initially and allow the system’s designs and patterns to emerge and evolve naturally.

Points to ponder upon and consider before jumping on to creating such common and shared dependencies

  • Ownership and governance of those systems, components and libraries. etc. (who owns it?). Do you have capacity?
  • Such shared models degrade innovation by introducing constraints and limitations.
  • Compromising autonomy of a team and the system/product.
  • Creates dependency on different teams and systems thus slows down development and limits how fast can a product move and narrows communication (Conway’s law).
  • Backward and forward compatibility with systems that are dependent on such components.
  • Technical dependencies and anti-polyglot systems.
  • High probability of creating a Distributed-monolithic.

There are many other things but above are just a glimpse of what we can expect and should consider if not in early stages of development but eventually before it is too late.

Conclusion: If you are into Distributed systems using architectural patterns such as micro-services, micro-frontends, autonomous products. etc. then consider mindset change to adapt to why those patterns exists and what problems they are solving.


Designing & Building Architecture for Microservices

Designing Fine-Grained Systems

Monolith to Microservices [Evolutionary Patterns to Transform Your Monolith].

And Experience

%d bloggers like this: