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.

21a532a137b506128914478ac521fc8b?s=128

Michael Plöd

May 11, 2018
Tweet

Transcript

  1. Communication Strategies 
 for
 Microservices Michael Plöd - INNOQ -

    @bitboss Kraków, 9-11 May 2018
  2. What has a better structure and looks cleaner?

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

    of hell
  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
  5. Sure, and we might end up with this

  6. You see

  7. ! With the adoption of microservices a former implicitly hidden

    complexity suddenly becomes explicitly visible and the challenges for communication grow exponentially
  8. I can’t stress this enough

  9. Distributed Systems are Difficult Systems

  10. 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?
  11. 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
  12. 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
  13. Example - You at GeeCon Reservations Event
 Management Badges GeeCon


    Visitor Name Payment Details Address Company Session Registrations Lunch Preferences Name Job Description Twitter Handle
  14. 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
  15. Upstream / Downstream Credit Agency Scoring Call Flow Model Flow

    Focus of 
 Context Map Upstream System Downstream System
  16. 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
  17. 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
  18. None
  19. !Perform an early assessment of the real quality criteria that

    are relevant for your application
  20. 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?
  21. Technical Options ➡ RESTful Resources ➡ Messaging ➡ Domain Events

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

    ➡ Feeds General Categories ➡ Orchestration ➡ Choreography Technical Aspects Microservice Communication
  23. Orchestration Credit
 Application Scoring Credit Decision Customer Create Customer Perform

    Scoring Decide on credit application Building Microservices by Sam Newman, O'Reilly
  24. Choreography Credit
 Application Scoring Credit Decision Customer Credit
 Application
 Submitted

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

    Stream Choreography Orchestration
  26. Technical Options ➡ RESTful Resources ➡ Messaging ➡ Domain Events

    ➡ Feeds General Categories ➡ Orchestration ➡ Choreography Technical Aspects Microservice Communication
  27. 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.
  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?
  29. 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
  30. 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?
  31. 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
  32. 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
  33. 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
  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?
  35. 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
  36. 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?
  37. REST is usually used for orchestrated Microservices Credit
 Application Scoring

    Credit Decision Customer Create Customer Perform Scoring Decide on credit application
  38. 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
  39. 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.
  40. This classic book is still relevant for asynchronous Microservices that

    rely on Messaging Gregor Hohpe, Bobby Woolf - Enterprise Integration Patterns http://www.eaipatterns.com
  41. Messaging leads us to choreographed Microservices Credit
 Application Scoring Credit

    Decision Customer Credit
 Application
 Submitted Event
  42. Credit
 Application
 Submitted Event We can use Domain Events for

    the communication between Microservices. This leads us to Event-driven Microservices
  43. ! Domain Events are something that happened that Domain Experts

    care about
  44. ! Model information about activity in the domain as a

    series of discrete events.
  45. Events are easy to grasp Events have a simple semantic

    Events can be placed 
 on a timeline
  46. An event is something 
 that happened in the past

    t now Event Event Event Event Event
  47. ShipmentDeliveredEvent
 CustomerVerifiedEvent CartCheckedOutEvent CreateCustomerEvent
 WillSaveItemEvent
 DoStuffEvent

  48. ShipmentDeliveredEvent
 CustomerVerifiedEvent CartCheckedOutEvent CreateCustomerEvent
 WillSaveItemEvent
 DoStuffEvent

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

  50. 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
  51. 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
  52. 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
  53. 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
  54. 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
  55. Case Study https://github.com/mploed/event-driven-spring-boot

  56. Credit
 Application
 Number
 Generated Application
 Process Credit Decision Credit Application

    Credit
 Details
 Entered Financial
 Situation
 Entered
  57. Credit
 Application
 Entered Credit Application Customer Scoring Customer Created

  58. Scoring Positive Scoring Scoring Negative Credit Decision Application Declined Application

    Approved
  59. One more thing…

  60. REST + Events

  61. REST + Events
 =
 Feeds

  62. 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
  63. 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
  64. In order to offer Feeds we must? Persist our Domain

    Events!
  65. Event Sourcing is an architectural pattern in which the state

    of the application is being determined by a sequence of events
  66. Using the ideas behind CQRS we can derive views that

    are optimized for queries from the event store
  67. Wrap up

  68. 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?
  69. Technical Options ➡ RESTful Resources ➡ Messaging ➡ Domain Events

    ➡ Feeds General Categories ➡ Orchestration ➡ Choreography Technical Aspects Microservice Communication
  70. THANK YOU Michael Plöd
 INNOQ
 @bitboss Kraków, 9-11 May 2018