⭐ Microservice pattern is an architecture that functionally decomposes an application into a set of services. It doesn’t say anything about size. Each service has focused, cohesive set of responsibility.

Characterstics of Microservice architecture

  • X, Y and Z-Axis Scalability of micro services (Michael Fisher’s book - The Art of Scalability (Addison-Wesley, 2015) - Scale cube)
  • Microservices as a form of modularity
  • Each service has its own database

How is this different from Service oriented architecture (SOA)?

  • In SOA, smart pipes as Enterprise Services Bus (ESB) using heavyweight protocols like SOAP, while Microservices has Dumb pipes as a message broker, or direct service to service communication using REST or gRPC.
  • In SOA, data is global and shared, in MS database per service
  • SOA is a typical large monolith.

Benefits of Microservices

  • continuous delivery and deployment
  • small services easy to maintain
  • independently deployable
  • independently scalable
  • enables team to be autonomous
  • allows experimenting and adoption of new tech
  • better fault isolation

Challenges with Microservices

  • Finding right set of services
  • Distributed systems are complex, makes dev, test and deployment difficult
  • deploying fetures that span multiple services required carefult coordination
  • hard to know that when to adopt MS acrhitecture

When to use (or not use) Microservices

  • If it is working then don’t change it
  • MS is not a silver bullet

Microservices Architecture Pattern Language

It is a collection of patterns that help you:

  • architect your application
  • decide whether to use microservice architecture or not
  • use it effectively by solving various architecture and design issues.

📚 Christopher Alexender - A Pattern Language: Town, Buildings, Construction

📚 Erich Gamma, Richard Helm, Ralf Johnson and John Vlissides - Design Patterns: Elements of Reusable Object Oriented Software

Design Patterns

A Pattern is reusable solution to a problem that occurs in a particular context. Any repetable Pattern must describe the context in which that pattern is useful.

A commonly used pattern structure includes three especially valuable sections:

  • Forces: What issues you must address when solving with the pattern
  • Resulting Context: The consequences of applying the pattern
    • Benefits: What issues (Forces) pattern is going to solve
    • Drawback: which existing issues (forces) pattern doesn’t solve
    • Issues: if it introduces few more issues
  • Related Patterns:
    • Predecessor: Monolith architecture is predecessor of Microservices Architecture
    • Successor: A pattern which solves issues that has been introduced by current pattern
    • Alternative: A pattern that provides an alternative solution to this pattern. Like Microservice is alternative to Monolith.
    • Generaliztion: Any pattern which is a general solution to a common problem,
    • Specializaton: A pattern which solves a special problem. Like container patter is specialization of single service per host.

Patterns broadly can be divided into following three categories:

  • Infrastructure Patterns: solve problems that are mostly outside of development.
  • Application Infrastructure Patterns: Infrastructure issues that also impact development
  • Application Patterns: These solve problems faced by developers.

Pattern Layers

Main Groups of patterns

  • Decomposition Patterns

    • Decompose by business capability
    • Decompose by subdomain

  • Communication Patterns

    • Communication style
    • Discovery
    • Reliability
    • Transactional messaging
    • External API
    • Message prpcess gurantee

  • Data consistency Patterns for Transaction management

  • Patterns for querying the data in MS architecture (CQRS)

  • Service deployment patterns

  • Observability patterns provide insight into app behaviour

    • Health check API
    • Log aggregation
    • Distributed tracing
    • Exception tracking
    • Application metrics
    • Audit logging

  • Patterns for automated testing

    • Consumer-driven contract test: Verify that service meets expectations of its clients
    • consumer-side contract test: verify tat the client of a service can communicate with the service
    • Service componen test: test a service in isolation

  • Pattern for handling cross cutting concerns (database, Kafka related reusable concerns)

  • Security Patterns

Delivery Organization

📚 Fred Brooks: The Mythical Man-Month

Delivery Process

👉 Move fast without breaking things.

Human side

  • Ending, Losing and Letting Go
  • The Neutral zone
  • New beginning