Monolithic architectures have been a cornerstone in software development for many years. However, as the industry has evolved, the term "monolith" has taken on various forms and meanings.
In this blog we will discuss three types of monoliths: Singular Monolith, Distributed Monolith, and Third-party Monolith. We will also delve into different types of coupling, exploring their impact on these monoliths and why they can be detrimental.
A Singular Monolith is a traditional monolithic architecture in which an entire application is built as a single, self-contained unit. All components, such as the frontend, backend, and database, are tightly integrated, making it difficult to change or scale individual parts.
Example: A classic e-commerce application where the frontend, backend, product catalogue, user management, and payment processing are all part of a single codebase.
In a Singular Monolith, implementation coupling and domain coupling are the most prevalent types. Implementation coupling occurs when components depend on each other's internal implementation details, making it challenging to modify one without affecting the others. Domain coupling refers to the tight interconnection between different business domains, which can lead to a lack of modularity and make it difficult to evolve the system.
To cope with implementation and domain coupling in Singular Monoliths, consider the following strategies:
Adopt a modular design: Organize the codebase into separate modules based on business domains, encapsulating functionality and minimizing inter-module dependencies.
Implement clear interfaces: Define clear contracts between components, avoiding dependencies on internal implementation details.
Use the Dependency Inversion Principle: Depend on abstractions rather than concrete implementations to promote loose coupling.
Apply domain-driven design (DDD): Utilize DDD principles to build a ubiquitous language, aligning the software design with the business domain and reducing domain coupling.
A Distributed Monolith is an architecture where individual components are physically separated and communicate via network protocols, but they still exhibit tight coupling and maintain dependencies on each other. It is often seen as an anti-pattern that arises when attempting to transition from a monolithic to a microservices architecture without properly addressing the underlying issues.
Example: A modular banking system where account management, loans, and customer support services are deployed separately but have strong dependencies on shared libraries, making it difficult to update one service without affecting others. Additionally, errors in one system may take down another due to high coupling.
Distributed Monoliths suffer mainly from temporal and deployment coupling. Temporal coupling arises when the order or timing of operations between components becomes critical, making the system fragile and hard to maintain. Deployment coupling occurs when changes or errors in one component force the redeployment of other components, hindering the ability to deploy and scale services independently.
To address temporal and deployment coupling in Distributed Monoliths, consider the following strategies:
Embrace asynchronous communication: Use message queues, event-driven architectures, or reactive programming to decouple components and allow for more flexibility in communication.
Implement independent deployment pipelines: Ensure each component can be deployed and scaled independently, minimizing the impact of changes in one component on others.
Define clear contracts and versioning: Establish well-defined interfaces between components and apply versioning strategies to maintain backward compatibility and reduce the impact of changes.
Apply the Single Responsibility Principle: Design components to have a single responsibility, reducing the likelihood of changes in one component affecting others.
A Third-party Monolith is a system where a significant portion of the application's functionality is provided by external, third-party services or libraries. This type of monolith can lead to a high degree of dependency on external components, reducing control and increasing the risk of vendor lock-in.
Example: A content management system (CMS) that heavily relies on third-party plugins for features like SEO, social media integration, and analytics, making it challenging to maintain and update the core CMS without potentially breaking compatibility with these plugins.
Third-party Monoliths are primarily affected by deployment coupling, as the system's reliance on external components can limit the ability to make changes and deploy new features. Additionally, this type of monolith may also face domain coupling if the third-party components are closely tied to specific business domains.
To manage deployment and domain coupling challenges in Third-party Monoliths, consider the following strategies:
Evaluate third-party dependencies: Carefully assess third-party components for stability, maintainability, and compatibility before integrating them into your system.
Implement abstraction layers: Introduce abstraction layers between your application and third-party components to minimize direct dependencies and provide flexibility in replacing or updating components.
Monitor third-party components: Keep track of updates, security patches, and potential issues with third-party components to proactively address potential problems.
Consider building in-house alternatives: If a third-party component is tightly coupled to your core business domain or imposes significant constraints, consider developing a custom solution tailored to your specific needs.
Monoliths, despite their reputation for complexity and rigidity, can still be an appropriate choice for certain applications. Understanding the different types of monoliths—Singular, Distributed, and Third-party—and the coupling challenges inherent to each is crucial in managing and maintaining these systems effectively.
Singular Monoliths, the classic monolithic application, often suffer from implementation and domain coupling. By adopting modular design principles, clear interfaces, dependency inversion, and domain-driven design, it is possible to reduce the impact of these coupling challenges and improve maintainability.
Distributed Monoliths, which have the appearance of a microservices architecture but still exhibit monolithic characteristics, often struggle with temporal and deployment coupling. Embracing asynchronous communication, independent deployment pipelines, clear contracts with versioning, and the Single Responsibility Principle can help mitigate these challenges.
Lastly, Third-party Monoliths, which are heavily reliant on third-party components, face deployment and domain coupling issues. Evaluating third-party dependencies, implementing abstraction layers, monitoring components, and considering in-house alternatives can help manage these challenges.
Each type of monolith has unique coupling challenges, but by understanding these challenges and applying appropriate mitigation strategies, it is possible to develop and maintain effective monolithic applications that meet the evolving needs of your business.
Is it possible to modernise critical legacy systems whilst maintaining business as usual? This was the theme of a recent techUK panel event where..
In January 2022, the last version of AngularJS left support. There will be no official updates or security patches for AngularJS ever again.
In the first part of his series on Modernising the Public Sector, Carlo looked at the risks of failing to modernise legacy systems which range from..
