Skip to main content

Use of Established Patterns

Context​

Microservices are being adopted. Each microservice is managed by exactly one team. The team is responsible for the whole life cycle of their microservice(s). There is missing knowledge about how to approach microservices, their implications, and the organizational alignment.

Problem​

  • Lack of knowledge in development teams how to do microservices and deal with their implications
    • e.g., how to split microservices, how to implement distributed architecture, DevOps, deal with network uncertainty, ...
  • Lack of knowledge on organizational level
    • e.g., how to structure teams, which processes need to be established

Solution​

Use established patterns organized in pattern catalogues (like this handbook).

Patterns are an abstraction of experiences aiming to provide reusable solutions for recurring problems in certain contexts. Instead of reinventing the wheel, you can apply existing patterns that have proven to work in other projects. Luckily there are already rich pattern catalogues (e.g. microservices.io, or this handbook) that provide guidance to utilize microservices. The ability to exploit design patterns is one of the advantages that microservice architectural style offers L20.

In this handbook, we aim to provide a more holistic pattern catalogue as we don't only provide design patterns, but also operational, organizational, and process-related best practices. As pattern catalogues often offer a pattern selection process supported by assembly guidelines, we also connect our best practices with each other via links to indicate which best practices go hand in hand or are alternatives to each other.

Maturity​

Proposed, requires evaluation.

Sources of Evidence​

L3:

  • Report on migration patterns
  • Practitioners use them to implement
  • Consultants use them to help plan
  • pattern = abstraction of experiences and best practices
  • pattern repository with reuseable process patterns or method chunks (instantiated from metamodel)
  • Pattern selectio nprocess
    • New migration experience / new domain => extract a migration pattern ==> store into pattern repository
    • selection and assembly guidelines to select specific patterns, use pattern discovery
  • Current state: microservices.io

L7:

  • raises question if existing design patterns give enough guidance?

L8:

  • Stability can be used by patterns in async communication
  • come in libraries that implement these patterns
  • need for patterns when splitting domain and sizing the services to help with design decision

L12:

  • Most of current approaches reuse knowledge by migration patterns without having cloud-native architectures as first-class citizens
  • Patterns like circuit breaker can migitate network service failures
  • Future work: consolidate practices and develop set of reuable patterns to migrate from on-premise to microservices
  • Patterns generalize the migration process, have well-defined structure that can be instantiated independently

L20:

  • pains of microservices are resolved by design-patterns
  • exploit of design patterns as big advantages of microservices
  • at design stage
  • studies discuss design patterns how to resolve pains
  • patterns and best practices to better leverage of microservices
  • Examples of patterns: database per service, API gateway, service discovery, circuit breaker

L24:

  • Some patterns already proposed in literature to reap benefits
  • Example: circuit breaker, API gateway, service discovery

L25:

  • Companies have issues of selecting the most appropriate architectural patterns
  • mainly becaus of lack of knowledge about the available patterns
  • patterns aim to support devs by finding suitable solution templates
  • patterns as key role in microservices

L31:

  • Have a pattern repository
  • Guidelines to select and compose patterns
  • Here topic: migration to microservices => build migration plan
  • Patterns address common problems
  • Pattern composition is project specific, process: (deviate where necessary)
    • (1) choose patterns without dependency => don't change the system / operational stuff
    • (2) change software system, but don't affect end users
    • (3) make internal changes transparent to end user
    • (4) solve problem of distributed system
    • (5) any remaining decomposition or operational patterns
  • factors: understandability, decomposition, modifiability, fault tolerance, deployment
  • Case (Backtory) pattern helped from development and operational perspective

L53:

  • Use patterns of microservice domain in IoT domain (in combination with other patterns)
  • Examples: API gateway, service distribution, discovery, containment, access control

L61:

  • Discovered design patterns in primary studies => need to see them as disjoint.
  • E.g. if API gateway does load balancing, both patterns are reported as separate patterns
  • Design patterns used by practitioners as catalogue of prepackaged solutions
    • to improve quality of architecture
    • potentially already validated by research community or evaluated in industry setting

Interview C:

  • Need to know the patterns and understand them
  • All come with advantages and disadvantages
  • E.g. have to know SAGA when having transaction-like business flows across services

Interview D:

  • Has seen many designs that called themselves Domain-driven
    • did not implement the loose coupling on domain level
  • => knowing a pack of pattern does not mean you can apply them