What is monolithic architecture in software?

Key features and components of monolithic applications

Most monolithic applications have the following characteristics:

• Single-tiered. This means that multiple components are combined into one large application. Consequently, the applications tend to have large codebases, which can be cumbersome to update and manage over time.
• Self-contained and unified. They are independent from other applications.
• Single codebase. If one component of the program needs to be updated, other elements might also require rewriting, and the whole application has to be recompiled, tested and deployed.
• Single database. They can use a relational database management system as a single data source.

Monolithic applications can include some or all of these components:

• Authorization. To authorize a user and allow them to use the application.
• Presentation. To handle HTTP requests and respond with Hypertext Markup Language, Extensible Markup Language or JavaScript Object Notation.
• Business logic. The underlying business rules that determine which functionalities and features should be included in the application.
• Database layer. Includes the data access objects that reach out to the application's database to achieve a specific goal.
• Notification module. Enables the application to send automated communications to users, such as through email.

What is an example of monolithic architecture?

To understand monolithic architecture, let's take an example of a banking application. Here's how it works:

• The application website authorizes customers.
• It logs them in to their account.
• Once they are in, they can check their account balance, download statements, transfer money to other accounts and perform other actions.

Several components are involved in this process, including the customer-facing user interface, plus back-end services for user authentication, authorization and customer actions.

If the application is monolithic, it is built and deployed as a single, unified, self-contained unit, regardless of how a customer uses it or where they access it from -- desktop, mobile device, etc. Also, it remains tightly coupled, and all the various components and modules are directly connected to each other. This means that if changes are needed for any one component, code changes are required for all other affected components as well.

Many well-known applications started off as monolithic and then adopted what is known as the microservices approach over time. These include the following apps:

• Spotify.
• Netflix.
• Facebook.
• Instagram.
• Uber.

That said, some applications have gone back to the monolithic approach after transitioning to a microservices architecture. One well-known example is Amazon Prime.

Some applications have remained true to their monolithic roots since inception. Examples include the WordPress content management system and Linux operating system kernel.

Advantages of monolithic architecture

Many applications are still created using the monolithic development paradigm because it offers several benefits.

For example, some monolithic programs might have better throughput and response times than modular, microservices-based applications, especially if the number of threads and users is small. They might also be easier to test and debug because they are composed of fewer elements and therefore involve fewer testing variables and scenarios.

The monolithic architecture simplifies development during the early stages of the software development lifecycle (SDLC). Deployment can be further simplified by copying the packaged application to a server. A single codebase simplifies logging, configuration management and application performance monitoring. Finally, multiple copies of the application can be placed behind a load balancer to enable horizontal scaling.

Disadvantages of monolithic architecture

Despite its benefits, monolithic architecture also presents several disadvantages:

1. The use of a single codebase means that a code update to one component of the application necessitates updates to all related components. This process can be time-consuming, which can delay application development and deployment, as well as limit the agility and speed of development teams. This drawback becomes especially significant for complex products or large teams.
2. Some applications have a large codebase, which can be difficult to understand. Poor understanding hinders developers from making required code modifications to meet changing business or technical requirements. As requirements evolve or become more complex, it becomes even harder to correctly implement changes without hampering code quality and application performance.
3. Following each update, 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, affecting the application's and team's agility.
4. The application's size can increase startup and response times.
5. Different parts of the application might have conflicting resource requirements. This makes it harder to find the resources required to scale the application.
6. Reliability is a concern with monolithic software. A bug in any one component can potentially bring down the entire application. Considering the previous banking application example: A memory leak in the user authorization module could end up making the entire application unavailable to users.
7. Finally, monolithic applications are not easily adaptable to new technologies due to their size and complexity, as well as the effort and costs involved in potential redevelopment. This can be a serious hurdle for small or budget-constrained organizations, leaving them unable to take advantage of a new programming language or framework.

What is the difference between monolithic and microservices architectures?

In monolithic architecture, the various components of the application are interdependent and controlled from a single codebase. Even small changes could affect large parts of the codebase. It's also time-consuming to make these changes because the entire codebase needs to be updated, and the entire application must be rebuilt and redeployed.

In contrast, a microservices architecture (MSA) consists of loosely coupled components, with each component based on a specific business logic and meant to accomplish a specific function. Code changes are easy when only a relevant part of the codebase needs to be updated. Also, the components that are changed can be individually tested and reliably deployed without the risk of bringing down the entire application. Components are also independently deployable, meaning that the entire application does not have to be redeployed for the changes to take effect.

Today, many organizations are moving away from monolithic architecture and adopting MSA because it offers multiple advantages:

• It supports modular applications, where any single module, such as a microservice, can be changed independently without affecting the other parts and without creating unanticipated changes within those elements.
• Modular programs are more adaptable to continual or iterative development and popular Agile practices compared with monolithic programs.
• They are also more scalable because each component gets its own resources that can be scaled independently of other components to match evolving requirements or demands.
• Modules communicate with each other through application programming interfaces and well-defined interfaces.
• Each module has its own database, which can improve application startup speed.
• It speeds up release cycles in that developers can push out updates as frequently as needed.

When to use monolithic vs. microservices architecture

At the beginning of the SDLC, it might be easier to go with a monolithic architecture. The approach is also suited for simple, lightweight applications or applications with a small number of expected users.

For more complex applications with frequent code changes expected, this monolithic approach is not suitable. In such situations, a microservices architecture might be the better choice. The microservices approach is also more suitable in the following cases:

• The application is meant to be scalable, easy to test and easy to maintain.
• There might be a need to independently deploy individual features or components.
• Continuous or frequent deployment is required.
• Teams need the freedom to work with new technologies, languages or tools.

Explore architecting beyond microservices and monoliths, see when not to use microservices, read about ways to survive the challenges of monolithic architectures and use these steps to break monoliths into microservices.