Skip to main content

Push More Responsibility to Microservice Teams

Context​

Microservices are being adopted. Each microservice should be owned by exactly one team to avoid ambiguities. One of the main goals is to foster independent deployments of microservices and increased innovation speed.

Problem​

  • The central top-down governance slows down decision processes and the overall innovation speed

Solution​

Decentralize the governance by giving more responsibility to the microservice teams. The microservice team is responsible for the full microservice life cycle from requirements engineering to operation.

Contrary to SOA, microservices emphasize the decentralization of the governance and the responsibility of the overall software to its components. Since there is not the one large code base, many decisions can be made locally within the microservice teams without the need to coordinate with other teams. This leads to a reduced global governance overhead. There might even be no need for a synchronization of development cycles of the teams.

The chance of delegating responsibility to the teams and decentralizing governance is an often quoted benefit of microservices. Each team can move on their own pace and decide on the used technology that fits best in the context, and gradually adopt new technology independently.

This technological freedom might conflict with other goals like avoiding to reinvent the wheel over and over again, and thus should be counteracted with decentralized governance practices like incentivizing standards. There is also the risk that local decisions within teams contradicts with global goals because the bigger picture is missing. This should be avoided by having coordination mechanisms between teams in place.

Taking full responsibility for all phases of the microservice lifecycle requires the knowledge and skills to do so, posing the challenge of a potential knowledge barrier to ensure team autonomy.

Maturity​

Proposed, to be evaluated.

Sources of Evidence​

L5:

  • self-manged, decentralized management, audibility

L6:

  • independent deployable components
    • => centralized governance, standards, tech platforms can be relaxed
    • (+) Each microservice can use own technology most suitable for the job
    • (+) consider tradeoffs of tools/technology individually
    • (+) gradually adopt new technology

L7:

  • decentralized governance enables polyglot programming
  • SOA: might be centralized but does not have to
  • mantra "decentralized everything" includes decentralized governance

L8:

  • autonomous teams double-edged sword
  • (+) local decisions => no need to coordinate with others
  • (-) increases risk of teams not seeing the big picture => but that should also influence local decisions
    • examples: infrastructure solutions difficult to communicate and reuse across services
    • conflict-avoidance culture: teams fix locally problems that other team's responsibility

L14:

  • modular structure of microservices esp. important for larger teams
  • decoupling teams as relevant as decoupling software modules
  • Organization vertically decomposed (as well as architecture)
    • (+) enables to scale dev capacities according to new requirements

L17:

  • distribution of clear and independent responsibilities among teams allows splitting large projects
    • into small more efficient teams
  • survey, smaller amount of participants: delegation and clear responsibility leads to separation of concerns as benefit

L20:

  • Microservice analysed, understood and updated without knowing anything about internals of other microservices
  • impacts governance of application => can be decentralized (benefit)
    • benefit of bounded contexts according to 7 of 24 studies
    • assign governance of different microservices to different groups

L22:

  • Microservices are autonomously developed

L32:

  • monolith: many design decisions need to be discussed by many teams since same code base
    • takes long although each person contributing may not be significant

L34:

  • Microservices managed by individual teams

L35:

  • Each microservice owned and operated by an independent team of devs

L38:

  • Each microservice may be developed and deployed independently by different teams

L41:

  • Microservice should be developable manageable by exactly one team
  • Conway's law => pay attention to org structure to build modular and loosely coupled design
  • More efficient communication on team level, but also within whole org => improves modularity of design

L45:

  • Team composed by 1 or more devs
  • Each microservice is owned by exactly one team

L46:

  • SOA: centralized governance
  • Microservices: decentralized governance

L53:

  • Self-contained microservice usually no external dependencies
  • => development broken into many small semi-independent and focused teams (IoT context)

L54:

  • Client/server, Mobile agents, SOA: centralized governance
  • Microservices: decentralized governance

L61:

  • decentralized and data management allows service independency
    • avoids standardization on a single technology

LN41:

  • fine granularity means bare minimum of centralized management of services
  • may lead to different programming languages with minimum development resources

LM45:

  • Context: interviews and insights from multiple cases on technologies and sw quality in MSA
  • C2-S2: high degree of central governance
  • C2-S3: medium degree of central governance, several restrictions from customer
  • C2-S4: decent autonomy for inner architecture, central architecture team provides guidelines for cross-cutting concerns
  • C4-S6: teams have medium amount of autonomy
    • there is central governance, customer can override decisions
  • C4-S7: teams have medium amount of autonomy
    • there is central governance for macro architecture, security, QA
  • C6-S9: teams have high degree of autonomy
    • minum of central governance, focused on common IT strategy
  • C8-S12: Architects have basic central governance for strategy, modernization and macro architecture
    • self-perception as coaches
  • C9-S13: central governace and customer prescribed most decisions
  • C10-S14: central governance involves IT strategy and general architecture guidelines only
  • DevOps and automation
    • 5/12: you build it you run it
  • influence of project nature on decentralization
    • large systems: developed with high degree of central governance and coordination
      • some cases: teams autonomy for inner architecture
    • some have concrete specs or prescribed tech/arch by customer
    • remaining eight systems: rather decentralized way
    • high degree of decentralization and team autonomy only in three companies
      • in combination with the "you build it you run it" principle
  • degree of decentralization can lead to differnt levels of technological heterogeneity
    • but not as large as expected

Interview A:

  • teams autonomous, sync in scrum-like manner
  • not a friend of every team reinventing the wheel
  • can't make to sync on overarching iteration rhythm, but seems no need to do so

Interview D:

  • Clearly distributed governance and distributed data managenent as underrated topic
  • Reason for microservices: need for independent deployments of business capabilities
    • requires independent teams moving with their own velocity
    • => was the challenge of the hyperscales
    • Etsy as example how to approach it differently with a monolith that is deployed 50 times a day
    • Still microservices make the life easier in that concern
    • Most often environement does not allow for this independence: requirements, infrastructure, making experiments ,... => only about development velocity in a highly dymanic market

Interview E:

  • Technology decision often spanning teams, architecture within microfrontend not
  • Standardization often triggered as democratic bottom-up process
    • But central governing team has responsibility and makes the final decision
  • Favors vertical teams
    • Know-how in team for vertical
    • Can design and change APIs as frontend+backend in their responsiblitly
    • horiziontal teams => often "we against them" situations
  • Who drives API? Frontend vs. backend

Interview F:

  • Microservice boundaries for different suppliers of functionality
    • different development processes with different cycles
    • different cycles => coordination
    • requires good PO + Scrum Master to tackle