Skip to main content

Evaluate the Microservice Cut With Prototypes

Context​

Microservices are in use or are planned to be adopted. The service cut has just been determined.

Problem​

  • It is unclear how good the determined service cut is and what its implications are

Solution​

Evaluate the service cut with a prototype. This prototype can be just a proof-of-concept or a minimal viable product that will be extended if the service cut was approved.

We did not find any established quantitative metrics that would give a context-dependent indication if service cut is suitable or not. Designing architecture often means deciding on trade-offs, and these should be evaluated.

We did not find suiting metrics to evaluate a service cut quantitatively. Technique Avoid LOC Metric for Service Cut Evaluation suggests to not use lines of code to evaluate a service cut.

A prototype can help to get a qualitative feeling for a service cut. Additionally, it supports to measure the characteristics of the resulting system quantitatively.

Maturity​

Proposed, requires evaluation.

Sources of Evidence​

Code "Evaluate Service Cut"​

L42:

  • Context: industry survey
  • After domain analysis + defining sharp boundaries between microservices
  • Practitioners identified need to get immediate feeling with the newly determined microservices

L62:

  • Absence of a sound evaluation methodology aggravates the challenge of decomposition

Interview F:

  • Context: how fine-granular to cut?
  • extremest case they saw: lambda functions => too fine granular
  • hard to describe which granularity is good
  • often a guts feeling

Code "Evaluate Cut with PoC / MVPs​

L42:

  • ways to get feeling for microservice cut
    • proof-of-concept services to investigate feasibility of migration
    • implement services as MVPs
      • artifact that may be incomplete in functionality/quality
      • but shows key characteristics for determining customer value