Advantages And Disadvantages of Monolith Architecture
there are several articles which complaints against monoliths architecture.
in this article I try to gather advantages and disadvantages of monolith architecture and put them together to make more clarity about this architecture.
Advantages of Monolith Architecture
there are many advantages that have led some of large applications to use this architecture in the first place
Business Flow Is Visible
With a single code base, we can inspect the end-to-end flow quickly. We can effortlessly find any feature we want since all functionality is in one repository. It is also easier to see the impacts of new developments since we can see the dependencies of that flow.
No Network Overhead and Limited External Dependencies
All the different modules call each other directly inside the application. There are no remote calls through the network through external APIs or event brokers.
Local Validation
In a monolith, it is possible to locally run the whole environment. Often, we can add and validate a feature by running a single application.
Code Reuse
Since all the code is right there inside the application, it is easy to reuse and build on top of existing functionality
Monitoring and Troubleshooting
Monitoring a monolith is straightforward since it is only one application. There is a reduced number of machines to monitor, and the logs are trivial to fetch. Troubleshooting an issue is also easier since the scope is reduced to one application.
End-to-End Testing
Since it is a single application, we can have automated tests that validate the whole application’s flow. Often end-to-end validations are contained in that application since they don’t depend on external services
Simpler Deployment Strategy
Since there is only one application, the deployment pipeline needs to account only for that application’s needs.
Data Is Centralized
the data is typically centralized in one or many accessible databases. If a new feature needs some kind of data, it can just go and fetch it from the database.
Consistency
Monoliths often use relational OLTP (online transaction processing) databases, which have strong consistency guarantees. These types of databases on monolithic applications typically enjoy ACID (atomicity, consistency, isolation, and durability) guarantees, which provide the traditional consistency guarantees we are used to;
Concurrency
In monolithic applications, we can deal with concurrency with the traditional strategies to handle race conditions, like locks or using the database.
Disadvantages of Monolith Architecture
When Monoliths Become the Business Constrictor Knot
Coupling and Lack of Boundaries
The main issue with monoliths is, given enough time, they become unbearably complex and coupled. Since all functionality is inside a single application, it is relatively easy to compromise each domain’s boundaries. With time, they fade and become entwined and hard to read. A single change might affect several parts of the system and has unpredictable impacts,
Team’s Autonomy
As the development team grows, it gets increasingly harder to work on a single application. Even with clearly defined modules, the development still requires communication and alignment, the deployment of the application needs coordination between the different teams. Depending on the development workflow, feature merges also become problematic. Feature branches will often lead to large merges with a high number of conflicts.
Release Cycle
The release cycle of a single monolithic application is usually larger than a micro-service. Even if a company adopts continuous delivery, the cycles will be inherently larger due to every release; no matter how small the change, the whole application must be validated and deployed. Validating the entire application at once requires a gigantic test suite that can take a considerable amount of time to run
Scaling
Most of the time, monoliths also nurture a monolithic database, which is very hard to scale. When the data starts to have a very high volume, it becomes problematic, especially with queries that require a lot of joins. Vertically scaling (increasing the number of resources, e.g., memory, CPU, etc.) is always an option for both the database and the application, but it gets costly very fast.
Outdated Technology Stack
Most of the time, monoliths are applications that have several years. Meanwhile, some of the technologies might have been discontinued. It goes beyond the usual technology hype of adopting something just because it’s the new best thing. If the application uses technology that is no longer supported by the company that made it, it is a concern.
Reliability
The risk of deploying a monolith is that any change can bring the whole application down. Even a change in a less critical part of the application can produce an issue (like a memory leak or unforeseen CPU usage) that can affect the whole application, and the whole application is every functionality.
