Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Microservices Identification Approach

DZone 's Guide to

Microservices Identification Approach

The approach is everything!

Free Resource
Identifying microservices.Identifying microservices.


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.

Challenges

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;

  1. Employee Microservice.
  2. 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.

Microservices

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.

Pitfalls

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.

Strangler Design Pattern

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.

Conclusion

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.


Further Reading

9 Fundamentals of a Successful Microservice Design

Microservices Logging Best Practices

Topics:
microservice architecture ,microservices best practices ,microservices application ,microservices

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}