Monolithic architecture

Monolithic architecture-based systems existed before the SOA or Microservices movement. These types of systems are exactly the opposite of what SOA tries to achieve.

A typical Monolithic system is an enterprise-based application, and this application might be in the form of a large website with all the working modules packaged in together into one single package, or it might be in the form of a service which talks to a website. It might be packaged as a large executable that is deployed on a machine.

In these systems, we added different components to an application to keep growing; there's no restriction in size, and there's no division. There's always one package which contains everything, and therefore, we end up with a large code base.

The high-level architecture diagram of a Monolithic system would look as follows:

Typical Monolithic architecture

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.

The only one advantage that a Monolithic system has is the fact that we can run the entire code base on one machine, so, when developing and testing, we could probably replicate the entire environment on a machine.

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.