Skip to main content

Decentralize the Service Cut

Context​

Microservices are in use or are planned to be adopted. The service cut is being planned or reconsidered. The project is rather big, making the fine-grained service cut complex.

Problem​

  • It is hard to plan the overall service cut as the project is so big

Solution​

Decentralize the service cut.

We found several indications that levels or layers exist in microservice-based systems. Microservices on these higher levels might, again, be composed by multiple microservices.

Instead of cutting all low-small microservices, rather conduct a top-down coarse-grained microservice cut for the first level in architecture. Let the microservice teams on the first level decide for themselves if and how they should split their area of responsibility futher into lower-level microservices.

Maturity​

More data needed (only 2 sources).

Sources of Evidence​

Code "Decentralize the service cut"​

L22:

  • James: top-down restructuring of product lines created bounded contexts automatically
    • service architecture follows
  • Nicolai: fan of botton-up design
    • centralized top-down enterprise-architecture-management is a waste of money
    • org structure and system structure match over long term
    • establish the right org structures => suiting software interfaces will emerge
    • James: "inverse Conway maneuver": build org you want, architecture follows
  • learning: top-down restructuring of business units helps to create bounded contexts

L27:

  • Context: "Contributor coupling strategy": generate service cut by looking at git history and teams working on them
    • comparibly high domain redundancy of this approach
  • Interpretation: they let the service cut emerge bottom-up by observing developer contributions

LM43:

  • Context: interviews and insights from multiple cases on technologies and sw quality in MSA
  • S2-S4
    • ~100 microservices structured in 15 domains
    • ~30 teams with over 300 people
    • service granularity differs because teams and contractors tend to cut very differently
    • architecture team tries to harmonize via frqeuent cutting and merging of services

Code "Collection: Levels in Architecture"​

L7:

  • open practitioner questions: can microservices be clients of other microservices
    • if so: how to avoid deployment dependency and inovation "spaghetti"
  • Interpretaion: This is a motivation for levels in architecture that implicitly reflect invocation chains downwards

L14:

  • Context: otto.de
    • necessity to sometimes further refine the vertical pillars
    • split independent features into a new vertical (microservice)
    • cut vertical further into distributed system of microservices

L20:

  • Microservice architectures support possibility hierarchical security policies
    • differently grained policies in different levels in architecture

L46:

  • Fig 7: Service model showing levels in architecture
    • 5 layers: entitiy services, business services, technical services, business process services, backend for frontend

L53:

  • Context: microservices for IoT systems
  • Microservices and API gateways might be located on device, edge cloud, internet cloud ,...
  • Depending on where the micoservices run, that also poses "levels" in architecture
    • Fig 6
  • Use of API gateway to aggregate services
    • independent protocol evolution of microservices, fine-grained locaiton for access policies
  • new microservices usually layered above old one

L54:

  • Each service is either independet or broken into smaller independent services

L55:

  • Context: example system
  • Orchestrator and Scheduler microservice: high-level composite business processes
    • Interpretation: this is a layer above the other microservices

LM43:

  • Context: SLR findings about microservices in DevOps
  • Table 10 lists layered architecture pattern

Interview C:

  • Context: mix of different communication paradigms in a microservice-based architecture (request response, pub-sub, streams)
  • they dont' mix well
    • each builds partial graph of the whole graph of microservices