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.

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
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