Microservices Identification Approach
Microservices Identification Approach
The approach is everything!
Join the DZone community and get the full member experience.Join For Free
Organizations are working to transform their legacy applications to cloud-native architectures to be competitive in the marketplace. Microservices architecture should help in this transformation journey. Microservices is a popular technique or architectural style to structure application as a collection of loosely coupled services.
You may also like: 7 Strategies for Assigning Ids to Microservices
Legacy applications have many disadvantages;
- Inability to scale individual components to meet changes in demand.
- Lack of automated unit and functional test cases.
- Tight coupling between components makes it difficult to deploy frequently.
- High maintenance cost.
- Less adaptable to future changes.
With Microservices, you get many benefits;
- Scale-up and down individual components to meet changes in demand.
- Automate application lifecycle stages including build, test, deploy.
- Multiple application releases due to loose coupling between components.
- Highly adaptable to future changes.
I was recently involved in application modernization and migration to the cloud. Rewrite path was chosen for modernizing legacy monolith applications in the HR domain.
One of the important design activity is to identify what (micro) services are required and how to approach this process.
Identifying Microservices Boundary
There are no standard rules on how big or small Microservice should be, but general guidelines on how Microservice should be composed;
1. Each Microservice should have a single responsibility.
2. Each service should have a bounded context.
3. If some functionality changes more frequently than others then have opted for separate service.
Identification of Microservices is not without its challenges, and these arise from;
1. Lack of a good understanding of the legacy application's business domain or functionality.
2. Degree of application changes expected in the future.
Due to this very reason, Microservices architecture is not a time fixed activity. You need to revisit Microservices architecture when new requirements come up in the future.
To provide real case example I worked on, we used the guidelines listed above to come up with two microservices;
- Employee Microservice.
- Authorization Microservice.
Then a few weeks down the line, we were asked to implement Employee Search as an additional requirement. As this was required to be a reusable generic component, we opted for new Search Microservice which can be called from Angular client application. This made us easy to separate unit tests, troubleshoot and deploy without impacting the existing ones.
It should be possible to update, build, deploy and scale Microservices independent of each other. This would normally require;
- New code repository.
- Separate pipelines for Continuous Integration and Continuous Deployment.
- Environment Configuration data.
One should also be aware of pitfalls during the process of identifying microservices;
- Do not define Nano services (say at operation level).
- Do not spend time trying to identify all the microservices upfront. It's okay to have coarse-grained services initially that can be decomposed further (mini services to microservices) basis benefits and needs.
This is a popular design pattern to incrementally transform your monolithic legacy application into Microservices by replacing a particular functionality in legacy with a new service. Once the new functionality is ready, the old component is strangled, the new service is put into use, and the old component is decommissioned altogether. This pattern is usually followed in the Refactor type of transformation where the Legacy application is incrementally peeled off and converted to Microservices.
Identifying the scope of services is an important design consideration in the microservices architecture journey. There are guidelines and best practices that can help in this process.
Microservices does not stay permanent once identified. With changes in the requirement, you need to revisit and make a decision whether you need a new microservice or update existing ones.
You can start with coarser services and then split into fine-grained services as your understanding of application functionality matures.
Opinions expressed by DZone contributors are their own.