Moving from Monoliths to Microservices
Published in
5 min readJan 15, 2023
When deciding to break down a monolithic service into a set of microservices, it’s important to evaluate if it is truly necessary based on current and future needs of the application, rather than simply following the trend of using microservices under fomo. While microservices have their own set of advantages, it’s important to also consider the challenges and concerns that come with this architecture.
When Not To
Lets be devil’s advocate here and consider why/when you should not go for dissecting a monolithic service into a set of microservices.
- The application is small or has low traffic: in such a case the complexity and overhead of microservices may not be justified.
- No scalability issues: If the application is not facing scalability issues, breaking it into microservices may not be necessary.
- Lack of expertise: If the team does not have the necessary expertise in distributed systems, microservices, and containerization, it may be better to avoid this type of architecture.
- Complex dependencies: If the application has complex dependencies that would be hard to reproduce in a microservices architecture, it may be better to avoid this type of architecture.
- High cost: If the cost of breaking the monolithic application into microservices is high, it may not be worth the investment.
- Security concerns: If the application handles sensitive data, breaking it into microservices may introduce additional security concerns, and in that case it may be better to avoid this type of architecture.
If any of the above mentioned conditions are met in your case it may be worthwhile to discuss it out and come back to these rules again.
When to Consider Microservices
- Scalability: If the monolithic service with scalability and any other scalability measures don’t work, breaking it into microservices can improve scalability by allowing for independent scaling of different functional areas.
- Flexibility: If the monolithic service is becoming difficult to change or extend, breaking it into microservices can improve flexibility by allowing for independent development and deployment of different functional areas.
- Resilience: If the monolithic service is becoming difficult to maintain, breaking it into microservices can improve resilience by allowing for independent management and monitoring of different functional areas.
- Different teams work on different parts of the application: If different teams are working on different parts of the application, breaking it into microservices can make it easier for them to work independently and improve the collaboration
- Different technology stacks: If different parts of the monolithic service are or ‘better to be’ built with different technology stacks, breaking it into microservices allows for the use of the best technology for each specific area.
- Security: If the monolithic service handles sensitive data, breaking it into microservices can improve security by allowing for more granular access control and isolation of sensitive data. Well this kind of is a gray area as there is more to be put on guard with a set of microservices instead of single monolithic service.
How to Move to Microservices
There is not fit set of rules around breaking a monolithic service into a set of microservices, though a general guide can give you a good idea.
- Identify boundaries: Identify the different functional areas of the monolithic application, such as user management, data storage, and business logic. These functional areas will become the boundaries for the microservices.
- Decompose the application: Decompose the monolithic application into smaller, independent services that can be developed, deployed, and scaled independently. The output of step listed above would help with this.
- Define the API contract: Define the API contract for each service, including the data structures and the methods that can be called. This will ensure that the services can communicate with each other in a consistent and predictable way. It would be a great idea to think with an implementation perspective here and carve out any common code as modules that can be reused across multiple services.
- Refactor the code: Refactor the code of the monolithic application to fit the new architecture. This may involve moving code from the monolithic application to the new services, and updating the code to use the new API contract.
- Continuous integration and delivery: Implement continuous integration and delivery (CI/CD) to automate the deployment process and ensure that new services are deployed quickly and reliably.
- Logging: Logging is often an important but overlooked part when going for microservices since the call from one service may finish after traversing through a number of other services. Passing through a common factor like some sort of tracking id and logging it in each service would service beneficial at the time of tracing the logs and debugging.
- Transactions: It can be a bit challenging to implement transactions when there are a number of services finishing a part of a transaction which was earlier handled by single application. This should be taken care of with great deal and designed upfront even if there is a remote chance of it being a requirement in future.
- Start Small: Identify small portion and build upon it isolating it from the monolithic service and rerouting the traffic to the new service. This would be a repetitive process.
- Opting for different technologies for services can be a good choice as it would give a chance to ease the very pain point around a functional boundary. It would be wise to keep in mind the technical competencies and learning curve of the team at hand.
Its better to spend a little bit time and thought before taking the plunge!
Bonus: Break down monoliths and build reusable microservices with Bit
Bit’s open-source tool help 250,000+ devs to build apps with components.
Turn any UI, feature, or page into a reusable component — and share it across your applications. It’s easier to collaborate and build faster.
Split apps into components to make app development easier, and enjoy the best experience for the workflows you want:
