Collabrate On Libraries
Context
Microservices are being adopted. There are cross-cutting concerns that need to be tackled in multiple or every microservice. Standards are introduced to govern the technological diversity.
Problem
- Inefficiency as there is no code sharing between microservice towards cross-cutting concerns
- The technical diversity makes the system unmaintainable
- Introduced standards are not implemented
Solution
Introduce an inner-source or open-source process to foster collaboration between teams on cross-cutting issues. Libraries can be utilized to share code. However, they should only compose of reusable general-purpose code and not domain-specific aspects like shared models.
By basing the library on the standardized technology stack, it incentivizes the adherence to the standard. A reimplementation of the same logic on another technology stack poses a hurdle for introducing technology by consuming additional resources. A deviation of the standard will only be chosen if the effort is justifiable and worth it.
Maturity
Proposed, to be evaluated.
Sources of Evidence
L8:
- Some (Spotify) developed utility libs like for logging in a central repository
- Others (Uber) restrict freedom of technology choice
L14:
- Code should not be shared to avoid dependencies
- Exceptions:
- frontend assets
- loosely coupled, highly coherent general-purpose code that satisfies quality to be open sourced
- => other teams are free to use these libraries or use their own solutions
L44:
- in IoT context
- Component model for a microservice with various parts
- Secrity (orthogonal)
- SDK
- Event Hub
- Event Processor
- Task Scheduler
- Domain Logic
- Public API
- ...
- "Microservice core components" can be inherited from
- cross-service API calls for service data context exchange
- coordination
- remote service management
Interview E:
- Achieve overarching look-and-feel
- Designed systems
- A team buids a style library
- If decoupling => versioning
- Inner-sourcing
- Style-guide / widget library