monolithic architecture

What is monolithic architecture?

A monolithic architecture is the traditional unified model for the design of a software program. Monolithic, in this context, means "composed all in one piece." According to the Cambridge dictionary, the adjective monolithic also means both "too large" and "unable to be changed."

Monolithic architecture for software explained

Monolithic software is designed to be self-contained, wherein the program's components or functions are tightly coupled rather than loosely coupled, like in modular software programs. In a monolithic architecture, each component and its associated components must all be present for code to be executed or compiled and for the software to run.

Monolithic applications are single-tiered, which means multiple components are combined into one large application. Consequently, they tend to have large codebases, which can be cumbersome to manage over time.

Furthermore, if one program component must be updated, other elements may also require rewriting, and the whole application has to be recompiled and tested. The process can be time-consuming and may limit the agility and speed of software development teams. Despite these issues, the approach is still in use because it does offer some advantages. Also, many early applications were developed as monolithic software, so the approach cannot be completely disregarded when those applications are still in use and require updates.

Understanding monolithic architecture with an example

To understand monolithic architecture, let's take an example of a banking application. The banking application website first authorizes customers, logs them in to their account and enables them to make online money transfers to other accounts. There are several components involved in this entire process, including the customer-facing user interface, plus services for user authentication, statement downloads, money transfers, etc.

If the application uses a monolithic architecture, it is built and deployed as a single application, regardless of how a customer uses it. Thus, whether users access the application from their desktop or from a mobile device, the application remains tightly coupled, and all the various components and modules are directly connected to each other. It may also use a relational database management system as a single data source. Finally, if changes are needed for any one component, code changes are required for all other affected components as well.

Key components of monolithic applications

Monolithic applications typically consist of multiple components that are interconnected to form one large application. These components may include these features:

• Authorization. To authorize a user and allow them to use the application.
• Presentation. To handle Hypertext Transfer Protocol requests and respond with Hypertext Markup Language, Extensible Markup Language or JavaScript Object Notation.
• Business logic. The underlying business logic that drives the application's functionality and features.
• Database layer. Includes the data access objects that access the application's database.
• Application integration. Controls and manages the application's integration with other services or data sources.

Some applications may also include a notification module to control and send automated email communications to users.

Benefits of monolithic architecture

There are benefits to monolithic architectures, which is why many applications are still created using this development paradigm. For one, monolithic programs may have better throughput than modular applications. They may also be easier to test and debug because, with fewer elements, there are fewer testing variables and scenarios that come into play.

At the beginning of the software development lifecycle, it is usually easier to go with the monolithic architecture since development can be simpler during the early stages. A single codebase also simplifies logging, configuration management, application performance monitoring and other development concerns. Deployment can also be easier by copying the packaged application to a server. Finally, multiple copies of the application can be placed behind a load balancer to scale it horizontally.

That said, the monolithic approach is usually better for simple, lightweight applications. For more complex applications with frequent expected code changes or evolving scalability requirements, this approach is not suitable.

Drawbacks of monolithic architecture

Generally, monolithic architectures suffer from drawbacks that can delay application development and deployment. These drawbacks become especially significant when the product's complexity increases or when the development team grows in size.

The codebase of monolithic applications can be difficult to understand because they may be extensive, which can make it difficult for new developers to modify the code to meet changing business or technical requirements. As requirements evolve or become more complex, it becomes difficult to correctly implement changes without hampering the quality of the code and affecting the overall operation of the application.

Following each update to a monolithic application, developers must compile the entire codebase and redeploy the full application rather than just the part that was updated. This makes continuous or regular deployments difficult, which then affects the application's and team's agility.

The application's size can also increase startup time and add to delays. In some cases, different parts of the application may have conflicting resource requirements. This makes it harder to find the resources required to scale the application.

In addition to limited scalability, reliability is another concern with monolithic software. A bug in any one component can potentially bring down the entire application. Considering the banking application example, suppose there's a memory leak in the user authorization module. This bug can bring the entire application down and make it unavailable to all users.

Finally, by virtue of their size and complexity, monolithic applications are not particularly adaptable to new technologies. A new development framework or language can affect the application as a whole, so adopting it can be both time-consuming and costly. Small organizations or companies on tight budgets may not have the funds or staff available to update the application, so they may end up maintaining the status quo, potentially leaving them unable to take advantage of a new language or framework.

Today, many organizations are moving away from monolith architectures and adopting a microservices architecture (MSA) because it offers multiple advantages.

Advantages of microservices architecture

MSA supports modular applications where any single module in a system, such as a microservice, can be changed independently without affecting the other parts of the program and without creating unanticipated changes within other elements.

Modular programs are also more adaptable to iterative development processes and Agile practices compared to monolithic programs. They are also more scalable and can be tested individually due to loose coupling between the various components. Modules also communicate with each other, have their own databases and increase application startup speed.

See application architecture, software development, source code, Agile software development, Lean software development, continuous software development, software development kit, release, artifact and software engineering.