Microservices: Understanding Candidate Identification and API Aggregation
In an earlier blog, I spoke about how the microservices style for building software architecture adopts a distributed approach. This allows for each service (or function) of the software to be highly independent, to have a specific business boundary or a defined context, be capable of managing its own data, and leverage different storing mechanisms.
Microservices architecture allows the software to be authored in different programming languages and maintained by disparate teams, building on a decentralizing approach much inspired by nature.
Over the past few years, microservices have become a popular choice for building large enterprise systems for its obvious benefits including flexibility and rapid scalability.
The Microservices Candidacy Conundrum — How Many Microservices Do I Need?
Despite its popularity, there is a growing realization that sizing a microservice can be a very tricky task. It requires meticulous planning and relies heavily upon the experience of the domain experts, software architects, and system designers.
A proper microservices identification and sizing would help define how a system will be able to evolve and scale — the primary goal of most enterprise systems. Therefore, finding the optimal size, boundary, and granularity constitutes the key to leveraging microservice architectural style benefits.
At this point, some of you may be thinking on the lines of entering troubled waters in search of perceived treasures with microservices architecture. Arguably, this is also the USP of this architectural style since it allows designers to begin with a draft list and later split and fuse microservices as and when more and more domain subjects and events are uncovered (or understood) thoroughly during evolution of the project. This allows designers to be agile and open for new changes.
Remember, this always is an iterative approach, as microservices candidates are rather challenging to be sized in one go.
I would like to focus on how designers can apply a technique to identity microservices candidates in a neutral, non-native manner . Designers can use this base technique and then refine it to their specific needs.
Microservices Candidacy through Business Processes (along with Domain Models and their APIs)
Step 1: Create a detailed step by step description of the user story with domain events attached.
Step 2: Convert it into a detailed sequence diagram.
Step 3: Identify each transaction, responses, and boundaries with respect to the relevant domain and data, and identify the APIs to be exposed for these transactions.
Step 4: The data Modelers/architects would then map the elements of data models to the sequence diagram.
Step 5: Domain experts to come up with domain models, maps, and designs.
Step 6: Identify the different clusters by synergizing the sequence diagram, data models, and domain models, including
• Data object clusters — Possessing a strong data relationship
• Activity clusters — Possessing a strong activity relationship
• Data access dependency clusters — Bottlenecks for scaling
Step 7: Identify microservices from the clusters identified with all the basic thumb rules of microservices, with activities describing the functionality that the target microservice intends to provide and the data object clusters which describe the data object which the microservice must administer.
Step 8: Performance and test architects to review and provide their comments from the Non-Functional Requirements (NFR) perspectives.
Step 9: Deployment and DevOps architects to review and provide their comments from the deployment perspectives.
Step 10: Principal architect to review and approve.
Let us illustrate this methodology with a hypothetical instance.
Sample Use Case: Let us assume we are building an e-commerce telecom application with the user story as below.
User Story — Customer wants to browse product catalog with his mobile app and check on eligibility for those products and offers.
Detailed step by step elaboration:
1. User opens his mobile app to browse the product catalog
2. He has the choice to browse various product lines and browse best current offers
3. User chooses to browse post-paid offers
4. The front end displays selection of post-paid offers and proposes to check the eligibility based on current geographical circles
5. User enters the geographical circle and triggers eligibility
6. Information shared by customer is checked and validated
7. User can now see packages which are eligible for him
Data model mappings happening in the background:
a. Fetch Catalog — Catalog Schema
b. Fetch Best Offers — Bundled Product Offerings
c. Fetch Postpaid — Category Schema
d. Eligibility — Eligibility Schema
e. Qualified Product Catalog — Bundled Product Offerings
Data clusters identified:
• Product
• Product Description
• Product related info
• User Activity log
Activity clusters:
• Listing Product lines
• Listing Best offers
• Listing Recommended Offers
• Eligibility check and listing eligible products
Potential microservices candidates:
1. Product_Inventory_Service — CRUD on Entire Product DB
2. Product_Enquiry_Service — Fetch Various Product lines and get Product description from Product DB or its projection
3. Recommend_Product_Service — Fetch recommended products given user details and Product lines
4. Eligibility_Check — Check user’s eligibility given the product line and user information
5. User_Activity_Manager — Logs all activities user performed to user activity DB
As an increasing number of microservices and their APIs are added to the architecture, a “Problem of Plenty” arises. Interested in knowing more? Follow us to uncover the need and possible solutions for API aggregation challenges in microservices.
Author
Senior Specialist — Digital Product Services, at L&T Technology Services
