Skip to main content

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