REST vs. Messaging For Microservices

Presentation from WJAX 2015 with Oliver Gierke. Compares REST and Messaging as an integration approach for Microservices.

Transcript

1. REST VS. Messaging Integration Approaches for Microservices Eberhard Wolff / ewolff / olivergierke Oliver Gierke
2. Microservices 2 ECommerce Order Customer Delivery Order Customer Delivery Package WAR
3. Integration 3 UI Logic Data Links Modular UI REST Messaging Replication No Common
 Schema!
4. Overview 4
5. REST • Architectural style • Constraints in architecture result in traits of the system • Identifiable resources, uniform interface, representations, hypermedia • Synchronous by default 5 ? Microservice Microservice
6. REST • Service discovery • DNS or registry & hypermedia • Load balancing • Dedicated infrastructure • So!ware load-balancer (Ribbon) 6 ? Microservice Microservice
7. Messaging • Microservices send message • Asynchronously 7 Microservice Microservice
8. Load Balancing • Can have any numbers of instances of a receiver • Load Balancing very easy 8 Microservice Microservice Microservice Microservice
9. 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
10. Fire & Forget 10
11. Example 11 Order Payment Credit card booking 200€
12. REST • F&F doesn’t fit naturally • Which HTTP method to use? • Requests to create side effects • DELETE, PUT, POST 12 ? Microservice Microservice
13. Safety / Idempotency 13 HTTP Method Safe Itempotent GET PUT DELETE POST PATCH
14. REST: Failure • Remote system unavailable • Can’t easily retry because of non-itempotency • Status codes to communicating semantic problems 14 ? Microservice Microservice
15. Messaging • Hand message over to messaging system • Messaging system
 guarantees delivery • Stores message • Acknowledgement • Might have duplicated messages 15 Microservice Microservice
16. 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
17. Request & Reply 17
18. Example 18 Order Payment Validate credit card # OK / not OK
19. REST • Natural model • GET request • Support for caching built in • ETags, Last-Modified, conditional GET / PUT • Still needs care • Timeouts, resilience 19 ? Microservice Microservice
20. Messaging • Send request • Expect response • Correlation • …or temporary queue • Asynchronous by design 20 Microservice Microservice
21. Resilience • Messaging can guarantee delivery • Failure just increases latency • System must deal with latency anyway 21 Microservice Microservice
22. Events 22
23. 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
24. 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
25. 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
26. Messaging • Publish / Subscribe e.g. JMS Topics • History of events limited • Guaranteed delivery somewhat harder 26
27. More Decoupling • Enterprise Integration Patterns (Hohpe, Woolf) • www.eaipatterns.com • Contains patterns like Router, Translator or Adapter • Create flexible messaging architectures 27
28. Code 28 @Inject OrderRepository repository; @Transactional public void order(Order order) { repository.save(order.deliver()); doCreditCardBooking(order.getCcNumber()); }
29. Transactions 29
30. 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
31. Microservice Messaging & Transactions (Rollback) • Database rollback • Outgoing message not sent • Incoming message retransmitted 31
32. REST & Transactions • No implicit infrastructure support • But can be built manually 32
33. 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()); }
34. Evolvability 34
35. Evolvability • Core aspect of Microservices: independent deployability • Means: decoupling • Change in one system must not break downstream systems 35
36. REST • Core concepts built into the protocol • Representations • Content negotiation • Media types • Hypermedia • Discoverability 36
37. Messaging • Data format: Your choice • i.e. easy to evolve if changes backwards-compatible • But: no support for content negotation 37
38. 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
39. Your next project: Messaging or REST? 39
40. You’ll probably use both :-) 40