Skip to main content

Standardization

Context​

Microservices are being adopted. There are multiple teams, each responsible for their certain microservice(s). The teams enjoy full responsible for their microservices, including technological freedom and decision autonomy.

Problem​

  • A plethora of technology (tech stacks, programming languages, frameworks, data stores) emerges
    • Poses operation overhead
    • Limits the effectiveness of moving people from one team to another due to high knowledge barriers.

Solution​

Limit the technological diversity by introducing standards.

Topics where standardization might be beneficial:

Standards should evolve from within the teams since they are closest to the technical decisions and their implications, so use for example thematic boards to come to a consensus.

There can be agreed-on mandatory standards that are required to be fulfilled in order to operate the systems, e.g. the logging format. These standards should be enforced, e.g. by tests or style checks in the CI pipelines. However, the mantra should be to mandatorily standardize formats and protocols in these cases, not the explicit technology.

Service templates and collaboratively developed libraries are best practices to incentivize standards.

Maturity​

Proposed, to be evaluated.

Sources of Evidence​

Note: As this technique is an abstraction of the following techniques, we also used their sources to formulate this technique:

L5:

  • Need for standardized mechanism for service discovery

L6:

  • Context: Dimmer platform case
  • Standardization of plaform deployment and provisioning infrastructure
    • imposed by lack of centralized governance and independent techs
  • Need to deploy to multiple pilot cities => need for standardization on deployment strategies
    • large set of technologies to choose from
    • tools designed wo work with popular cloud infrastructures
    • => can be easily deployed by teams outside of platform consortium

L12:

  • Freedom in persistence and programming languages might lead to chaos and make the system unmaintainable
  • Standards as solution to that problem
  • Development templates for each leveraged language
    • (+) easy to start developing

L17:

  • Define architectural guidelines as part of the migration process towards microservices

L22:

  • Establish standards and practices for defining and implementing interfaces when decomposing the monolith
    • stateless, message-oriented, and hypermedia-driven

L26:

  • Importance of standards despite the rapid changes (agility)
  • "[..] flexibility and ease of implementation [...] is either compatible with or in fact greatly driven by the emergence of successful design patterns that are already in the process of becoming standards"

L32:

  • Each team could choose their own tech stack
    • can create knowledge silos => makes moving individuals into other teams more difficult
    • each tech stack requires operational overhead => outweighs benefits
  • Introduce governance
    • Review process for each new tech stack
    • (+) Utilize flexibility of polyglotness where necessary
    • (+) Prevent the chaos / operational overhead / knowledge silos

L49:

  • Microservices should have an open and standardized interface describing all available communication methods
    • graphical interface or API

L52:

  • freedom of technology usually perceived as advantage
    • best tool for the job
    • reduces risk of lock-ins into outdated technology
    • supports culture of innovation and experimentation

L59:

  • Need for standardized way of packaging and deploying microservices

LM45:

  • Context: interviews and insights from multiple cases on technologies and sw quality in MSA
  • C2-S4
    • ~100 microservices, structured in 15 domains; over 300 people from several contractors, organized in 30 teams
    • central architecture team providing meta-guideleins and cross-cutting concerns like Docker images or authentication
  • decentralization characteristic => central governance
    • P4: created large amount of guidelines and rules for service creation

Interview A:

  • Standardization as key factor (along with automatization)
  • Standards should emerge from within teams
    • The higher up the decision is made, the more they lack the understanding and implication of the technological choices
  • Commitment to follow standards without exceptions
    • Example with configuring services => leads to errors in production otherwise
  • In cases where standards don't suffice: question them and adapt them
  • What to standardize
    • Way of configuring services (fail fast)
    • Communication protocol between services (e.g. at their project REST)
    • Logging: to std-out in JSON

Interview B:

  • API design guide
    • Standardizes
      • how payload looks like
      • return codes
      • failure signalling
      • caching
      • location header
      • etc.
    • As soon as possible
    • Should be exhaustive
    • For events and Rest
    • Style checks in CI to enforce it
    • Otherwise every service feels different
  • Freedom of technology only works until a certain point
  • Need for standardized tracing across services
    • Which infrastructure
    • Which tracing format
  • Overarching security concept
  • Documentation (e.g. OpenAPI)
  • What does API Gateway, Service mesh etc.

Interview D:

  • Need for standard reaction patterns to handle errors
  • Standardized way to finding and embedding launched APIs
  • Standardize for efficiency
    • Examples
      • which kind of communication between cpability borders
      • structure of events to be able to read them
      • versioning or alternative
      • how to announce deprecation of APIs
      • authentication, authorization, token handling
    • => so that coordination has not to start at zero but is reduced to minimal aammount
  • Too much standardization is also not good => trade-off
    • => parabolic curve
  • Standardize should come from teams each sending a representative

Interview E:

  • Achieve overarching look-and-feel
  • Designed systems
    • A team buids a style library
    • If decoupling => versioning
    • Inner-sourcing
  • Style-guide / widget library
  • How to come up with the standard?
    • Guild system => design guild
    • vs. UX expert defines or serves as consultant
    • Some devs prefer having a "dictatorship" because they don't have to deal with it
    • Other teams are more design affine => incorporate to prevent a revolution
    • Often triggered buttom-up, but top-down final decision
      • at least for the feeling of the people to be involved
      • often personal sensitivities play a role => sometimes easier if someone up there decides
      • responsibles (e.g. architect team) decide for sth they can maintain over time
  • Complete freedom of teams unconmmon
    • Technology decisions overarching
    • Introducing new tech still can make sense, not short term, but over time
      • No framework lives forever

Interview F:

  • Automation plays well with standardization
    • Enforce standards by automation: tests, linting
    • To enforce a certain quality standard that everyone can rely on
  • Standardization examples
    • List representation in REST has different RFCs
    • In general: standardize communication to work similarly everywhere
  • Standardization process
    • Lead-architect or customer
    • Each team having architecture affine representative assisting lead architect
  • Standards enforced by audits
    • Gradually by milestone which standards need to be fulfilled
    • Also other things as processes audited
  • Emphasizes at end that standards are personally important to him
    • makes your life easier and more comforable
    • even if it is exhaustive at the first glance => good citation