Legacy Systeme modernisieren mit Microservices, Hystrix und RxJava

präsentiert auf der OOP in München am 4. Februar 2016

Als Software-Entwickler ist man nur sehr selten in der Situation, ein völlig neues System auf der Basis neuester Technologien entwickeln zu dürfen. Oft sollen bestehende Systeme nur um viele kleinere Features erweitert werden.
Die Renovierung der grundlegenden Systemarchitektur und die Einführung neuer Programmierparadigmen sind in diesem Umfeld schwierig. Umso wichtiger ist es, dass man die Modernisierung von Altsystemen zu einem fortlaufenden Bestandteil auch des Feature-getriebenen Entwicklungsprozesses macht.
In diesem Vortrag möchten wir zeigen, wie auch größere, monolithische Altsysteme mithilfe der offenen Netflix-Bibliotheken schrittweise in Richtung einer Microservice-Achitektur weiterentwickelt werden können. Hystrix kann dabei einen wertvollen Beitrag zur Gesamtstabilität des entstehenden verteilten Systems leisten.
Der Einsatz von RxJava eröffnet eine gute Möglichkeit, den Anteil von asynchronen Prozessen innerhalb der Legacy-Architektur zu erhöhen. Der Vortrag wird anhand von Beispielen demonstrieren, wie der hier angedeutete Modernisierungsprozess umgesetzt werden kann.

Transcript

1. Modernizing Systems with Microservices, Hystrix and RxJava Holger Kraus, Arne Landwehr OOP, München, Feb 4, 2016
2. A typical System
3. The context
4. Current problems > Maintenance is difficult > New features need a lot of time > Very unstable > Outdated technology > Doesn’t scale + frustrated developers :(
5. Current problems > Maintenance is difficult > New features need a lot of time > Very unstable > Outdated technology > Doesn’t scale Microservices FTW ! not yet …
6. Stabilize first!
7. External dependencies here! here! and also here!
8. Cascading Failures https://www.flickr.com/photos/benstassen/2991003141/
9. Stability patterns > Timeouts > Circuit Breaker > Bulkhead … Fail Fast, Steady State, Handshaking, Test Harness, Decoupling Middleware
10. Timeout https://www.flickr.com/photos/55293400@N07/15564061004
11. Bulkheads https://www.flickr.com/photos/10413717@N08/6935206524
12. Ships http://de.wikipedia.org/wiki/RMS_Titanic#/media/File:Titanic_Structure_de.svg
13. Bulkheads and IT > Thread pools > Database connection pools > Instances > Server > Data center
14. Circuit Breaker https://www.flickr.com/photos/leafbug/409950515/
15. Circuit Breaker http://martinfowler.com/bliki/CircuitBreaker.html
16. Hystrix > Library from Netflix > Resilience Library > Command Pattern > Metrics > Dashboard
17. Use Cases let’s pick this one!
18. Search Products 2. find external products 1. search products 3. find internal products 4. return internal + external products
19. Search Products
20. Call without Hystrix cascading failures incoming!
21. Simple Command
22. Execute it!
23. Execute it asynchronously
24. Static Fallback
25. In case Merchant 2 is down something is missing here
26. Stale Caches
27. Nested Commands
28. Configuration > Netflix archaius used internally > Configuration at runtime is possible > allows a faster PDCA cycle and could prevent server restarts > overall highly configurable and well documented
29. Command Groups > every Command has a name > you can combine commands to groups > groups aggregate commands for metrics, dashboards etc. > per default a group determines the thread pool
30. Thread Pool sizing requests per second at peak when healthy × 99th percentile latency in seconds + some breathing room Little's law
31. The stabilized system
32. Demo
33. More advanced features > Request Collapser > Request Cache > Semaphore
34. Let’s recap > Stabilize first to enable further distribution > Hystrix is easy to integrate in existing systems > it includes Bulkhead, Timeouts and Circuit Breakers out of the box > Application monitoring as a side benefit
35. And now?
36. Current Problems > Maintenance is difficult > New features need a lot of time > Very unstable => enables further distribution > Outdated technology > Doesn’t scale
37. Microservices! but how to get started ????
38. Architectural Decisions https://speakerdeck.com/aheusingfeld/microservices-meet-real-world-projects-lessons-learned
39. Domain Architecture which boxes do we need ? let the monolith guide you!
40. Domain: Search
41. Cut you domain „MECE“ * Riccardo Mangiaracina, The eCommerce Customer Journey: A Model to Assess and , Compare the User Experience of the eCommerce Websites, Journal of Internet Banking and Commerce mutually exclusive and collectively exhaustive
42. Domains and Teams Site Landing Product Discovery Product Presentation Cart Management Checkout Infrastructure PO QA UI Backend Infrastructure PO QA UI Backend Infrastructure PO QA UI Backend Infrastructure PO QA UI Backend Infrastructure PO QA UI Backend
43. Macro Architecture > Integration > Deployment > Formats > Protocols > Reduce Choices what’s the same for all boxes ? = API = Docker = JSON = HTTP + AMQP = Java, Go Monozon: pick your own!
44. Micro Architecture Search Service
45. Migration Path ? pick one [big bang, strangler, wonder]
46. Big Bang a.k.a REVOLUTION only call old monolith meanwhile build new systems:
47. Big Bang only call new shiny systems delete this one!
48. Strangler a.k.a EVOLUTION your monolith a.k.a „Big Ball of Mud“
49. Strangler give your monolith internal structure and define interfaces … if possible.
50. Strangler Extract your new service and redirect calls to it
51. Strangler Once unused strangle the old code
52. Merchant Product Invoice Payment … Order Monozon … … Use Case Search product Presentation Use Case Add To Cart Presentation Use Case Search Product Presentation Use Case Order Tracking Presentation Use Case … Presentation Use Case … Presentation Use Case XYZ Presentation Inventory How much to cut out? intertwined presentation and use case logic intertwined business entity and persistence logic
53. Reuse Business Entities? Merchant Product Inventory Inventory Payment … Order Monozon … … Use Case Search product Presentation Use Case Add To Cart Presentation Use Case Search Product Presentation Use Case Order Tracking Presentation Use Case … Presentation Use Case … Presentation Use Case XYZ Presentation Persistence InventoryService CRUD API Validation
54. Beware of multiple Clients Monozon Web Web-UI Product search Checkout Order Tracking … Monozon eReader eReader-UI Product search Checkout Order Tracking … Monozon iOS App iOS-UI Product search Checkout Order Tracking … Monozon Andoid App Android-UI Product search Checkout Order Tracking … InventorySerice JSON CRUD API OrderService JSON CRUD API ProductService JSON CRUD API PaymentService JSON CRUD API CustomerService JSON CRUD API isn’t that redundant?
55. Downsides > CRUD APIs must match all needs > only Use Case agnostic validation is possible > every Clients must rebuild the Use Cases with by aggregating a lot of calls > redundant and not reusable logic in all Clients
56. Aim for a higher cut that also influences your integration strategy
57. API Integration Merchant Product Inventory Inventory Payment … Order Monozon … … Use Case Search product Presentation Use Case Add To Cart Presentation Use Case Search Product Presentation Use Case Order Tracking Presentation Use Case … Presentation Use Case … Presentation Use Case XYZ Presentation Persistence Use Case REST API Business Logic Inventory Service
58. Frontend Integration Merchant Product Inventory Inventory Payment … Order Monozon … … Use Case Search product Presentation Use Case Add To Cart Presentation Use Case Search Product Presentation Use Case Order Tracking Presentation Use Case … Presentation Use Case … Presentation Use Case XYZ Presentation Persistence UI Business Logic Inventory Service
59. Frontend Integration Simple hyperlinks can be used to navigate between systems. System 1 System 2
60. Frontend Integration System 1 System 2 Hyperlinks can also support the 
 dynamic inclusion of content that is served by another application into the web interface of a self-contained system.
61. http://scs-architecture.org/
62. API Integration Review Pro: > simple „classic“ way > no need to restructure backend and frontend teams > could support wide variety of clients Con: > harder to extract complete business logic > no real product teams > cut between frontend and backend
63. Frontend Integration Review Pro: > nice way to extract complete logic > systems are highly autonomous > real product teams possible Con: > not the stuff most devs are used to > callbacks could be ugly > reorganization of frontend and backend teams could be needed
64. Let’s recap 1. stabilize your monolith and enable distribution 2. establish and communicate your macro architecture 3. use you domain architecture to extract new services 4. prefer to „strangle“ over „big bangs“ 5. always extract all business logic (even if it’s harder) 6. have a vision
65. Assume we picked „api integration“ as a strategy
66. Time to connect boxes
67. What has to be done? > Retrieve internal products that match 
 search criteria > Retrieve external products from merchants 
 that match search criteria
68. Internal Product Search > Retrieve product ids from Search > Retrieve product details from Product > Retrieve number of matching products in stock from Inventory > Combine all data into one format 
 called SearchResult
69. External Product Search > Retrieve matching products from different merchants in different data formats > Combine all data into one format
 called SearchResult
70. Sequential vs. Parallel
71. Future<SearchResult>
72. Future<Future<SearchResult>
73. Internal products with Futures blocking! blocking!
74. External products with Futures blocking!
75. Combine products with Futures blocking!
76. Time for RxJava > Reactive Extensions for the JVM > Asynchronous streams > Elements of > Observable pattern > Iterator pattern > Functional programming
77. The Observable part > An Observable emits items > An Subscriber consumes these items
78. https://speakerdeck.com/benjchristensen/functional-reactive-programming-with-rxjava-javaone-2013 The Interator part
79. The functional part > Combining: merge(), zip(), join(), … > Filtering: filter(), skip(), distinct(), … > Aggregating: reduce(), max(), sum(), … > Transformation: map(), flatMap(), … > Conditional: contains(), amb(), all(), …
80. Everything is a stream!
81. RxJava in one picture https://speakerdeck.com/benjchristensen/functional-reactive-programming-with-rxjava-javaone-2013
82. Creating Observables
83. Transforming with map http://reactivex.io/RxJava/javadoc/rx/Observable.html
84. map in action
85. Combining with merge http://reactivex.io/RxJava/javadoc/rx/Observable.html
86. merge in action
87. Combining streams with zip http://reactivex.io/RxJava/javadoc/rx/Observable.html
88. zip in action
89. Collecting details with flatMap http://reactivex.io/RxJava/javadoc/rx/Observable.html
90. flatMap in action
91. Why not map?
92. Concurrency > Observers run in the thread that runs the Observable
93. Easier with Hystrix
94. Converting into a stream
95. Synchronous result
96. Asynchronous result
97. Subscriber
98. Error handling > onError works like onCompleted, just with an error ;) > UncheckedExceptions end up in OnError > CheckedException have to be catched and rethrown as RuntimeExceptions > Rx provides helpers to throw them
99. Reasons for RxJava > Can be used with Java 6 and later versions > Already part of Hystrix > Lots of operators
100. Alternatives > ListenableFuture (Google Guava) > Reactive Streams (Akka-Streams, Reactor, Vert.x, etc.) > CompletableFuture (Java 8) > Flow (Java 9)
101. Summary > Use Hystrix to stabilize your system! > Use RxJava to increase the amount of parallel processes in an easy way! > Introduce Microservices to get control over your system again! > Have fun :)
102. Thank you!