Monolithic vs Microservice Architecture

Monolithic architecture

In monolithic architecture applications, all application tiers are tightly coupled and share the same resources. Application tiers are different layers or components of applications grouped on the basis of the functionality they perform. Each tier performs a particular functionality and works together to complete the overall functionality of the application. For example in a monolithic backend application, all the functionality, business logic, databases, and controllers share the same resources and are hosted on the same server. 

Thus, in monolithic architecture, all the application tiers share the same resources and are deployed on a single server. Thus they are

  1. Managed in the same repository
  2. Sharing resources (CPU, memory, etc)
  3. Developed in one programming language
  4. Released in a single executable file

Advantages of monolithic architecture

  1. Simple to understand, develop, and deploy.
  2. Easy deployable as only one file needs to be deployed.
  3. Performance is good as there are fewer network calls
  4. Simple to debug and test as there is only one code base
  5. Mostly have a single database so a simple data layer
  6. Much more secure in the sense that there are fewer opportunities to attack an application as compared to when one has distributed architecture.

Limitations of monolithic architecture

  1. Scalability, if we need to enhance a particular tier then we need enhancements for a complete application. Further, it has less initial cost as only one code base and one pipeline to deploy, but cost increases exponentially as the app scales.
  2. As all are tightly coupled, it has less flexibility and needs major changes through the app for any change
  3. Less component reusability due to tightly coupled modules/components
  4. Reliability, if one module got down, the complete app goes down

Microservice architecture

In a microservice architecture, all application tiers are loosely coupled and each tier is working as a separate service, called microservice. It is deployed separately with its own resources like memory, CPU, repository, DB, etc. Each microservice is independent of other microservices and thus may be developed using any programming language. These microservices are not dependent on each other and perform their specific functionality on their own but communicate with each other to complete application functionality as a whole. Each microservice may also have a different set of resources, for example, one microservice has its own db while other don’t or it is also possible that all microservices have their own db, or its also possible that all microservices is communicating with another microservice that is responsible for the database related stuff. It all depends on the requirement. So the architecture and resource requirement of microservices is not very straightforward and depends on the requirements. So in the following figure, it is cleared that each microservice may communicate with another microservice depending upon the requirements and implementation of microservices.

Communication between microservices

We may communicate between microservices in many ways. We may use 

  1. HTTP / Rest API
  2. GraphQL
  3. Messages queues
  4. RPC (Remote Procedural Calls)
  5. Event sourcing

We may discuss them all with practical examples at some other time. So let’s see what are the advantages and disadvantages of using microservice architecture.

Advantages of microservice architecture

  1. Scalability, as each microservice is completely independent, we may scale any microservice as per requirement and thus avoid scaling the complete app. So as the app grows it’s much more feasible to scale apps with microservice architecture as compared to monolithic architecture apps.
  2. It’s much more flexible and modular, thus allowing developers to work on separate services and deploy them separately. 
  3. Each microservice can be built on different platforms/ languages thus providing technology diversity.
  4. Easy deployments as only particular services need to be deployed 
  5. Fault tolerance and isolations, as a fault in a particular service, may affect only that service, not the complete app

Limitations of microservice architecture

  1. Complexity in terms of managing different microservices, their deployments, and troubleshooting.
  2. Communication overhead is high due to communication between each service.
  3. Increased communication complexities and challenges due to network failures, messages, and event consistency.
  4. Data consistency if multiple services using the same data layer
  5. Security concerns as now the number of opportunities to attack an application increases with the increase in accessible points of microservices. 
  6. Not much secure in the sense that there are greater opportunities to attack an application as compared to applications with a monolithic architecture.

Different implementation strategies at frontend and backend applications

The concepts of monolithic and microservice architectures can be applied to both the frontend and backend applications or even to the application as a whole.

Considering monolithic architecture, for frontend applications, all the UI modules, frontend features, forms, and integrations are grouped and deployed as a single entity. Similarly, for backend applications, all the business logic, functionality, and databases are tightly coupled and used as a single application. For a complete web application, both frontend and backend along with their modules and components are deployed on the same server thus sharing the same resources.  

Considering microservice architecture, for frontend applications (micro-frontends), there are different smaller services for each different functionality. Each functionality is being served by an independent micro-frontend. For example, search is implemented in a separate micro-frontend, and listing is managed by another micro-frontend. Both micro-frontends are working as a separate independent service as shown in the below figure.

The same goes for backend applications as well, where multiple microservices are responsible for separate functionality and working independently. There are also architectures where both frontend and backend applications have microservices. 

It may also be possible that different architectures are being used in an application. For example monolithic architecture at the frontend and microservice architecture at the backend and vice versa. 

Monolithic architecture or microservice architecture

Both types of architecture have their own pros and cons, as mentioned before. Depending on the application requirements, one should finalize the architecture. It is also not fixed that one can use a monolithic approach or microservice approach in a complete app. One can use a hybrid approach as well, where some part of the application is monolithic and some part is using microservice architecture. An example of a hybrid approach will be (frontend with a monolithic architecture and backend with a microservice architecture or vice versa).

 

App RequirementsMicroservice ArchitectureMonolithic Architecture
Scalable & Flexible
Simple and needs to launch quickly
Lower software latencies
Time to time features/enhancements and continuous deployments
Technology diversity
Reliable and fault tolerant
Small to medium size
Ease in debugging
Low costs
Distributed development teams

Author
Rehman Akram

Latest Blogs From Our Engineers