A monolithic application combines the user interface and data access layers for multiple features into one application. Usually, a monolithic application will exist as a single codebase that is modified by multiple teams within an organization, and be deployed as a single unit containing all the functionality that those teams maintain.

Monolithic applications can often be easier to develop and deploy thanks to the tight integration of their components. However, as the application’s scope and performance demands increase, a monolith can consequently become difficult to maintain and scale.

Examples of Monolithic Application Architectures

Monolithic systems can be a good fit for smaller, less complex applications that don’t need to quickly scale or be routinely maintained. Below are a few examples of applications that commonly have monolithic foundations (though their newer functionalities may be based on a more containerized infrastructure).

  • Ecommerce platforms – Monolithic applications are commonly seen in ecommerce because once the infrastructure is set up (building the online store, order processing, payment processing, and customer service), very few updates are required of the architecture.
  • Content Management Systems (CMS) – This very glossary entry was made possible by a monolithic application (WordPress). CMS applications, when deployed, contain all the functionality necessary for content management in the form of web pages.
  • Banking systems – Many financial systems are built as monolithic applications because the points of entry are limited, making it more secure. Additionally, upon deployment, the codebase contains all the functionality a consumer expects from an online banking experience: managing financial transactions, payment processing, and tracking.
Advantages of a Monolithic Architecture

While some aspects of monolithic architectures have become outdated, there are still many purposes and positive attributes.

Some advantages of monoliths include:

  • Simplicity – The centralized architecture makes monoliths easier to develop, deploy, and maintain when compared to more complex architectures such as microservices architectures.
  • Faster testing – By integrating every component into one program, a monolithic application can quickly be tested as a whole. Unlike architectures comprised of multiple, smaller components (e.g., microservices), there is no additional testing for complex communication protocols nor multiple code repositories.
  • Security – With fewer points of entry for bad actors, monoliths are generally easier to secure. It is also easier to enforce security protocols across one application versus managing multiple security configurations.
  • Cost – Deployed as a single unit, monoliths remove extra costs associated with deploying and securing additional communication protocols, building more connective infrastructure, and hiring employees with more specialized skills and training.
Disadvantages of a Monolithic Architecture

While the singular nature of monoliths has its positives, it can also lead to issues.

Some disadvantages of monoliths include:

  • Complexity creep – Over time, an application’s growth and added functionality can cause a monolithic architecture to grow larger and more complex. This sprawl increases the risk that an update could compromise the single codebase that keeps the entire program running smoothly.
  • Lack of scalability – When one feature or area of the application needs to scale horizontally, the entire large application (including subsystems that do not require additional resources) must be scaled. This can lead to both slowness in scaling since deployments take longer, as well as increased cost since each instance will have larger hardware requirements to run when compared to microservices.
  • Resilience – In a monolithic architecture, all application components are tightly linked and run from a central codebase. Therefore, if one fails, the entire application could go down.
  • Full redeployment – With a singular codebase representing the entire application, a monolith requires a full redeployment whenever a single component is changed or updated.
  • Technology stack – Because developers have to make sure any tools or languages they use will fit in with the monolith, choice is restricted. Also, many monolithic applications are written in ways that aren’t completely compatible with newer, more efficient technologies like cloud computing and containerization.
  • Slower development – When multiple development teams are working on one large codebase, extreme care is required to make sure interfaces and domain boundaries are respected and maintained. Sometimes, code can introduce complex coupling, making cross-team dependencies slow down the development of new features or fixes to critical issues.
What Is a Microservices Architecture?

In contrast to monolithic architecture, there is microservices architecture. Microservices is an approach to software architecture that builds a large, complex application from small components. These components can each perform a single function (e.g., authentication, notification, or payment processing) or work as bundles within a monolith. “Microservices” (or just “services”) is also the term for the small components themselves.

While monolithic apps are tightly coupled (meaning their components are interconnected), a microservices app is distributed (meaning their components can act independently). As applications grow larger and more complex, many organizations are exploring either migrating away from monoliths or incorporating new apps in a microservices format.

NGINX is proud to offer the following free educational resources for those exploring monolithic and microservices