Monolithic vs Microservices Architecture
This is the 1st post in a series on microservices architecture. This article is originally published at https://www.learncsdesign.com
It’s important to understand the pros and cons of both architectures. Let’s discuss them in detail.
We consider a monolithic system one in which all functionality is deployed in one go. There are two types of monolithic systems.
- Single process monolith — All code is packaged into a single process.
2. Distributed monolithic— The system consists of multiple services, but for whatever reason, it must be deployed as a whole.
Pros of Monolithic Architecture
- Easy to develop and test.
- Deploys as a single deployment unit.
- Easily scale horizontally with the same deployment unit.
- Requires less technical expertise and sharing the same underlying code.
- Allows high performance by centralizing code and memory.
- Suitable for small applications.
Cons of Monolithic Architecture
- The complexity of a system increases with time.
- New features take a long time to be released.
- Production hotfixes take longer.
- When a small change occurs in a module, the entire application has to be updated.
- Unable to adopt newer technologies for better performance due to their close relationship with one technology.
- Single point of failure.
- Code becomes complex and doing KT becomes increasingly challenging due to high coupling.
- High dependency on key developers who understand the entire code base
- Continuous deployment is challenging.
- Individual modules are difficult to scale.
- The high coupling between modules causes reliability and availability issues.
- Security concerns as all deployment are at one place.
The concept of microservices refers to independent, deployable services attached to a particular business domain. Microservices communicate through networks. The microservice architecture consists of multiple collaborating microservices and is a form of service-oriented architecture (SOA).
Microservices are small Autonomous services that work well together, modeled around a business domain.
— Sam Newman
The fundamental characteristic of microservices is their agnosticism toward technology. Using one or more network endpoints, microservices expose the business capabilities that they encapsulate. They also encapsulate data storage and retrieval, exposing data via well-defined interfaces, making them a form of a distributed system. Databases are therefore hidden inside the service boundary. Let’s examine these concepts in more detail.
Independent Deployability — The idea is that we can make a change to a microservice and deploy it into production without having to use any other services. Our services need to be loosely coupled to ensure independent deployment.
Modeled Around a business domain — Each service caters to only one subdomain of business needs and is responsible for that subdomain. Microservices should adhere to the Single Responsibility Principle (SRP).
Own their own data — When a microservice needs access to data held by another service, it should ask that service for the data. Microservices should not share databases.
Pros of Microservices
- Domain knowledge and business expertise.
- Independent scalable.
- Accelerates the velocity of software development by enabling small, autonomous teams to work in parallel.
- The ability to respond quickly to change.
- Improves uptime.
- Adapt newer technology more easily.
- Loose coupling.
- Ideal for large-scale applications.
- Clearly defined team ownership of microservices.
- Customizable security for different services.
Cons of Microservices
- Distributed systems introduce additional complexity.
- Deployment complexity.
- Monitoring is more complex.
- Increasing resource consumption and lots more servers to manage.
- Network communication between distributed services is not instantaneous and may result in latencies.
- Testing services can be challenging.
- Data consistency between services is challenging and complex.
Below are links to posts that explain each pattern in more detail.