REST vs. Messaging For Microservices

Slide 1

Slide 1 text

REST VS. Messaging Integration Approaches for Microservices Eberhard Wolff / ewolff / olivergierke Oliver Gierke

Slide 2

Slide 2 text

Microservices 2 ECommerce Order Customer Delivery Order Customer Delivery Package WAR

Slide 3

Slide 3 text

Integration 3 UI Logic Data Links Modular UI REST Messaging Replication No Common  Schema!

Slide 4

Slide 4 text

Overview 4

Slide 5

Slide 5 text

REST • Architectural style • Constraints in architecture result in traits of the system • Identifiable resources, uniform interface, representations, hypermedia • Synchronous by default 5 ? Microservice Microservice

Slide 6

Slide 6 text

REST • Service discovery • DNS or registry & hypermedia • Load balancing • Dedicated infrastructure • So!ware load-balancer (Ribbon) 6 ? Microservice Microservice

Slide 7

Slide 7 text

Messaging • Microservices send message • Asynchronously 7 Microservice Microservice

Slide 8

Slide 8 text

Load Balancing • Can have any numbers of instances of a receiver • Load Balancing very easy 8 Microservice Microservice Microservice Microservice

Slide 9

Slide 9 text

Service Discovery • Microservices send messages to queues / topics • Receiver(s) read messages • Decoupled by queues & messages • No need for service discovery 9 Microservice Microservice Microservice Microservice

Slide 10

Slide 10 text

Fire & Forget 10

Slide 11

Slide 11 text

Example 11 Order Payment Credit card booking 200€

Slide 12

Slide 12 text

REST • F&F doesn’t fit naturally • Which HTTP method to use? • Requests to create side eﬀects • DELETE, PUT, POST 12 ? Microservice Microservice

Slide 13

Slide 13 text

Safety / Idempotency 13 HTTP Method Safe Itempotent GET PUT DELETE POST PATCH

Slide 14

Slide 14 text

REST: Failure • Remote system unavailable • Can’t easily retry because of non-itempotency • Status codes to communicating semantic problems 14 ? Microservice Microservice

Slide 15

Slide 15 text

Messaging • Hand message over to messaging system • Messaging system  guarantees delivery • Stores message • Acknowledgement • Might have duplicated messages 15 Microservice Microservice

Slide 16

Slide 16 text

Messaging: Failures • Message doesn’t make it into the message broker • e.g. Timeout / TCP problem • Retry • Rely on re-transmission of incoming message 16 Microservice Microservice

Slide 17

Slide 17 text

Request & Reply 17

Slide 18

Slide 18 text

Example 18 Order Payment Validate credit card # OK / not OK

Slide 19

Slide 19 text

REST • Natural model • GET request • Support for caching built in • ETags, Last-Modified, conditional GET / PUT • Still needs care • Timeouts, resilience 19 ? Microservice Microservice

Slide 20

Slide 20 text

Messaging • Send request • Expect response • Correlation • …or temporary queue • Asynchronous by design 20 Microservice Microservice

Slide 21

Slide 21 text

Resilience • Messaging can guarantee delivery • Failure just increases latency • System must deal with latency anyway 21 Microservice Microservice

Slide 22

Slide 22 text

Events 22

Slide 23

Slide 23 text

Event Driven Architecture • Order sends events • Decoupled: no call but events • Receiver handle events as they please 23 Order New Order Event Payment: Books credit card Delivery:  Ship products

Slide 24

Slide 24 text

Event Driven Architecture • System are built around publishing domain events • Multiple event listeners • Event listener decides what to do • Can easily add new event listener with additional business logic • Challenges • Delivery hard to guarantee • What about old events? 24

Slide 25

Slide 25 text

Events + REST = Feed • System stores domain events and publishes feed (e.g. Atom) • Strong consistency within the service • No additional infrastructure required • Getting closer to Event Sourcing • Clients subscribe to feed • Clients in charge of polling frequency • Server side optimizations: caching, ETags, pagination, links • Client side optimizations: conditional requests 25

Slide 26

Slide 26 text

Messaging • Publish / Subscribe e.g. JMS Topics • History of events limited • Guaranteed delivery somewhat harder 26

Slide 27

Slide 27 text

More Decoupling • Enterprise Integration Patterns (Hohpe, Woolf) • www.eaipatterns.com • Contains patterns like Router, Translator or Adapter • Create flexible messaging architectures 27

Slide 28

Slide 28 text

Code 28 @Inject OrderRepository repository; @Transactional public void order(Order order) { repository.save(order.deliver()); doCreditCardBooking(order.getCcNumber()); }

Slide 29

Slide 29 text

Transactions 29

Slide 30

Slide 30 text

Messaging & Transactions (Commit) • Database commit • Incoming messages acknowledged • Commit success: outgoing messages sent • Outgoing messages hopefully handled successfully. • Inconsistencies: Outgoing messages not yet processed 30 Microservice

Slide 31

Slide 31 text

Microservice Messaging & Transactions (Rollback) • Database rollback • Outgoing message not sent • Incoming message retransmitted 31

Slide 32

Slide 32 text

REST & Transactions • No implicit infrastructure support • But can be built manually 32

Slide 33

Slide 33 text

REST & Transactions 33 @Inject OrderRepository repository; @Inject ApplicationEventPublisher publisher; @Transactional public void order(Order order) { repository.save(order.deliver()); publisher.publish(new OrderDeliveredEvent(order)); } @TransactionalEventListener(phase = TransactionPhase.AFTER_COMMIT) public void onOrder(Order order) { doCreditCardBooking(order.getCcNumber()); }

Slide 34

Slide 34 text

Evolvability 34

Slide 35

Slide 35 text

Evolvability • Core aspect of Microservices: independent deployability • Means: decoupling • Change in one system must not break downstream systems 35

Slide 36

Slide 36 text

REST • Core concepts built into the protocol • Representations • Content negotiation • Media types • Hypermedia • Discoverability 36

Slide 37

Slide 37 text

Messaging • Data format: Your choice • i.e. easy to evolve if changes backwards-compatible • But: no support for content negotation 37

Slide 38

Slide 38 text

Summary 38 REST Messaging Communication style synchronous asynchronous Service Discovery DNS, Service Registry  Resource Discovery Message Broker  Queues / Topics Strengths Content negotiation, Hypermedia More control over direct interaction Messages in Re-submission of messages