Skip to main content

Avoid LOC Metric for Service Size

Context​

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

Problem​

  • It is unclear how large a suiting microservice should have

Solution​

Don't use lines of code (LOC) as metric to evaluate the size of a microservice (and the underlying service cut).

There is no clear indication how many LOC a microservice should have. Rather, focus on qualitative metrics like single comprehensibility and self-containment.

We recommend to evaluate the service with a prototype instead.

Maturity​

Proposed, requires evaluation.

Sources of Evidence​

L4:

  • Some microservices have couple of hundred liens of code
  • others up to a couple of thousand lines of code
  • => should do one thing and one thing only
  • you should be able to understand them
  • should have single reason change
  • probably not more than a couple of thousand lines of code

L8:

  • lack of agreement on right service size
    • drastically different interpretations of term "micro"
    • some few to few dozen LOC
    • others a few kLOC, few dozen classes and database entities

L32:

  • no strict rule on lines of code
  • rule of thumb: each service must be kept to size that a single engineer can comprehend

L34:

  • e-commerce shop system
    • 100 microservices
    • or 5-25 SCS
  • SCS suggests a microservice has around 100 lines of code

L43:

  • Context: case study
  • microservices, each in order of several hundred lines of code

LN44:

  • DDD usually results in smaller codebase per microservice
  • if measure with LOC: more LOC => more bugs; more bugs => more exploitable bugs
  • smaller microservices => smaller attack surface
  • reduced cognitive complexity, better code comprehension for individual developers
    • opposite for architects

Interview B:

  • Important is not the size, but that the microservice is enclosed/self-contained and independent from others

Interview C:

  • discussions if "micro" really means "micro" or rather "macro"
    • "micro" does not mean size of code / platform, but amount of functionality
    • enclosed small as in components in 90s
      • component has enclosed function area at max
      • function alone might be too far-fetched