Monolithic Architecture

What is Monolithic?

A monolithic application is tightly coupled and entangled as the application evolves, making it difficult to isolate services for purposes such as independent scaling or code maintainability. In simple words, If all the functionalities of a project exist in a single codebase, then that application is known as a monolithic application.

Why Monolithic?

1. Simple to develop relative to microservices where skilled developers are required in order to identify and develop the services.
2. Simple to deploy We need to care about only one file or directory, not many deployments.
3. Easier debugging and testing Since a monolithic app is a single indivisible unit, you can run end-to-end testing much faster, Easier to run the test.
4. Less cross-cutting concerns Cross-cutting concerns are the concerns that affect the whole application such as logging, handling, caching, and performance monitoring. In a monolithic application, these areas of functionality concern only one application so it is easier to handle it.

Issues with monolithic architecture:

1. At some point in time, it becomes too large in size, and hence difficult to manage.
2. It is difficult to adopt any new technology which is well suited for a particular functionality as it affects the whole application, both in terms of time and cost.
3. As the size of the application increases, its start-up and deployment time also increases. We need to redeploy the whole application even for a small change.
4. Scalability. You cannot scale components independently, only the whole application.

Components of monolithic architechture

The above image is specific to a java application but concepts that we are going to discuss here is generic to all the application architect using monolithic architecture.

As we can see at the bottom layer of the above image, we have a presentation layer that basically deals with UI and all(static HTML pages, js, CSS). Then comes the Request routing /validation which intercepts all the incoming requests and ensures no malicious data is coming through probably converting the HTTP request to hashmap transformation and many more. Then comes the controller/Communications/orchestration, which basically orchestrates the incoming request to business components. i.e if it is this request then these are the business component it needs to invoke. Controller get request and it fires up the business object (which is kind of brain of business application) can have different design patterns like factory pattern. So here we can see the partition/seam is at the business objects level where we have to distinguish mods each having their own functionality. The business object (In the above pic) is the place where the business logic resides. We can have a service locator as seen in the above pic. Then we have common factors likes session mgmt, DB connection and etc which can be used in all the business model and can be placed in a sperate package. The final layer is an adapter which is to interact with surrounding, with other application within or outside the organization i.e interaction with different DB, third party service(downstream system: another application which my application talks to), email, pub-sub.

All of these components reside together. when we create a single deployable comprised of all these things will get deployed in all the servers as shown in the above image. The reason why these machines are bigger in size is that there are multiple components working together. Monolith is basically a single deployable, deployed on few machines.

Monolithic web application — The business process is wired in the application as API calls across multiple packages in a single JVM.

Monolith Characteristics:

1. Typically enterprise application where the investments have been done over a decade.
2. Any application that stated nimble and has grown over the decade.
3. The logic for handling a request runs in a single process/thread, allowing you to use a basic feature of your language to divide up the application into classes, functions, and namespace- a cohesive bundle.
4. Testing requires a holistic approach to cover the areas that were not affected by the change
5. Any changes in the system involve building and deploying a new version.
6. use a deployment pipeline to ensure that changes are properly tested and deployed into production.
7. since all the components are managed as a single unit they tend to be easy from an ops perspective eg build 3 build pipeline -dev, stage, and prod.
8. Scaling issues — All the components get the added capacity and not just the selected layers that actually deserve the additional capacity.
9. Because of the above, there can be a resource cannibalistic effect where one component can hog more from the infra suffocating other components.
10. Any form of agile development can be difficult to achieve.
11. Application takes longer time to initialize and may cause adverse effects during horizontal scaling.
12. one flaw can bring the whole application server/cluster down because each instance is identical.
13. Must follow a cohesive, homogenous development/programming environment.