Monolithic Architecture

In the first part on web application architectures, we briefly visited client-server model, multitier architecture, and layered architecture. While the client-server model and the multitier architecture discussed how the application was divided over one or more tiers (logical entities or servers), layered architecture focused on how the code of an application was separated into logical entities.

Here, we discuss briefly monolithic architecture. The term monolith refers to "an organized whole that acts as a single unified powerful or influential force" (Merriam-Webster), and the term monolithic architecture refers to an application that is a single coherent unit where all the code is in the same directory hierarchy and where the application is deployed as a single unit.

Applications that use monolithic architecture may contain a user interface (view templates, javascript, images, ...), a server-side application responsible for handling requests, and the functionality related to handling database requests. The database can be separate from the application, but the database could be also included in the application. The key is that the server-side functionality is built as a single unit, and the functionality provided by the application resides in the same codebase.

As an example, the Task Management Application from Application Example I has monolithic architecture. The application follows a layered architecture, where the code is divided into logical entities, and a multitier architecture, where the functionality of the application is divided over the client, the server-side application, and the database. The application code is in the same directory hierarchy, and the application is deployed as a single unit.

When new functionality is added to an application with monolithic architecture, the application as a whole must be deployed again when the functionality is put to production. Similarly, if one would wish to increase the throughput or performance of such an application, one approach would be increase the amount of servers and add a load balancer that would distribute the incoming requests to the web servers. The key here is that each new web server would run the whole application; that is, it would not matter which server the client would be forwarded to by the load balancer as all of them behave the same way.

Monolithic applications can be tested in multiple ways. One can test individual components or functions, one can test the HTTP interfaces of the application, and one can -- naturally -- do manual testing. One can also mock functions, interfaces, etc. Monolithic applications are straightforward to test and deploy using continuous integration and continuous deployment as the application can be deployed as a whole.

Similarly, software developers can also typically launch the application as a whole on their computers, likely (hopefully!) adjusting the database configuration so that a development database is used instead of a production database.

However, as the size of the application grows, maintaining an understandable internal structure of the codebase becomes harder. In our examples, we have included all service functionality in a folder called services and all controller functionality within a folder called controllers that resides within a folder routes. If there are tens of controllers and dozens of services, and the developer does not know the application well enough, it can be tempting to simply mimic the existing code and add a new controller instead of studying how the application works and e.g. and refactoring the application codebase to improve it.

With the increasing size of the application, the need to deploy the whole application after every change can also be somewhat cumbersome. For example, if we would adjust the title of the task application or add styles to it, we would have to deploy the whole application, including the server-side functionality, even if those would not have been touched at all. The larger the application is, the longer it also takes to start up after deployment, which can result in poor user experience if the deployment process or timeline is not well thought out.

Increased size of an application also tends to lead to increased commitment to an application and the technology used by the application. The sunk cost fallacy stipulates that people in general have a greater tendency to continue investing time and other resources into an effort once an investment to that effort has already been made. With the relatively rapid development of technologies and frameworks, investment into an application may lead to a situation where resources will be redirected to that application also in the future.

Also, considering the scalability; while it is easy to add new servers that host the application, it is possible that only small parts of the application are those that really need to scale, while the majority of the application requires rather little resources.

To summarize, a monolithic architecture is an architectural pattern where the application is developed and deployed as a whole. The benefits of monolithic architecture include easiness in developing, deploying, and scaling. However, as the size of an application grows, it can become harder to maintain and develop, the deployment times can become longer, and one may become dependent on the used technologies.

Although monolithic architecture has been critizised, there are arguments for starting new projects using a monolith-first approach, i.e. initially building the project using a monolithic architecture, and only later consider refactoring the architecture.