Monolithic Architecture? Good or bad?

If you are in the developer world you must have heard something about the monolithic project, or even monolithic architecture, if you never heard of it, maybe it's time to join us and know why we should know this architecture type and what implications it has on our project.

Also, this post was heavily inspired by these contents:
video
article

Let's start with the problem...

Problem Statement

• Develop a server-side enterprise application.
• It must support a variety of different clients including desktop browsers, mobile browsers, and native mobile applications.
• It might also integrate with other applications via either web services or a message broker like payment gateways and notification services
• The application handles requests (HTTP requests and messages) by executing business logic, accessing a database, exchanging messages with other systems, and returning a JSON response.
• The application handles requests (HTTP requests and messages) by executing business logic, accessing a database, exchanging messages with other systems, and returning a JSON response.

Problem

What’s the application’s deployment architecture?

Forces

• There is a team of developers working on the application
• New team members must quickly become productive
• The application must be easy to understand and modify
• You want to practice continuous deployment of the application
• You must run multiple instances of the application on multiple machines in order to satisfy scalability and availability requirements
• You want to take advantage of emerging technologies (frameworks, programming languages, etc)

Solution

Build an application with a monolithic architecture. For example:

• a single Java WAR file.
• a single directory hierarchy of Rails or NodeJS code

Traditional Server-Side App

In a traditional server-side app, we have a basic Server-Side app, as it shows below:

Here we have the following, a Client-Side, where the user makes the inputs and requests. These requests are then sent to the said Server Side, where they are treated accordingly.

After the presentation layer (front-end), we make a request to the back-end side, where the logic is present (business), and where we can send the request made by the back-end to the data layer, where then they catch the requested data from the database.

This is a monolith, this is because the logic is all contained in a single file, in a way that it only accesses the single database.

Taxi booking Server-Side App

Some places might reference this as the "Uber architecture", which is not, but is very similar. This will be your first version of your application, where we have the internal modules and the external modules.

The internal are those like billing and notifications or payments when those services need to connect to the outside world we reach the outside modules. We reach than by the adapters, or converters, which convert the data from the outside world and send it to the user.

This is considered a monolith because all of your business logic resides within a single application and you only have a single database.

Result Context

This solution has a number of benefits:

• Simple to develop - the goal of current development tools and IDEs is to support the development of monolithic applications
• Simple to deploy - you simply need to deploy the WAR file (or directory hierarchy) on the appropriate runtime
• Simple to scale - you can scale the application by running multiple copies of the application behind a load balancer

Also, it has some disadvantages:

• As the monolithic grows, the complexity also grows, and as result, it becomes impossible to sustain. It intimidates developers who are new and can be difficult to modify, as result the development slows down. Also, because there are not hard module boundaries, modularity breaks down over time.
• Overloaded IDE and Start - the larger the codebase the slower the IDE and the less productive developers are. Think about 5 minutes or even 20 minutes to load a file and a few minutes to search for a file.
• Continuous deployment is difficult - a large monolithic application is also an obstacle to frequent deployments. In order to update one component, you have to redeploy the entire application. This will interrupt background tasks (e.g. Quartz jobs in a Java application), regardless of whether they are impacted by the change, and possibly cause problems. There is also the chance that components that haven’t been updated will fail to start correctly. As a result, the risk associated with redeployment increases, which discourages frequent updates. This is especially a problem for user interface developers since they usually need to iterative rapidly and redeploy frequently.
• Scaling the application can be difficult - a monolithic architecture is that it can only scale in one dimension. On the one hand, it can scale with an increased transaction volume by running more copies of the application. Some clouds can even adjust the number of instances dynamically based on load. But on the other hand, this architecture can’t scale with an increasing data volume. Each copy of the application instance will access all of the data, which makes caching less effective and increases memory consumption and I/O traffic. Also, different application components have different resource requirements - one might be CPU intensive while another might memory intensive. With a monolithic architecture we cannot scale each component independently
• The obstacle to scaling development - A monolithic application is also an obstacle to scaling development. Once the application gets to a certain size it's useful to divide up the engineering organization into teams that focus on specific functional areas. For example, we might want to have the UI team, accounting team, inventory team, etc. The trouble with a monolithic application is that it prevents the teams from working independently. The teams must coordinate their development efforts and redeployments. It is much more difficult for a team to make a change and update production.
• Requires a long-term commitment to a technology stack - a monolithic architecture forces you to be married to the technology stack (and in some cases, to a particular version of that technology) you chose at the start of development. With a monolithic application, can be difficult to incrementally adopt newer technology. For example, let’s imagine that you chose the JVM. You have some language choices since as well as Java you can use other JVM languages that inter-operate nicely with Java such as Groovy and Scala. But components written in non-JVM languages do not have a place within your monolithic architecture. Also, if your application uses a platform framework that subsequently becomes obsolete then it can be challenging to incrementally migrate the application to a newer and better framework. It’s possible that in order to adopt a newer platform framework you have to rewrite the entire application, which is a risky undertaking.

Finally

A monolith is something you want to avoid. It's like a black void, where every code goes to never be found. It's a project where a very few developers understand, it's written using obsolete and unproductive technology that makes hiring talented developers a difficult task because no one wants to work on a monolith. Also, the application is difficult to scale up and your costumers are always reporting bugs that if someone doesn't fix it upright and fast it breaks all the applications.