Identifying candidates for microservices

The top-most challenge in migrating from a monolithic application to microservices is to identify the right candidates for microservices. A well structured and modularized monolithic application already has well-defined boundaries (bounded contexts) that can help disintegrate the application into microservices. For example, the User, Orders, and Interest modules already have well-defined boundaries and are good candidates to create microservices for. If the application does not have well-defined boundaries, the first step is to refactor the existing application to create such bounded contexts for microservices. Each bounded context must be tied to a business capability for which a service can be created.

Another approach in identifying the right candidates for microservices is to look at the data access patterns and associated business logic. If the same database is being updated by multiple components of a monolithic application, then it makes sense to create a service for the primary component with associated business logic that manages the database and makes it accessible to other services via APIs. This process can be repeated until databases and the associated business logic are managed by one and only one service that has a small set of responsibilities, modeled around a business capability.

For example, a monolithic application consisting of User, Interest, and Orders components can be migrated into microservices by picking one component at a time and creating a microservice with an isolated database, as shown in the preceding diagram. To start with, first pick the one with the least dependency, the User module, and create the User Service service around it. All other components can now talk to this new User Service for User Management, including authentication, authorization, and getting user profiles. Next, pick the Orders module based on the least dependency logic, and create a service around it. Finally, pick the Interest module as it is dependent on both the User and Orders modules. Since we have the databases isolated, we can also swap out the database for Interest with maybe a graph database that is efficient to store and retrieve user interests due to its inherent capability of storing relationships as a graph.