Service Cut by Non-Functional Requirements
Context
Microservices are in use or are planned to be adopted. The service cut is being planned or reconsidered. Parts of the system have very diverse non-functional requirements, e.g., towards data privacy, security, scalability, or others.
Problem
- A bad service cut might lead to the need to satisfy the union of all non-functional requirements in multiple microservices.
Solution
Use the non-functional requirements specific for a subpart of the system to drive the microservice cut.
For example, if you have very sensible data that should be accessible by as few people as possible, encapsulate it within a microservice. This allows designing the specific microservice to satisfy these non-functional requirements while sparing the rest of the system doing so.
Maturity
Proposed, requires evaluation.
Sources of Evidence
LN39:
- Cut by implementation technology (e.g., computations in C, chatty in NodeJs)
- Cut based on greography (legal, commercial, or cultural aspects)
- Cut by certain other non-functional requirements
- Table 2
- Workload-based decomposition
- Security and scalability requirements based
- GranMicro: based on non-functional requirements
Interview D:
- Extremely diverse non-functinoal requirements can make sense for a service split (10% of the cases)
- Example: high requirements in one part of the system towards privacy or integrity (only 4 people of backoffice are allowed to access the data)
- Monolith: union of all non-functional requirements
- Microservices: individually
- => one way to cut, but doesn't imply it
Interview F:
- Company politics influencing the service cut
- data treasure that must be within only one team; all others. no access
- quite clear that this had to be a separate service
- further cut based on other principles