Event-driven Microservices with the Spring Ecosystem

Michael Plöd, @bitbossAll photos © Michael Plöd

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

Print Service

Post Service

Print Service

Post Service

Print Service

Post Service

Sure, and we might end up with this

!With the adoption of

microservices a former implicitly hidden complexity suddenly becomes explicitly visible and the challenges for

communication grow exponentially

I can’t stress this enough

Technical Options

➡ RESTful Resources ➡ Messaging ➡ Domain Events ➡ Feeds

General Categories

➡ Orchestration ➡ Choreography

Microservice Communication

Orchestration vs

Choreography

Building Microservices by Sam Newman, O'Reilly

Event Stream

ChoreographyOrchestration

Orchestration

Credit Application

Scoring Credit DecisionCustomer

Create CustomerPerformScoring

Decide on credit application

Building Microservices by Sam Newman, O'Reilly

RESTful HTTP is usually used for orchestrated Microservices

Credit Application

Scoring Credit DecisionCustomer

Create CustomerPerformScoring

Decide on credit application

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?

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

Choreography

Credit Application

Scoring Credit DecisionCustomer

CreditApplicationSubmitted

Event

Building Microservices by Sam Newman, O'Reilly

Choreographed Microservices lead us towards Messaging

Credit Application

Scoring Credit DecisionCustomer

CreditApplicationSubmitted

Event

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

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.

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

This classic book is still relevant for asynchronous

Microservices that rely on Messaging

Gregor Hohpe, Bobby Woolf - Enterprise Integration Patterns

http://www.eaipatterns.com

Credit ApplicationSubmitted

Event

We can use Domain Events for the communication between Microservices.

This leads us to Event-driven Microservices

! Domain Events are something that happened that Domain Experts care

about

!Model information about activity in the domain as a

series of discrete events.

Events are easy to grasp

Events have a simple semantic

Events can be placed on a timeline

An event is something that happened in the past

t

now

EventEventEventEventEvent

ShipmentDeliveredEvent

CustomerVerifiedEvent

CartCheckedOutEvent

CreateCustomerEvent

WillSaveItemEvent

DoStuffEvent

Triggers of Events

Documents

Time

Applications

User Actions

Other Events

Options for Event Payload

Options

Full Payload The event carries complete Entitiy-Graphs or Aggregates

MixThe 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

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 andconsumer

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

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

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

Case Study

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

CreditApplication

NumberGenerated

Application Process

Credit Decision

Credit Application

Credit DetailsEntered

Financial Situation Entered

CreditApplication

Entered

Credit Application

Customer

Scoring

Customer Created

Scoring Positive

Scoring

Scoring Negative

Credit Decision

Application Declined

Application Approved

One more thing…

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

application

REST + Events

REST + Events =

Feeds

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

Characteristics of Feeds

Feeds

HTTPYou 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 CloudFeeds 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.

InfrastructureYou won’t need an additional infrastructure for implementing feeds. All you need is HTTP, no message brokers.

RESTBy 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

In order to offer Feeds we must?

Persist our Domain Events!

Event Sourcing is an architectural pattern in

which the state of the application is being

determined by a sequence of events

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

Event-driven Microservices with the Spring Ecosystem

Michael Plöd, @bitbossAll photos © Michael Plöd