Utilización de imágenes como recurso gráfico

A monolithic application or system is built as a single unit. As an application, that generally means one binary entry point that relies on zero or more libraries or assemblies. As a system, that means several binary entry points (or processes) that rely on the execution or presence of one or more other processes. A monolithic system could be based on a client-server or n-tiered architecture such that the processes consist of a front-end user interface, a middleware or business logic tier, and a back-end data tier. An n-tier application like this is "monolithic" when higher-level tiers cannot function without the ability to connect to the lower-level tiers and when all the tiers need to be deployed at once.

97

Symptoms and Consequences

With greenfield systems, the monolithic architecture most closely matches the initial production deployment of the application. The planning of the initial deployment can often near-sightedly influence the architecture of the system. Initially there may be little consequence to this architectural pattern, but over time this architecture can cause friction with maintenance and updates.

Updates to a system may be small or large. With small updates, a monolithic architecture requires the entire system to be updated at once. This has several negative consequences. The major consequence of course is that as the system becomes more complex over time, deployment becomes more and more time- consuming and riskier.

It’s highly-coupled. With any software development project, the aspect that causes pain requires that that pain be felt continuously and compensated for in order for that the pain to be addressed. Monolithic architecture accepts and promotes a high degree of coupling. As time moves on, monolithic architectures become more and more resistant to change. Those changes often include change in topology, change in platform, change in resources, etc. The needs and atmosphere of a system change over time. With no need to address coupling as part of the architecture, the monolithic architecture does not view tight coupling as a pain-point, so it is not addressed inherently nor continuously.

Required change often revolves around the use and processing performed by the system. It's not out of the ordinary to see usage of a system go up over time, resulting in the system performing more and more processing. A monolithic architecture is tightly coupled to the hardware resources that it is deployed to. As a system is required to support more and more users (and as a result, more and more processing power), a monolithic architecture consequently limits the degree to which it can scale to support extra processing by limiting vertical scalability. A monolithic system is hard to change to different quantities of hardware resources (horizontal scaling) and scales only by faster and larger resources (vertical scaling). Vertical scaling is limited and costly.

A monolithic system is highly-coupled. Any change to one part of the system often has a far-reaching ripple effect throughout the rest of the system. If a small change cannot be made to a system without having many adverse effects to the rest of the system, it's likely a monolithic system.

Causes

Simplicity. A monolithic system is easy to reason about. Coupling is usually logical or obvious and easy to understand. The resulting system probably has one or very few "moving parts" (components to deploy), making the system easy to deploy.

Anemic requirements. Requirements that lack depth and are narrow of focus can make a project or system appear simpler than it actually is. If the system is viewed too simply, a monolithic architecture may seem like the best solution when it fact the actual complexity would result in it being counterproductive.

Focusing on one platform. Often when a system is implemented in one and only one platform, there is a tendency to put all the components together. This is partially due to the fact that it's possible to put all the components together. The resulting monolith actively prevents the use of other platforms and reduces the system’s agility or response to change.

Lack of cohesiveness. Cohesiveness in software development and architecture was defined by Edward Yourdon and Larry Constantine as the degree to which the elements of a [component] belong together . Without thought or analysis of cohesive sub-components of a system, the cohesive parts become the whole. The lack of cohesive separation of responsibilities, functionality, data, etc. limits cohesiveness to the entire system, which almost dooms the project to being monolithic.

98

Exceptions

If all the causes of a monolithic system are explicitly defined as requirements or features of a system, it may be the exception to monolithic architecture as an anti-pattern.

It's counterintuitive to think that a system should have anemic or shallow requirements. So, the exception to monolithic as an anti-pattern really is that the system is simple, needs to be implemented on one platform, and be deployed as a single entity. Examples of this could be a simple console or WPF application.

Solution

The pain and friction points of a monolithic application almost always revolve around the degree and type of coupling. That coupling is often that the entire application is coupled to a single binary, but could also be that tiers have a one-to-one coupling. The solution to the monolithic architecture is to introduce decoupling at the binary and process levels. An n-tier application is decoupled at the process level, so that decoupling often means going deeper so that any one-to-one coupling is at a logical level. In effect, the one-to-one coupling becomes a one-to-at-least-one coupling. That decoupling can simply take on the form of an RESTful HTTP request so that the request can be load-balanced to two or more tiers. Or the decoupling could take on a delegation pattern so that a third dependency acts as a broker facilitating communication between the individual components.

As mentioned earlier, one specific solution is decoupling at the process layer and moving

communication between code/units/modules to HTTP. One architectural pattern for this is the microservice pattern. The microservice pattern basically suggests decomposing a system into a set of collaborating services communicating via an over-the-wire protocol like HTTP or AMQP. Each component in a microservices architecture implements narrowly related functionality. Although this can technically be viewed as a broker because the decoupling between requestor and responder can have components like load-balancers inserted, we don't view it as a broker. Let's look at brokers more closely.

You can take the interprocess architecture and over-the-wire decoupling to another level by viewing what is communicated over the wire as messages and have a third component to broker that communication of those messages between components. The communication between RESTful HTTP microservices can be viewed as sending and receiving messages, but it's a single type of messaging: request/response. Using messages in a message-oriented architecture takes that communication to another level to support different messaging types, such as point-to-point, request/response, pub/sub, and so on.