A monolithic application describes a single-tiered software application combining the user interface and data access code.
Monolithic Application Expalined
A monolithic application is self-contained, and independent from other computing applications. The design philosophy is that the application is responsible not just for a particular task. But can also perform every step needed to complete a particular function.
Today, some personal finance applications are monolithic. In the sense that they help the user carry out a complete task, end to end. And are “private data silos” rather than parts of a larger system of applications that work together. Some word processors are monolithic applications. These applications are sometimes associated with mainframe computers. In software engineering, a monolithic application describes a software application. Which is designed without modularity.
Modularity is desirable, in general. As it supports reuse of parts of the application logic. And also facilitates maintenance by allowing repair or replacement of parts of the application without requiring wholesale replacement.
Code-based modularity allows developers to reuse and repair parts of the application. Object-based modularity provides the application as a collection of separate executable files. Hence, without redeploying the entire application. Some object messaging capabilities allow object-based applications to be distributed across multiple computers. Service-oriented architectures use specific communication standards and protocols to communicate between modules.
Components of Monolithic Application
- Authorization — responsible for authorizing a user
- Presentation — responsible for handling HTTP requests and responding with either HTML or JSON/XML (for web services APIs).
- Business logic — the application’s business logic.
- Database layer — data access objects responsible for accessing the database.
- Application integration — integration with other services (e.g. via messaging or REST API). Or integration with any other Data sources.
- Notification module — responsible for sending email notifications whenever needed.
- Simple to develop — At the beginning of a project it is much easier to go with Monolithic Architecture.
- Simple to test. For example, you can implement end-to-end testing by simply launching the application and testing the UI with Selenium.
- Simple to deploy. You have to copy the packaged application to a server.
- Simple to scale horizontally by running multiple copies behind a load balancer.
- Maintenance — If Application is too large and complex to understand entirely, it is challenging to make changes fast and correctly.
- The size of the application can slow down the start-up time.
- You must redeploy the entire application on each update.
- Monolithic applications can also be challenging to scale when different modules have conflicting resource requirements.
- Reliability — Bug in any module (e.g. memory leak) can potentially bring down the entire process. Moreover, since all instances of the application are identical, that bug impact the availability of the entire application
- Regardless of how easy the initial stages may seem, Monolithic applications have difficulty to adopting new and advance technologies. Since changes in languages or frameworks affect an entire application, it requires efforts to thoroughly work with the app details, hence it is costly considering both time and efforts.
The monolithic approach is common, and many organizations are developing with this architectural method. Many enjoy good enough results, whereas others encounter limits. Many designed their applications in this model because the tools and infrastructure were too difficult to build SOAs, and they did not see the need. Hence, until the app grew.