Published on

Deciding which services to migrate to microservices

Authors
  • avatar
    Name
    Parminder Singh
    Twitter

Attempting to fit every component of a monolithic architecture into a microservice is like trying to fit a square peg into a round hole. Not everything belongs, and forcing it only distorts the integrity of both the structure and the function. The right choice can lead to enhanced scalability, easier maintenance, and faster deployment times. Conversely, the wrong choice can result in increased complexity, unnecessary overhead, potential performance bottlenecks and wasted resources. In this blog we will provide a framework to identify which functionalities or modules are ripe for migration to a microservice and which are not.

DECIDE framework

The DECIDE framework provides a structured approach to evaluating candidates for microservices. Image by author.

The DECIDE Checklist

Consider the following checklist when evaluating which functionalities or modules are good candidates for microservices:

  1. D - Domain-Driven Design (DDD) Alignment: Services should align with business capabilities. Each microservice should encapsulate a specific domain of business functionality. This ensures that services are focused and cohesive, and that they can evolve independently. E.g. a service handling authentication might be a good candidate, as it represents a distinct domain of user management. A service that only performs logging might not be the best candidate, as logging is a cross-cutting concern that spans multiple domains.

  2. E - Encapsulation: Services that can encapsulate their data and behavior, minimizing dependencies on other services are ideal. E.g. a billing service, managing invoices and payments, can operate independently from other services. A service that requires frequent, synchronous calls to other services for data might not be a good candidate due to tight coupling.

  3. C - Cohesion: Services should have high internal cohesion, meaning they perform a set of related functions. E.g. a storage service that handles file storage, retrieval, and metadata management demonstrates high cohesion. A service that combines user authentication, billing, and email notifications lacks cohesion and is not suited.

  4. I - Independent Scalability: Services should be able to scale independently without necessitating the scaling of other services. E.g. a content delivery network (CDN) service needs to scale based on traffic independently from the compute or storage services. If a service's scalability is heavily dependent on another service's capacity, it's not an ideal candidate.

  5. D - Deployment Independence: Services should be deployable independently of one another, enabling quick updates and rollbacks. E.g. a microservice managing DNS settings can be updated independently of a service managing virtual machines. A service that requires simultaneous updates with other services to maintain compatibility is not ideal.

  6. E - Evolvable: Services should be evolvable, able to adapt and expand without disrupting the ecosystem. E.g. an API gateway service is designed to evolve as new microservices are added or changed within the infrastructure. A service so tightly integrated that changes require widespread updates across other services is poorly suited for microservices.

Takeaways

While the above D.E.C.I.D.E. framework provides a structured approach to evaluating candidates for microservices, it's essential to follow general guidelines and avoid some of the following common anti-patterns:

Distributed Monolith: This occurs when services are so tightly coupled in terms of data, API calls, or shared libraries that they cannot be deployed, scaled, or developed independently. Despite being physically separated, the tight coupling retains the drawbacks of a monolithic architecture, such as slow deployment cycles and scalability issues, while forfeiting the benefits of microservices.

Anemic Services & Microservice Sprawl: Creating microservices that are too small or too numerous can lead to anemic services, where each service lacks the necessary business logic to be meaningful on its own.

Over Communication: Excessive communication between microservices can lead to performance bottlenecks and increased complexity. It's essential to strike a balance between service independence and inter-service communication.

I would love to know about your experience with migrating to microservices. What challenges did you face? What strategies did you use to identify which services to migrate? Please share your thoughts.

Also published on my medium channel here.