Monolithic Architecture Pattern

What is monolithic architecture pattern?

Monolithic architecture - monolithic application is a single unified software application which is self-contained and independent from other applications, but typically lacks flexibility.

Monolithic architecture - Design an architecture that structures the application as a single deployable/executable component that uses a single database.

Monolithic architecture has only one contract between application and database. There is no any contracts between components.

Monolithic architecture means:

• All components are implemented in one framework and plased in single application.
• Application can have structured and loosely coupled design or don't have this.
• It is not required to be implemented in one repository, application can have external libraries.
• In most cases, a monolithic application uses one large database for all data.

Monolith - this is an application that we cannot divide into parts without refactoring and manage the individual parts independently.

Patterns for monolithic architecture

There are no specific patterns for monolithic applications. But, SOLID, patterns, any other aggrements and contracts between developers can improve quality and provide well-designed, structured, loosely coupled application for future implevements without pain.

Evolution of monolithic architecture in application

It is interesting which result we can have with monolithic architecture. Let's see what can happen:

1. Monolithic architecture it is easiest way to start MVP. Now we have MVP and it is monolith.

   It can be a last stage in project life cycle. If you have created simple application to solve some dedicated problem - that enough, problem have been solved, just use it and from time to time update it to new framework and/or library version to keep security in high level.

2. New features, new users - project growths.

   If the project is really required in new features. If the project is growing and requires more and more compute resources.

   Then, we have some options here:

   • If you can scale your monolith horizontaly - just do it and continue development.

   • If you can't scale your project - you have no choise, it is time to use microservices.

3. You are working with big, highload, fast growing project.

   In this situation, you should already have microservices or you should actively migrate to microservices at this time.

   In real project we can have a different situation, but in general, for projects in this stage microservices can solve alot of problems with scalebility, development process, resource utilization.

Is it possible to grow with monolith and add new features and save or increase the speed of development?

Again, we have two option:

• Project was developed and is currently being developed using patterns, approaches like SOLID and other good development practices.

  In this case we can continue to work with monolith. If our solution still well structured, supportable and you can work on different feature in project independently - why not? And yes, it is not true if you have some predictions that growth will continue.

  In this early stage we can start process to redisign application, for example with microservice approach. This may reduce efforts and negative affect from this redesign in the future. Probably, you should not doing this if you are not sure that the load will be large.

• Project was created without internal structure, patterns, it was implemented as "big ball of mud"

  Pain and suffering. Redesign and reimplement this solution or continue to suffer with growing badly done monolith.

Note: Sometimes, we should use SOA (service oriented architecture) instead of microservices, because its simpler and allows us to take out the critical high load part and scale it independantly.

Note: Of course :), if you know in advance what kind of load the application will handle, how many users, data, etc... will be in application - you should not start you project in monolith style, if it is a big and high load system.

Example of monolithic application

Try monolithic architecture pattern for simple knowledge-graph-builder application which add new data into knowledge graph. Let's imagine what our application has good design, it is not "big ball of mud" and we have separated component inside the application.

There is the following components are in our example application:

• book-uploader - upload books in different formats. PDF, Epub, DjVu, ...
• book-transformation - transform incoming book to internal knowledge graph view
• Crowler to pull data from web
  • spider - pull data from URL and store in database
  • data-miner
    • text-miner - pull text fragments from html and store in knowledge store
    • link-miner - pull links from html and store links in database

[  ](monolith-architecture-example application components.png)

This monolithic application will be deployed as shown in diagram below:

[  ](monolith-architecture-deployment d.png)

Different component in this diagram have different hardware requirement. For example:

• book-transformation requires a lot of RAM
• text-miner requires fast HDD
• spider requires fast internet connection

Scale the application

for example, our spider component can't cope with the load, it lacks network bandwidth:

1. In first case it is impossible, because there is no ability to connect more than one instance of component to storage (knowledge-store).
2. If everything is fine, and we can have two or more application instances we will create one more application instance:

[  ](monolith-architecture-deployment d 2.png)

new server "server 3" should have save hardware settings (CPU,MEM,Network) as for "server 1", but obviously this is not necessary because we should scale only "spider" component with special requirements for internet connection.

Increasing the coupling of application components

Even good designed application over time can transform onto highly coupled application.

Here on the diagram below we can see a lot of new dependencies between components. Also, new library that links all others components.

But, this is an abnormal situation when development was carried out without proper code quality control.

Advantages, disadvantages and limitations of monolithic architecture

Advantages

• Avoid all integration problems which actual for microservices.

• Performance. Due to the lack of network communications.

• Easy debugging

  It is obviously what debugging in monolith is more simplest thing in distributed system with number of different services.

Disadvantages

• Scaleability

  Theory says that there is only one way to scale application - vertical scaling. But, in real life we can have stateless monolithic application and with load balancer we can scale this application horizontally.

• Restrictions on using only one technology stack.

  In monolithic application we can use only chosen framework, libraries and components only for chosen language. We can't quickly adopt new valuable component in different language. We can't use new framework for new component to speed up development process.

• The monolithic application is easier to turn into "big ball of mud".

• Reliability

  An error in any application module can affect the availability of the entire application. This situation is not unique problem for this architecture pattern, for SOA or microservices a similar error may occur. This is more likely to happen in monolith than a well-designed micro-service architecture. Of course, in microservices we have more approaches and tools to increase reliability and we can build reliable system, but it is additional complexity, additional time to desing and to develop the system, significant increase complexity for support.

Controversial statements

• Deployment

  In some articles you can find what deployment it is problem point in monoloth and great feature in microservices, but in other articles you can find the opposite opinion. In fact, it depend on you devops provess. If you or your team can create CI/CD pipeline - it means you won't have a problems with deploymnent and it doesn't matter monolithic or microservices.

• Development process

  Same as for deployment, but here we are speaking about development process organization and code quality.

  "A large, monolithic application makes development more complex and slower." - it is not really true if your monolithic application well structured with modules, low coupled, with documentation, etc...

Distributed Monolith

What if we think we have microservices, but our services can't be used independently, we can not update the service independently of other services.

[  ](monolith-architecture-Distributed Monolith.png)

In this example we have service "spider-service" which can't work independently without "text-miner" and "link-liner".

Here we have different services, but they cannot work independently. This approach is called Distributed Monolith

A distributed monolith is an application that’s deployed like a microservice but is built like a monolith. It leverages platforms like Kubernetes and a distributed systems architecture but isn’t designed to do so efficiently or reliably.

Distributed Monolith is a system that resembles the microservices architecture but is tightly coupled within itself like a monolithic application.

Signs of such an architecture

• A small change to application logic requires concurrent changes to many other components.
• Multiple microservices and components access the same database.
• The number of parameters passed to multiple microservices continually grows over time.
• Multiple microservices and components share common, boilerplate code.
• Microservices retain compounding amounts of logic with each successive change to a system.

You have a distributed monolith if you are using:

• Shared Database - distributed services share the same database, it’s not a distributed system.

• Shared Codebase/Library - Microservices can fall into the trap of shared codebases or libraries. The problem with shared libraries is that frequent library updates can affect the dependent services and re-deploy the services.

• Synchronous Communication - if your application has too much synchronous communication between services, it can be a distributed monolith.

• Shared Deployment - If your services use a shared deployment or common CI/CD pipelines.

Why is a monolith is simpler then microservices?

Monolith can be less usable for big scalable applications, but this pattern is simpler than service oriented architecture or microservices.

Why is it?

Let's take a look at list of patterns for microservices in this well known place: microservices.io/patterns.

Here, you can find a lot of patterns which was designed to solve the problems in microservices. It means we have a lot of problems in microservices which we have to solve to use microservices and get all benefits from this architecture pattern.

For example: Access Token, Distributed tracing, Circuit Breaker, Deployment patterns, etc... there are no problems of this kind in monolith, because there is nothing that causes these problems.

Conclution

In general, monolith it is good architecture for a large number of applications. if you're not Google or Netflix - it is a good choice for your application which is not intended for millions of users.