Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Communication Strategies for Microservices

Communication Strategies for Microservices

There are many ways that Microservices can communicate with each other. Starting from synchronously calling REST Resources to Domain Event based decoupling there are many flavours to choose from for teams and organizations. However the choice of communication will obviously have an impact on how you structure your Microservices, what infrastructure you should have in place and of course on the way you treat data. In this talk we will take a look at various strategies such as synchronous calls, messaging solutions, Domain Events and even Event Sourcing / CQRS. The latter is obviously not directly a communication strategy but brings in some interesting possibilities. In addition to that I will explain what impacts, advantages and disadvantages each of the possibilities has. Finally we will close the talk by evaluating how teams can move from a synchronous landscape with lots of chattiness to a more decoupled landscape.

Michael Plöd

May 11, 2018
Tweet

More Decks by Michael Plöd

Other Decks in Programming

Transcript

  1. Communication Strategies 

    for

    Microservices
    Michael Plöd - INNOQ - @bitboss
    Kraków, 9-11 May 2018

    View full-size slide

  2. What has
    a better
    structure
    and looks
    cleaner?

    View full-size slide

  3. Our starting point is
    often
    the monolith
    from the gates of hell

    View full-size slide

  4. Monoliths suck, let’s do
    microservices and REST
    AuthorService
    EMail Service
    Roles Service
    OutBound Service
    Print Service
    Post Service
    Print Service
    Print Service
    Print Service

    View full-size slide

  5. Sure, and we might end
    up with this

    View full-size slide

  6. ! With the adoption of
    microservices a former
    implicitly hidden complexity
    suddenly becomes explicitly
    visible and the challenges for
    communication grow
    exponentially

    View full-size slide

  7. I can’t stress this enough

    View full-size slide

  8. Distributed Systems
    are
    Difficult Systems

    View full-size slide

  9. Integration is not just technical
    Teams
    In order to integrate, teams often need to communicate
    with each other which may lead to politics and
    governance issues.
    Technology
    REST is not the only option for you
    Quality

    Criteria
    What are your requirements with regards to
    consistency, performance, scalability and robustness?
    Coupling
    How do you plan to achieve the mantra „how cohesion,
    low coupling“ for your microservices?

    View full-size slide

  10. Bounded Context
    Context Map
    Shared
    Kernel
    Customer
    / 

    Supplier
    Conformist
    Anticorruption

    Layer
    Separate
    Ways
    Open
    /
    Host 

    Service
    Published 

    Language
    Domain-driven Design
    helps us with regards
    to teams and coupling

    View full-size slide

  11. Bounded Context
    Every sophisticated business
    (sub-) domain consists of a
    bunch of Bounded Contexts
    Each Bounded Context
    contains models and maybe
    other contexts
    The Bounded Context is also
    a boundary for the meaning
    of a given model

    View full-size slide

  12. Example - You at GeeCon
    Reservations
    Event

    Management
    Badges
    GeeCon

    Visitor
    Name
    Payment Details
    Address
    Company
    Session Registrations
    Lunch Preferences
    Name
    Job Description
    Twitter Handle

    View full-size slide

  13. Context Map
    The Bounded Context by
    itself does not deliver an
    overview of the system
    By introducing a Context
    Map we describe the contact
    between models / contexts
    The Context Map is also a
    great starting point for
    future transformations

    View full-size slide

  14. Upstream / Downstream
    Credit Agency
    Scoring
    Call Flow Model Flow
    Focus of 

    Context Map
    Upstream System
    Downstream System

    View full-size slide

  15. Context Map Patterns Categorized
    Credit Agency
    Scoring
    Model Flow
    Upstream System
    Downstream System
    Upstream Patterns:
    • Open Host Service
    Downstream Patterns:
    • Customer / Supplier
    • Conformist
    • Anticorruption Layer
    In-Between Patterns:
    • Shared Kernel
    • Published Language
    • Separate Ways

    View full-size slide

  16. Context Maps and Conway’s Law
    Team
    independence
    Tight Coupling /
    Integration
    Shared Kernel
    Customer / Supplier
    Conformist
    Anticorruption Layer
    Separate Ways
    Open / Host Service
    Published Language
    Team
    Communication
    Event Publisher

    View full-size slide

  17. !Perform an early assessment
    of the real quality criteria
    that are relevant for your
    application

    View full-size slide

  18. Integration is not just technical
    Teams
    In order to integrate, teams often need to communicate
    with each other which may lead to politics and
    governance issues.
    Technology
    REST is not the only option for you
    Quality

    Criteria
    What are your requirements with regards to
    consistency, performance, scalability and robustness?
    Coupling
    How do you plan to achieve the mantra „how cohesion,
    low coupling“ for your microservices?

    View full-size slide

  19. Technical Options
    ➡ RESTful Resources
    ➡ Messaging
    ➡ Domain Events
    ➡ Feeds
    General Categories
    ➡ Orchestration
    ➡ Choreography
    Technical Aspects
    Microservice
    Communication

    View full-size slide

  20. Technical Options
    ➡ RESTful Resources
    ➡ Messaging
    ➡ Domain Events
    ➡ Feeds
    General Categories
    ➡ Orchestration
    ➡ Choreography
    Technical Aspects
    Microservice
    Communication

    View full-size slide

  21. Orchestration
    Credit

    Application
    Scoring
    Credit
    Decision
    Customer
    Create Customer
    Perform
    Scoring
    Decide on
    credit application
    Building Microservices by Sam Newman, O'Reilly

    View full-size slide

  22. Choreography
    Credit

    Application
    Scoring
    Credit
    Decision
    Customer
    Credit

    Application

    Submitted
    Event
    Building Microservices by Sam Newman, O'Reilly

    View full-size slide

  23. Orchestration
    vs
    Choreography
    Building Microservices by Sam Newman, O'Reilly
    Event
    Stream
    Choreography
    Orchestration

    View full-size slide

  24. Technical Options
    ➡ RESTful Resources
    ➡ Messaging
    ➡ Domain Events
    ➡ Feeds
    General Categories
    ➡ Orchestration
    ➡ Choreography
    Technical Aspects
    Microservice
    Communication

    View full-size slide

  25. RESTful Resources
    Upstream System
    Downstream System
    RESTful Resource
    Architectural style based on HTTP.
    Well known to most teams but
    often not so well implemented.
    Support for Hypermedia, multiple
    representations and synchronous
    by default.
    Implementing a simple call to a
    RESTful Resource is easy, a robust
    one not so much.

    View full-size slide

  26. Challenges
    to consider
    regarding
    REST
    Service
    Discovery
    How do downstream systems know about the URLs of
    upstream services? How many instances of a certain
    microservice are available, what is their health and
    where are they?
    Load
    Balancing
    How and where is load balancing being performed?
    Client-side, through the platform or with a dedicated
    hardware?
    Resilience
    How do you plan to deal with systems that suddenly
    produce errors, that are unavailable or with high
    latencies? How do you plan to avoid cascading error
    scenarios?

    View full-size slide

  27. Service lookup by name
    HATEAOS for interface discovery
    Service
    Discovery
    How do downstream systems know about the URLs of
    upstream services? How many instances of a certain
    microservice are available, what is their health and
    where are they?
    Service Registries
    ➡ Central Infrastructure
    ➡ Needs to be maintained
    ➡ Examples: Eureka or
    Consul
    Platform-based
    ➡ Part of your PaaS
    Platform
    ➡ Lookup through service
    names or routes
    DNS
    ➡ Service discovery with
    DNS-Lookups
    ➡ DNS needs to be
    maintained

    View full-size slide

  28. Challenges
    to consider
    regarding
    REST
    Service
    Discovery
    How do downstream systems know about the URLs of
    upstream services? How many instances of a certain
    microservice are available, what is their health and
    where are they?
    Load
    Balancing
    How and where is load balancing being performed?
    Client-side, through the platform or with a dedicated
    hardware?
    Resilience
    How do you plan to deal with systems that suddenly
    produce errors, that are unavailable or with high
    latencies? How do you plan to avoid cascading error
    scenarios?

    View full-size slide

  29. Resilience
    How do you plan to deal with systems that suddenly
    produce errors, that are unavailable or with high
    latencies? How do you plan to avoid cascading error
    scenarios?
    AuthorService
    EMail Service Roles Service
    THREAD POOL
    Gets slower and slower….
    Thread Pool is full
    No requests to other 

    microservices are possible
    Problem

    View full-size slide

  30. Resilience
    How do you plan to deal with systems that suddenly
    produce errors, that are unavailable or with high
    latencies? How do you plan to avoid cascading error
    scenarios?
    AuthorService
    EMail Service Roles Service
    THREAD POOL
    Gets slower and slower….
    Thread Pool is full
    Incoming Requests
    get stuck
    Problem

    View full-size slide

  31. Solution
    AuthorService
    EMail Service Roles Service
    Resilience
    How do you plan to deal with systems that suddenly
    produce errors, that are unavailable or with high
    latencies? How do you plan to avoid cascading error
    scenarios?
    AuthorService
    EMail Service Roles Service
    THREAD POOL
    Gets slower and slower….
    Thread Pool is full
    Incoming Requests
    get stuck
    THREAD POOL THREAD POOL
    Bulkheads
    Circuit Breakers
    Problem

    View full-size slide

  32. Challenges
    to consider
    regarding
    REST
    Service
    Discovery
    How do downstream systems know about the URLs of
    upstream services? How many instances of a certain
    microservice are available, what is their health and
    where are they?
    Load
    Balancing
    How and where is load balancing being performed?
    Client-side, through the platform or with a dedicated
    hardware?
    Resilience
    How do you plan to deal with systems that suddenly
    produce errors, that are unavailable or with high
    latencies? How do you plan to avoid cascading error
    scenarios?

    View full-size slide

  33. Good combinations with Service Discovery options
    Load
    Balancing
    How and where is load balancing being performed?
    Client-side, through the platform or with a dedicated
    hardware?
    Client-side
    ➡ Client knows about all
    available service
    instances
    ➡ Implements its own
    load balancing
    ➡ Example: Ribbon
    Platform-based
    ➡ Part of your PaaS
    Platform
    ➡ Behind every route /
    service name are 1..n
    instances
    Infrastructure
    ➡ Hardware or dedicated
    software load balancers
    ➡ Dedicated, centralized
    infrastructure
    ➡ Often not maintained
    by dev team
    Service Registries DNS
    Service

    Registries
    Platform

    based

    View full-size slide

  34. Challenges
    to consider
    regarding
    REST
    Service
    Discovery
    How do downstream systems know about the URLs of
    upstream services? How many instances of a certain
    microservice are available, what is their health and
    where are they?
    Load
    Balancing
    How and where is load balancing being performed?
    Client-side, through the platform or with a dedicated
    hardware?
    Resilience
    How do you plan to deal with systems that suddenly
    produce errors, that are unavailable or with high
    latencies? How do you plan to avoid cascading error
    scenarios?

    View full-size slide

  35. REST is usually used for orchestrated
    Microservices
    Credit

    Application
    Scoring
    Credit
    Decision
    Customer
    Create Customer
    Perform
    Scoring
    Decide on
    credit application

    View full-size slide

  36. Messaging
    Upstream System
    Microservices send messages to
    topics and queues. Asynchronous
    communication
    A messaging system can guarantee
    delivery, store messages and
    acknowledge delivery
    Other Microservices can consume
    the messages from topics or queues
    and are decoupled through the
    messaging system
    publishes
    consumes
    Downstream System

    View full-size slide

  37. Let’s
    revisit the
    Challenges
    Service
    Discovery
    There is no need for service discovery for
    messaging as the providers and consumers only
    need to know the messaging system.
    Load
    Balancing
    Load balancing does not have to be implemented
    or dealt with explicitly. All you need to do is to
    scale the number of instances of consuming
    microservices.
    Resilience
    Messaging systems can guarantee delivery of
    messages. Due to the asynchronous nature of
    messaging the main risk you have to deal with is
    increased latency in the case of errors or
    downtimes.

    View full-size slide

  38. This classic book is still relevant
    for asynchronous
    Microservices that rely on
    Messaging
    Gregor Hohpe, Bobby Woolf -
    Enterprise Integration Patterns
    http://www.eaipatterns.com

    View full-size slide

  39. Messaging leads us to choreographed
    Microservices
    Credit

    Application
    Scoring
    Credit
    Decision
    Customer
    Credit

    Application

    Submitted
    Event

    View full-size slide

  40. Credit

    Application

    Submitted
    Event
    We can use Domain Events
    for the communication
    between Microservices.
    This leads us to
    Event-driven Microservices

    View full-size slide

  41. ! Domain Events are
    something that happened
    that Domain Experts care
    about

    View full-size slide

  42. !
    Model information about
    activity in the domain as a
    series of discrete events.

    View full-size slide

  43. Events are easy to grasp
    Events have a simple
    semantic
    Events can be placed 

    on a timeline

    View full-size slide

  44. An event is something 

    that happened in the past
    t
    now
    Event
    Event
    Event
    Event
    Event

    View full-size slide

  45. ShipmentDeliveredEvent

    CustomerVerifiedEvent
    CartCheckedOutEvent
    CreateCustomerEvent

    WillSaveItemEvent

    DoStuffEvent

    View full-size slide

  46. ShipmentDeliveredEvent

    CustomerVerifiedEvent
    CartCheckedOutEvent
    CreateCustomerEvent

    WillSaveItemEvent

    DoStuffEvent

    View full-size slide

  47. Triggers of Events
    Documents
    Time
    Applications
    User Actions
    Other Events

    View full-size slide

  48. Options for Event Payload
    Options
    Full Payload The event carries complete Entitiy-Graphs or
    Aggregates
    Mix
    The event contains data that is usually of interest to
    many other contexts. For special purposes there is also
    a URL to a RESTful HTTP Ressource
    Empty The event is empty or contains only minimal data and
    is being used to trigger pulling from a feed (eg. Atom)
    REST URL The event only carries a URL to a RESTful HTTP
    Ressource

    View full-size slide

  49. CustomerCreatedEvent
    {
    "eventId": "4567854",
    "eventTimetamp": „12398989343",
    "eventType": "CustomerCreatedEvent",
    "customerName": "Michael",
    "customerLastName": "Plöd",
    "customerNumber": "34ed2345",
    "address" :
    {
    "street": "Kreuzstr. 16",
    "postCode": "80331",
    "city": "München"
    }
    }
    Full Payload
    Events contain full object
    graphs
    Consumers do have all the
    data they need
    „Invitation“ to a high degree of

    coupling between event and

    consumer

    View full-size slide

  50. CustomerCreatedEvent
    {
    "eventId": "4567854",
    "eventTimetamp": „12398989343",
    "eventType": "CustomerCreatedEvent",
    "url": "http://123.03.24.23/event/2"
    }
    REST URL
    Events only contain a URL to a
    REST resource for the event
    data
    If consumers need the data
    they
    can obtain it but don’t have to
    Synchronous communication,
    but no service discovery

    View full-size slide

  51. CustomerCreatedEvent
    {
    "eventId": "4567854",
    "eventTimetamp": „12398989343",
    "eventType": "CustomerCreatedEvent",
    }
    Empty
    Events contain no data at all
    Consumers would usually 

    consume an (ATOM) Feed
    Consumers need to know the 

    Source of the Feed

    View full-size slide

  52. CustomerCreatedEvent
    {
    "eventId": "4567854",
    "eventTimetamp": „12398989343",
    "eventType": "CustomerCreatedEvent",
    "customerLastName": "Plöd",
    "customerNumber": "34ed2345",
    "url": "http://123.03.24.23/event/2"

    }
    MIX
    Events contain some data
    Additional data can be obtained 

    by calling as REST Resource
    Good compromise in many 

    occasions

    View full-size slide

  53. Case Study
    https://github.com/mploed/event-driven-spring-boot

    View full-size slide

  54. Credit

    Application

    Number

    Generated
    Application

    Process
    Credit Decision
    Credit Application
    Credit

    Details

    Entered
    Financial

    Situation

    Entered

    View full-size slide

  55. Credit

    Application

    Entered
    Credit
    Application
    Customer
    Scoring
    Customer
    Created

    View full-size slide

  56. Scoring
    Positive
    Scoring
    Scoring
    Negative
    Credit
    Decision
    Application
    Declined
    Application
    Approved

    View full-size slide

  57. One more thing…

    View full-size slide

  58. REST + Events

    View full-size slide

  59. REST + Events

    =

    Feeds

    View full-size slide

  60. Application
    Approved
    Event
    Credit
    Decision
    The Credit Decision
    microservices publishes the
    Application Approved Events
    as an Atom Feed via HTTP
    Contract Offers
    The Contract Offers
    microservices polls the HTTP
    based Atom Feed at a
    predefined rate

    View full-size slide

  61. Characteristics of Feeds
    Feeds
    HTTP
    You can leverage the full featureset of HTTP for the feeds
    on the client and the server side: ETags, Last Modified
    Headers, pagination, links or conditional requests.
    Hybrid Cloud
    Feeds come in handy when dealing with a hybrid cloud
    scenario because HTTP is always the easiest way to
    communicate between on premise and public networks.
    Infrastructure
    You won’t need an additional infrastructure for
    implementing feeds. All you need is HTTP, no message
    brokers.
    REST
    By using feeds you can mitigate some challenges that you
    face when going for a full synchronous scenario. You still
    need service discovery but resilience is easier to handle

    View full-size slide

  62. In order to offer
    Feeds we must?
    Persist our
    Domain Events!

    View full-size slide

  63. Event Sourcing is an
    architectural pattern in
    which the state of the
    application is being
    determined by a
    sequence of events

    View full-size slide

  64. Using the ideas
    behind CQRS
    we can derive
    views that are
    optimized for
    queries from
    the event store

    View full-size slide

  65. Integration is not just technical
    Teams
    In order to integrate, teams often need to communicate
    with each other which may lead to politics and
    governance issues.
    Technology
    REST is not the only option for you
    Quality

    Criteria
    What are your requirements with regards to
    consistency, performance, scalability and robustness?
    Coupling
    How do you plan to achieve the mantra „how cohesion,
    low coupling“ for your microservices?

    View full-size slide

  66. Technical Options
    ➡ RESTful Resources
    ➡ Messaging
    ➡ Domain Events
    ➡ Feeds
    General Categories
    ➡ Orchestration
    ➡ Choreography
    Technical Aspects
    Microservice
    Communication

    View full-size slide

  67. THANK YOU
    Michael Plöd

    INNOQ

    @bitboss
    Kraków, 9-11 May 2018

    View full-size slide