“Good design goes to heaven, bad design goes everywhere”

When it comes to software engineering, an application is considered as a monolithic application if both the user interface and data access codes are combined into a single program through a single platform.

With that, others might think that creating a monolithic is much easier that creating other kinds of applications. But what they don't know is that monolithic applications are deceptive creatures — they are easy to create but are also difficult to kill.

Why is it so? Well, to understand why these are frowned upon, we must first have to understand what they are, what are the advantages and disadvantages that they possess, and what kind of chaos they can unleash if they are not properly managed.

The design philosophy of it is that the application is responsible not just for a task, it can also perform the steps that are needed to complete a function. They act as silos rather than parts of a larger system of applications working together.

In some cases, building monolithic applications are accepted, but a lot of drawbacks occur from the moment of its inception.

Tightly coupled design:

Everything is connected to everything; this is the root of the power of a monolith.

Lack of reusability: With tight coupling comes lack of reusability. Since everything depends on everything, reusing one part of the software becomes non-trivial.

Difficult deployments:

If you need to update one part of the application, you must do a complete redeployment of your whole application.

Not proven to streaming work: In any big project, you have multiple people working on multiple parts of the application. With everything being strictly coupled, it becomes exponentially possible for one feature to indirectly affect the other features.

Inflexible to maintain and replace parts of the application: Maintainability as you may have guessed also increases the complexity that is calculated upon the trial or test, and enhancing even a part of the application already means a full regression test on the whole application.

“Monolith impede change”

Hopefully by now, you've realized how dangerous monolithic applications are, and how frail its design is. But, how can we stay away from them?

Modularity

By simply taking a modular based architecture and by having loosely coupled components, we could avoid the pitfalls and achieve the benefits that it offers such as:

Easier to maintain:

Since we have loosely coupled components, it is possible that updating one part of the codebase without interfering another unrelated part is more feasible.

Smaller and more frequent deployments: If we think of building with smaller blocks, deployments become less painful. It is now possible to update one part of the codebase by avoiding a full regression test of the whole application.

Facilitates reusability: Building in smaller blocks also means building a unit with a single responsibility. These units can now be shared or swapped, and has increased development productivity and subsequently reduces cost.

Provide guardrails for developers: A developer can now safely code in a sandbox environment and know that it cannot interfere with another feature, making development safer for both the developer and the business.

Ability to scale horizontally: Since we achieve isolation through modularity, it is possible to scale horizontally. It is possible to increase disk capacity, and have an efficient I/O performance.

Resources: