Overheads of Monolithic architecture

In the long run, enterprises faced these shortcomings when they applied Monolithic architecture to their systems:

• Due to the code base being so large, it took the teams longer to develop a new functionality within the application.
• Deployment of a large system can also be challenging, because even for a small bug fix, we have to deploy a new version of the entire system, and therefore, that creates greater risk.
• It's one large code base, so, we're also stuck with one technology stack.
• It makes the overall system less competitive, because we can't easily adopt new technologies which might give us a competitive edge.
• Since the code is in one large package, we might also have high levels of coupling, which means that if a change is made in one part of the system, it might affect another part of the system, because the code is intertwined. This kind of coupling might be present between modules, and also between different services.
• Scaling up this service to meet the demand is quite inefficient. For example, if the Orders module of the system is in demand, we would have to create a copy of the whole package, of the whole service, in order to scale up just the Orders section.
• More powerful servers need to be bought to work efficiently for a large footprint of monolithic apps.
• Unit testing for such a large code base takes time, and regression testing by QA is also a time-consuming process.

An example of a Monolithic system could be an ASP.NET MVC site where the website itself is the UI layer, and then in the Business layer, you have business logic along with the data access layer. Over the years, if we continue with the same approach, then it will become a Monolithic system.