As part of our exercise, we decided to transition our existing monolithic application FlixOne to a microservice-styled architecture. We saw how to identify decomposition candidates within a monolith, based on the following parameters:
- Code complexity
- Technology adoption
- Resource requirement
- Human dependency
There are definite advantages it provides in regard to cost, security, and scalability, apart from technology independence. This also aligns the application more with the business goals.
The entire process of transitioning requires you to identify seams that act like boundaries of your microservices along which you can start the separation. You have to be careful about picking up seams on the right parameters. We have talked about how module interdependency, team structure, database, and technology are a few probable candidates. Special care is required to handle master data. It is more a choice of whether you want to handle master data through a separate service or through configurations. You will be the best judge for your scenario. The fundamental requirement of a microservice having its own database is that it removes many of the existing foreign key relationships. This would bring forth the need to pick your transaction-handling strategy intelligently to preserve data integrity.