Communication Strategies for Microservices

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

What has a better structure and looks cleaner?

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

Sure, and we might end up with this

Slide 6

Slide 6 text

You see

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

I can’t stress this enough

Slide 9

Slide 9 text

Distributed Systems are Difﬁcult Systems

Slide 10

Slide 10 text

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?

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

Example - You at GeeCon Reservations Event  Management Badges GeeCon  Visitor Name Payment Details Address Company Session Registrations Lunch Preferences Name Job Description Twitter Handle

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

Upstream / Downstream Credit Agency Scoring Call Flow Model Flow Focus of   Context Map Upstream System Downstream System

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

No content

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

Choreography Credit  Application Scoring Credit Decision Customer Credit  Application  Submitted Event Building Microservices by Sam Newman, O'Reilly

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

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.

Slide 28

Slide 28 text

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?

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

Slide 37

Slide 37 text

REST is usually used for orchestrated Microservices Credit  Application Scoring Credit Decision Customer Create Customer Perform Scoring Decide on credit application

Slide 38

Slide 38 text

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

Slide 39

Slide 39 text

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.

Slide 40

Slide 40 text

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

Slide 41

Slide 41 text

Messaging leads us to choreographed Microservices Credit  Application Scoring Credit Decision Customer Credit  Application  Submitted Event

Slide 42

Slide 42 text

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

Slide 43

Slide 43 text

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

Slide 44

Slide 44 text

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

Slide 45

Slide 45 text

Events are easy to grasp Events have a simple semantic Events can be placed   on a timeline

Slide 46

Slide 46 text

An event is something   that happened in the past t now Event Event Event Event Event

Slide 47

Slide 47 text

ShipmentDeliveredEvent  CustomerVeriﬁedEvent CartCheckedOutEvent CreateCustomerEvent  WillSaveItemEvent  DoStuffEvent

Slide 48

Slide 48 text

ShipmentDeliveredEvent  CustomerVeriﬁedEvent CartCheckedOutEvent CreateCustomerEvent  WillSaveItemEvent  DoStuffEvent

Slide 49

Slide 49 text

Triggers of Events Documents Time Applications User Actions Other Events

Slide 50

Slide 50 text

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

Slide 51

Slide 51 text

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

Slide 52

Slide 52 text

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

Slide 53

Slide 53 text

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

Slide 54

Slide 54 text

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

Slide 55

Slide 55 text

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

Slide 56

Slide 56 text

Credit  Application  Number  Generated Application  Process Credit Decision Credit Application Credit  Details  Entered Financial  Situation  Entered

Slide 57

Slide 57 text

Credit  Application  Entered Credit Application Customer Scoring Customer Created

Slide 58

Slide 58 text

Scoring Positive Scoring Scoring Negative Credit Decision Application Declined Application Approved

Slide 59

Slide 59 text

One more thing…

Slide 60

Slide 60 text

REST + Events

Slide 61

Slide 61 text

REST + Events  =  Feeds

Slide 62

Slide 62 text

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 predeﬁned rate

Slide 63

Slide 63 text

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 Modiﬁed 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

Slide 64

Slide 64 text

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

Slide 65

Slide 65 text

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

Slide 66

Slide 66 text

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

Slide 67

Slide 67 text

Wrap up

Slide 68

Slide 68 text

Slide 69

Slide 69 text

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

Slide 70

Slide 70 text

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