Monoliths vs Microservices
Table of contents
In the last few years, there’s been an accelerating trend of Microservices Architecture for Software Applications. Application architecture can have profound implications on not only enterprise IT but the digital transformation of entire businesses. Many companies prefer this over Monolithic Architecture because of its scalability, maintainability, and other significant advantages which we’d be reading later in this article.
Any software application has 3 components:
1. Database: This basically stores the data. It can be either RDS (Postgres, MySQL) or NoSQL (Mongo, Cassandra, etc.)
2. Server-side / Backend: This usually consists of some APIs used to perform CRUD operations on the database. It can also be used to perform some complex logic and return the result. It focuses mainly on handling, processing the data.
3. Client Interface/ Frontend: This is basically the client interface and the focus is mainly on design, UI/UX, and providing the user with a GUI to perform some operations.
Now, let’s understand Monoliths and Microservices in layman terms.
Imagine you need to build a residential society which should have apartments, parking, pool, halls, parks, clubs, auditoriums — think of these as features.
We can start with an approach to include all these amenities in a single building structure, wherein the first 2 floors would consist of parking, the next 10 would have apartments, and you can go on by building the other required features within this building.
But building different features isn’t enough, for example, if you build an auditorium, the electricity requirements, the parking requirements for that feature would be very different from that of a residential apartment.
If you build a swimming pool, the water requirements for it would be very different from the rest of the building.
Think of space, water, electricity, and parking as the infrastructure, when building a software application this physical infrastructure is present as different kinds of servers or cloud services you might choose to use to build the features.
Supporting and scaling different kinds of features in a single building can lead to wastage of electricity, water, or other resources that have severely different usage patterns than each other. An example would be an auditorium being used only once a month vs an apartment in the building that is used daily.
Alternatively, to design a structure with all the amenities we referred to earlier, you can choose a different architecture wherein all of these amenities would be given a dedicated area to be built upon. Though this would require them to be distributed, maintenance would be more as each feature is stand-alone, and so would be the cost, but this is quite scalable, maintainable, and can be quite clean if implemented well. This is analogous to Microservices Architecture.
But choosing this in the initial phase of development might not pay off as the requirements might not be clear and the high abstraction that this architecture provides may not be necessary.
Monolithic Architecture
The Monolithic Architecture includes developing an application as a single unit wherein all the functionalities of an application reside in a single codebase. This has been a traditional practice for developing applications until a few years back.
Pros of using this architecture are:
1. Ease of development: You don’t need to maintain multiple repositories and servers. And updates can be done at once unlike in microservices.
2. Simplified deployment and monitoring: We don’t need to handle many deployments, it would be just one application.
3. Performance: When properly design these are often more efficient as it doesn’t require multiple API calls for a single task which results in less latency.
4. Fewer Complications around cross-cutting concerns as all logics and flows are present in a single codebase.
Particularly for smaller projects or organizations, creating a highly distributed environment might involve more development and maintenance than a small team can manage effectively.
The cons of this architecture are:
1. Scalability: You can’t scale any specific part of your application, only the whole application.
2. Modifying Existing Functionalities: As the application code base grows over time it is challenging to include changes in existing functionalities as it would be used across the application.
3. Technology: The entire application would need to be built on one technology and it is extremely problematic to apply a new technology as the entire application would need to be rewritten.
So we read about why Monoliths were great, but there were some drawbacks and challenges associated with this architecture which are better served by Microservices Architecture.
Microservices Architecture
Unlike Monoliths, microservices architecture consists of smaller independent services which are segregated based on the business logic and requirements. Every service has its own logic and database and they usually interact with each other via HTTP resource API.
So with this architecture, the functionalities are split up into independent services which can be deployed, updated, and scaled independently.
Principles for Microservices Design:
1. Single Responsibility Principle: This asserts that each microservice should have only one responsibility.
2. Built around business capabilities: A microservice shall never restrict itself from choosing a certain technology best suited for a particular business solution.
3. Fault Tolerance: If a particular microservice is down/ malfunctions it should affect only that service and other services continue to handle requests.
4. Loose Coupling: The microservices should be loosely coupled.
5. Ownership: You build it, you own it!
6. Infrastructure Automation: As the number of instances to be deployed is usually large we need an automation solution to do this job using some DevOps tools.
The pros of this architecture are:
1. Scalability: Since each service can be scaled independently, this provides better scalability as one service might require high computation and another one might require high memory. In the case of a Monolith, the whole application would need to be scaled which has its own challenges.
2. Flexibility in choosing technologies: Each microservice can be built on different technology and use different databases which suit its requirements.
One service can be built on Python and another one on C++ with different databases (RDS or Nosql) depending on the requirement.
3. Improved Productivity: Since the application consists of independent services it makes it easier for the team to work on new logic and divide the work and avoid dependency.
4. Better Resiliency: It is easier to troubleshoot the issues, find performance bottlenecks and do a root cause analysis due to isolated components, and mitigate those. Downtime is reduced since updates can be rolled back without affecting the entire application.
The cons of this architecture are:
1. Increased Complexity: Since it is a distributed architecture, we have to set up connections between the modules and databases and usually all of them have to be deployed independently.
2. Cross-cutting concerns: We have to deal with many *concerns* like security, health checks, logging, different metrics, etc.
3. Testing: Testing becomes quite difficult as we’d need to test each component.
Both Monolithic and Microservices Architecture have their set of challenges and benefits, so it’s up to us to decide which best suits our requirements considering cost, human efforts, and complexity.
Ultimately, there is no silver bullet answer to the challenges of scaling. Each application, team, and business is unique and should be considered as an individual case.
Some critical factors to consider Software Architecture suits your application:
Choosing a Monolithic Architecture
- Small team/ building an MVP
- Quick Development: If you need to develop a product as quickly as possible, it’s better to go for Monolithic Architecture.
- Business needs or requirements are subject to frequent changes.
- No microservices and DevOps expertise.
Choosing a Microservices Architecture
- Microservices expertise along with DevOps and Containers knowledge: Choosing this architecture without expertise on it would probably not pay off.
- You need to build a complex and scalable application and expect a lot of traffic on certain functionalities/services.
- Enough engineering resources
- Clarity on business requirements, usage patterns, and use-cases.
In the last few years, there’s been an accelerating trend of Microservices Architecture for Software Applications. Application architecture can have profound implications on not only enterprise IT but the digital transformation of entire businesses. Many companies prefer this over Monolithic Architecture because of its scalability, maintainability, and other significant advantages which we’d be reading later in this article.
Any software application has 3 components:
1. Database: This basically stores the data. It can be either RDS (Postgres, MySQL) or NoSQL (Mongo, Cassandra, etc.)
2. Server-side / Backend: This usually consists of some APIs used to perform CRUD operations on the database. It can also be used to perform some complex logic and return the result. It focuses mainly on handling, processing the data.
3. Client Interface/ Frontend: This is basically the client interface and the focus is mainly on design, UI/UX, and providing the user with a GUI to perform some operations.
Now, let’s understand Monoliths and Microservices in layman terms.
Imagine you need to build a residential society which should have apartments, parking, pool, halls, parks, clubs, auditoriums — think of these as features.
We can start with an approach to include all these amenities in a single building structure, wherein the first 2 floors would consist of parking, the next 10 would have apartments, and you can go on by building the other required features within this building.
But building different features isn’t enough, for example, if you build an auditorium, the electricity requirements, the parking requirements for that feature would be very different from that of a residential apartment.
If you build a swimming pool, the water requirements for it would be very different from the rest of the building.
Think of space, water, electricity, and parking as the infrastructure, when building a software application this physical infrastructure is present as different kinds of servers or cloud services you might choose to use to build the features.
Supporting and scaling different kinds of features in a single building can lead to wastage of electricity, water, or other resources that have severely different usage patterns than each other. An example would be an auditorium being used only once a month vs an apartment in the building that is used daily.
Alternatively, to design a structure with all the amenities we referred to earlier, you can choose a different architecture wherein all of these amenities would be given a dedicated area to be built upon. Though this would require them to be distributed, maintenance would be more as each feature is stand-alone, and so would be the cost, but this is quite scalable, maintainable, and can be quite clean if implemented well. This is analogous to Microservices Architecture.
But choosing this in the initial phase of development might not pay off as the requirements might not be clear and the high abstraction that this architecture provides may not be necessary.
Monolithic Architecture
The Monolithic Architecture includes developing an application as a single unit wherein all the functionalities of an application reside in a single codebase. This has been a traditional practice for developing applications until a few years back.
Pros of using this architecture are:
1. Ease of development: You don’t need to maintain multiple repositories and servers. And updates can be done at once unlike in microservices.
2. Simplified deployment and monitoring: We don’t need to handle many deployments, it would be just one application.
3. Performance: When properly design these are often more efficient as it doesn’t require multiple API calls for a single task which results in less latency.
4. Fewer Complications around cross-cutting concerns as all logics and flows are present in a single codebase.
Particularly for smaller projects or organizations, creating a highly distributed environment might involve more development and maintenance than a small team can manage effectively.
The cons of this architecture are:
1. Scalability: You can’t scale any specific part of your application, only the whole application.
2. Modifying Existing Functionalities: As the application code base grows over time it is challenging to include changes in existing functionalities as it would be used across the application.
3. Technology: The entire application would need to be built on one technology and it is extremely problematic to apply a new technology as the entire application would need to be rewritten.
So we read about why Monoliths were great, but there were some drawbacks and challenges associated with this architecture which are better served by Microservices Architecture.
Microservices Architecture
Unlike Monoliths, microservices architecture consists of smaller independent services which are segregated based on the business logic and requirements. Every service has its own logic and database and they usually interact with each other via HTTP resource API.
So with this architecture, the functionalities are split up into independent services which can be deployed, updated, and scaled independently.
Principles for Microservices Design:
1. Single Responsibility Principle: This asserts that each microservice should have only one responsibility.
2. Built around business capabilities: A microservice shall never restrict itself from choosing a certain technology best suited for a particular business solution.
3. Fault Tolerance: If a particular microservice is down/ malfunctions it should affect only that service and other services continue to handle requests.
4. Loose Coupling: The microservices should be loosely coupled.
5. Ownership: You build it, you own it!
6. Infrastructure Automation: As the number of instances to be deployed is usually large we need an automation solution to do this job using some DevOps tools.
The pros of this architecture are:
1. Scalability: Since each service can be scaled independently, this provides better scalability as one service might require high computation and another one might require high memory. In the case of a Monolith, the whole application would need to be scaled which has its own challenges.
2. Flexibility in choosing technologies: Each microservice can be built on different technology and use different databases which suit its requirements.
One service can be built on Python and another one on C++ with different databases (RDS or Nosql) depending on the requirement.
3. Improved Productivity: Since the application consists of independent services it makes it easier for the team to work on new logic and divide the work and avoid dependency.
4. Better Resiliency: It is easier to troubleshoot the issues, find performance bottlenecks and do a root cause analysis due to isolated components, and mitigate those. Downtime is reduced since updates can be rolled back without affecting the entire application.
The cons of this architecture are:
1. Increased Complexity: Since it is a distributed architecture, we have to set up connections between the modules and databases and usually all of them have to be deployed independently.
2. Cross-cutting concerns: We have to deal with many *concerns* like security, health checks, logging, different metrics, etc.
3. Testing: Testing becomes quite difficult as we’d need to test each component.
Both Monolithic and Microservices Architecture have their set of challenges and benefits, so it’s up to us to decide which best suits our requirements considering cost, human efforts, and complexity.
Ultimately, there is no silver bullet answer to the challenges of scaling. Each application, team, and business is unique and should be considered as an individual case.
Some critical factors to consider Software Architecture suits your application:
Choosing a Monolithic Architecture
- Small team/ building an MVP
- Quick Development: If you need to develop a product as quickly as possible, it’s better to go for Monolithic Architecture.
- Business needs or requirements are subject to frequent changes.
- No microservices and DevOps expertise.
Choosing a Microservices Architecture
- Microservices expertise along with DevOps and Containers knowledge: Choosing this architecture without expertise on it would probably not pay off.
- You need to build a complex and scalable application and expect a lot of traffic on certain functionalities/services.
- Enough engineering resources
- Clarity on business requirements, usage patterns, and use-cases.
Give your product vision the talent it deserves
building your dream engineering team.
.webp)
