Java Reference
In-Depth Information
Client
Load Balancer
User
Account
Service
Front-end views
(Payment view, customer
view, and so on)
Customer
Service
Data
Persistence
Store
Payment
Service
Stock Control
Service
FIGURE 15-3:
Monolithic architecture
The components are packaged together in a logical modular form and deployed as one single
monolithic application. It's a simple way to develop and deploy an application because there's
only one application to test. Integrated Development Environments (IDEs) and other development
tools are designed with the monolithic architecture in mind. Despite these benei ts of monolithic
architecture, applications built to this design are often very large.
A small application is easy for developers to come to grips with, to understand, and maintain, but
a large monolithic application can be difi cult, especially for those developers who have recently
joined the team. They may take many weeks or months to thoroughly understand the application.
Frequent deployments are not practical because they require the coordination of many developers
(and perhaps other departments). It may take hours or days to arrange a deployment, hindering
the testing of new features and bug i xes. A signii cant drawback to the monolithic design is that
it's difi cult to change the technology or framework. The application was developed based on
technology decisions made at the beginning of the project. You are stuck with these decisions; if a
technology is found that solves the problem in a more elegant or performant way, it is difi cult to
start using it. Rewriting an entire application is almost never an affordable option. The monolithic
architecture pattern does not lend itself well to scalability.
Scalability
Scalability
refers to an application's ability to grow (and shrink) as demand for its services changes
without noticeably affecting the user experience. A badly performing e‐commerce website loses
