A monolithic application is built as one large system . The frontend, backend and database are all defined together.
Typically, it is all maintained in the same codebase and often deployed all at once.
Why would someone want to use monolithic architecture?
- Simple to Deploy and Scale
You have only one large system to deploy. It can be scaled horizontally by running multiple instances behind a load balancer.
- Simple to Test
All the internal systems are tightly coupled and hence testing is easier.
- Less Operational Overhead
You have only one application to setup for deployment, logging, monitoring etc.
- Fewer Cross Cutting Concerns
Cross cutting concerns are technical features that are commonly applicable to all parts of a system. Ex: Configuration, Logging, Exception Handling, Auditing, Authentication, Authorization etc. Monolithic applications have fewer cross cutting concerns because they can be shared centrally using libraries or frameworks.
Why would someone NOT want to use monolithic architecture?
- Hard to Understand
Application is too large and complex to fully understand and make changes correctly.
- Tight Coupling
Bug in any module can potentially bring down the entire application. Any code change affects the entire system and has to be thoroughly coordinated. For every update, the entire application has to be redeployed.
- Hard to Adopt New Technology
It is expensive to adopt a new technology since any change in language or framework affects the entire system.
- Hard to Scale
Due to the tight coupling, it is hard to isolate services and scale them independently. Different modules might have conflicting resource requirements for scaling.
A microservices application is built as a suite of small services, each running its own process and communicating with lightweight mechanisms.
These services have their own codebase are typically built around business capabilities and are independently deployable.
Why would someone want to use microservices architecture?
- Easy to Understand
Due to the decoupled nature, each service has a very specific job and hence easier to understand and maintain.
- Easy to Scale
Any hot services can be independently scaled from the rest of the system.
Each service is independent and hence easier to recompile and reconfigure to serve the purpose. Bug in any service only has impact on that service and doesn’t affect the entire application.
- Faster to Develop
Each service can be independently developed by a team that is only focused on that service.
- Easy to Adopt New Technology
Since any change in language or framework only affects the intended service, developers can choose any technology that makes sense without worrying about the decisions taken at the start of the project.
Why would someone NOT want to use microservices architecture?
- Cross Cutting Concerns
Cross cutting concerns such as logging, monitoring, auditing, etc. have to be added for each of the micro service. A separate module might be needed for each cross cutting concern.
- Higher Operational Overload
Each microservice has to be separately setup for logging, monitoring, etc and has to be independently deployed.
- Increase in Complexity
Microservice architecture results in a distributed system. You have to choose an inter process communication mechanism, setup and maintain these connections between all the modules and databases. Changes that span across multiple services have to be carefully planned and coordinated for rollout.
- Hard to Deploy
Each service will have multiple instances running. Each of these have to be configured, monitored and scaled separately. Getting this done manually is difficult and requires high level of automation.
Monolithic is great for small teams, without any microservices expertise, that want to develop a simple and lightweight application, which can be quickly deployed and tested.
Microservices is great for complex and evolving applications. It makes scaling and adding new capabilities much easier. However, proper microservices expertise is required.