Vom Monolithen zu Self-Contained-Systems

Praxisbericht über das schrittweise Herauslösen eines Self-Contained-Systems aus einem gewachsenen Monolithen.

Transcript

1. @DanielRosowski 1 Vom Monolithen zu 
 Self-Contained-Systems: Ein Praxisbericht Daniel Rosowski The Architecture Gathering 2018 10.10.2018, München
2. !2 Softwareentwickler Softwarearchitekt Geschäftsführer DanielRosowski rosowski@smartsquare.de Bielefeld www.smartsquare.de
3. @DanielRosowski Ein Monolith ist… eine zusammenhängende, logische Einheit, z.B. Module Deployment Laufzeit !3
4. @DanielRosowski Modul-Monolith !4 © http://www.codingthearchitecture.com/2014/11/19/what_is_a_monolith.html
5. @DanielRosowski Deployment-Monolith !5 © http://www.codingthearchitecture.com/2014/11/19/what_is_a_monolith.html
6. @DanielRosowski Laufzeit-Monolith !6 © http://www.codingthearchitecture.com/2014/11/19/what_is_a_monolith.html
7. @DanielRosowski Monolithen sind böse!
 …immer? !7
8. @DanielRosowski !8
9. @DanielRosowski !9
10. @DanielRosowski „At Etsy about 150 engineers deploy a single monolithic application more than 60 times a day.“ „1.49 billion page views, 4,215,169 items sold, $94.7 million of goods sold, 22+ million members, 800,000+ active shops“ !10
11. @DanielRosowski !11
12. @DanielRosowski „We have 200 controllers with a total of 900 methods! This combined with a model of 190 classes with some 1473 methods.“ !12
13. @DanielRosowski Die Realität: Der Big Ball of Mud Ein Softwaresystem mit einer hohen Entropie Resultiert aus uneingeschränktem Wachstum Abhängigkeiten „kreuz und quer“ und zirkulär 13
14. @DanielRosowski Ausgangslage !14
15. @DanielRosowski Metriken !15
16. @DanielRosowski Architektur !16
17. @DanielRosowski Dependency Structure Matrix Spring Framework !17 © https://erik.doernenburg.com/2010/04/dependency-structure-matrix/
18. @DanielRosowski Dependency Structure Matrix Spring Framework !18 © https://erik.doernenburg.com/2010/04/dependency-structure-matrix/
19. @DanielRosowski Dependency Structure Matrix
 Der Monolith !19
20. @DanielRosowski Probleme !20
21. @DanielRosowski Probleme Lange Releasezyklen Test-Eistüte Langer Buildprozess Teambildung eingeschränkt !21
22. @DanielRosowski Lange Releasezyklen Agiles Mantra: „release early, release often“, aber: Keine Module, keine Teilreleases Aufwändiger Model-Driven-Development Prozess Langer Buildprozess !22
23. @DanielRosowski Lange Releasezyklen Anpassung eines Pflichtfelds: !23 Dev + QS + Rollout = 1-2 PT
24. @DanielRosowski Testpyramide !24 Unit Tests Integration Tests UI Tests Manual Tests Laufzeit Kosten
25. @DanielRosowski Test-Eistüte Die Testpyramide im Kopfstand Viele Integrations- und GUI Tests = Lange Laufzeit 25
26. @DanielRosowski Langer Buildprozess !26
27. @DanielRosowski Langer Buildprozess !27
28. @DanielRosowski Teambildung eingeschränkt fehlende Modularisierung => keine Schnittstellen Keine isolierte Fachlichkeit => Jeder muss alles wissen Querschnittsthemen wie Architektur und QS werden zunehmend schwieriger !28
29. @DanielRosowski –Unbekannt „Und nu?“ !29
30. @DanielRosowski Weitere Erosion des Monolithen verhindern! !30
31. @DanielRosowski Architektur Arbeitsgruppe Regelmäßiger Termin mit klarem Fokus Jeder ist eingeladen teilzunehmen I.d.R. um die 4-5 Devs und 1-2 Ops Ergebnisse werden protokolliert Architekturentscheidungen werden in Architecture- Decision-Records (ADR) festgehalten !31
32. @DanielRosowski Zielarchitektur 
 festlegen & prüfen Oftmals ist eine ursprüngliche Architektur bekannt / erkennbar Architektur festlegen (es gibt Tools, z.B. Structure101) Architektur visualisieren (PlantUML, yed, Whiteboard) Architektur-Constraints festlegen
 !32
33. @DanielRosowski Zielarchitektur !33
34. @DanielRosowski Architektur dokumentieren !34
35. @DanielRosowski Architektur-Constraints kontinuierlich prüfen Structure101 SonarQube jQAssistant Degraph Archunit !35 UI Service Domain
36. @DanielRosowski Pfadfinder-Regel !36 © https://www.lustiges-taschenbuch.de/entenhausen/charaktere/die-ducks/faehnlein-fieselschweif „Hinterlasse einen Ort immer in einem besseren Zustand als du ihn vorgefunden hast.“
37. @DanielRosowski Teilsysteme bilden !37
38. @DanielRosowski Microservices!
 Ist doch klar! 
 …oder? !38
39. @DanielRosowski Microservices sind ein Modularisierungskonzept sind …klein. sind separate Deployments sind Programmiersprachen-unabhängig sind nicht eindeutig definiert! !39
40. @DanielRosowski !40 © https://martinfowler.com/articles/microservice-trade-offs.html
41. @DanielRosowski Self-Contained-Systems sind …größer als Microservices :-) sind in sich geschlossen, sie müssen nicht mit anderen Systemen kommunizieren beinhalten i.d.R. eine UI (Webanwendung) werden i.d.R. über die UI integriert !41
42. @DanielRosowski !42 Independent Systems Architecture Microservices Self-Contained-
 Systems
43. @DanielRosowski Independent Systems Architecture Module die über Schnittstellen kommunizieren Module sind separate Prozesse, Container oder virtuelle Maschinen Unterscheidung zwischen Makro- und Mikroarchitektur Integration über standardisierte Schnittstellen !43 Kommunikation über standardisierte Protokolle Eigenständiger CI/CD Lifecycle Standardisierter Betrieb (Konfiguration, Deployment, Logging, etc.) Resilienz
44. @DanielRosowski Microservices oder 
 Self-Contained-Systems? !44
45. @DanielRosowski !45
46. @DanielRosowski !46
47. @DanielRosowski Entscheidungen für 
 Self-Contained-Systems Programmiersprachen-Unabhängigkeit wird nicht gebraucht (JEE Stack) Microservices sind schwierig! UI soll maßgeblicher Bestandteil der Teilsysteme sein Für sich alleine genommen sinnvoller Business Value !47
48. @DanielRosowski SCS in the wild otto.de
 https://dev.otto.de/2016/03/20/why-microservices/ Kühne + Nagel
 https://kuehne-nagel.github.io/monolith-to- microservices/#/ Hermes
 https://speakerdeck.com/hermes/wie-wir-mit- microservices-beinahe-gescheitert-waren !48
49. @DanielRosowski Der Weg zu SCS !49
50. @DanielRosowski Fachlicher Schnitt !50 Domain Service UI Faktura Verarbeitung Reporting
51. @DanielRosowski Welche Fachlichkeit? Was wurde in der Vergangenheit häufig geändert? Was wird sich in Zukunft vermutlich häufig ändern? Oder auch, was verursacht den größten Schmerz? !51
52. @DanielRosowski Was wurde in der Vergangenheit am häufigsten geändert? Ticketsystem Reporting über Epics (o.ä.) der letzten Monate/Jahre VCS Reporting über geänderte Pfade der letzten Monate/ Jahre !52
53. @DanielRosowski Was wird sich in Zukunft vermutlich am häufigsten ändern? Backlog analysieren Mit dem Business sprechen! Stakeholder konsultieren Zukünftige Businessgoals beachten !53
54. @DanielRosowski Was verursacht den größten Schmerz? “If it hurts, do it more frequently, 
 and bring the pain forward.”
 - Jez Humble Architektur Arbeitsgruppe Einzelne Entwickler befragen !54 © https://de.wikipedia.org/wiki/Der_Schrei
55. @DanielRosowski Kunden- schnittstellen !55
56. @DanielRosowski DSM Abstrakter Kundenservice Ausgabe Kundenschnittstellen Kundenschnittstellen Ausgabe !56
57. @DanielRosowski Typische Probleme Hohe Codeduplikation Schlechte Testbarkeit Hohe Änderungsfrequenz Hohe Kopplung !57
58. @DanielRosowski Ausgangslage Verarbeitung Eingangs- schnittstellen Ausgangs- schnittstellen FTP FTP Datenbank Reporting Faktura Self-
 Service … !58
59. @DanielRosowski Vorgehen Integration der Serviceschicht Integration der Daten Integration der Benutzerschnittstelle !59
60. @DanielRosowski Integration der Serviceschicht Verarbeitung MQ FTP FTP Reporting Faktura Self-
 Service … !60 Eingang Ausgang Kunden- schnittstellen
61. @DanielRosowski Kundenschnittstellen Start mit zwei Kunden und zwei KSS „Feature Toggle“ am Kunden !61 Der „Standardkunde“ (ca. 80% aller Kunden) Der „Customized Customer“
62. @DanielRosowski Canary Release Verarbeitung FTP Datenbank MQ Eingang Ausgang Kunden- schnittstellen Eingang Ausgang !62 FTP
63. @DanielRosowski Relocate or Rewrite? Code in das neue System verschieben? Oder Code neu schreiben? Es gibt keine klare Heuristik! Hybrid, da einige Teile übernommen werden konnten, andere dafür komplett ersetzt werden (EIP) !63
64. @DanielRosowski Pipes and Filters Validieren Splitten Normieren Anreichern Kundenschnittstelle Unit-Test? Unit-Test! Unit-Test! Unit-Test! Unit-Test! !64
65. @DanielRosowski Pipes and Filters Validieren Splitten Normieren Anreichern FTP Message Queue Ergebnis- mapping Anreichern Aggregieren FTP Message Queue Eingang Ausgang !65
66. @DanielRosowski Kundenschnittstellen 1. Schritt: Eigener Bounded Context im Monolithen Schnittstelle zu den Stammdaten im Monolithen !66
67. @DanielRosowski Integration der Daten Eingang Ausgang CSV XML Version 4 Version 3 UTF-8 UTF-8 Verarbeitung Reporting Faktura Self-
 Service … REST API ⭐ ⭐ Monolith !67 Eingang Ausgang Kunden- schnittstellen Kunde Id Name Organisation
68. @DanielRosowski Kundenschnittstellen 2. Schritt: Bounded Context in eigenes Schema migrieren Schnittstelle zu den Stammdaten im Monolithen bleibt bestehen !68
69. @DanielRosowski Integration der Daten Kunden- schnittstellen Kunde Id Name Organisation Verarbeitung Reporting Faktura Self-
 Service … REST API Eingang Ausgang CSV XML Version 4 Version 3 UTF-8 UTF-8 Monolith !69
70. @DanielRosowski User Interface !70 Work in Progress!
71. @DanielRosowski Wie kann integriert werden? !71 Server-seitig Client-seitig
72. @DanielRosowski Wie kann integriert werden? Server-seitig
 z.B. ESI oder SSI ➕ Standardlösung, wird von
 den meisten Webservern
 unterstützt
 
 
 ➖ Synchron und dadurch
 langsam !72 Client-seitig
 z.B. Ajax ➕ Asynchron und dadurch 
 fehlertolerant
 ➕ Es können auch nur Teile
 der Seite neu geladen
 werden
 ➖ Mehrere Requests im
 Client nötig
73. @DanielRosowski Am Beispiel Kundenschnittstellen !73 UI (JSF) MQ Monolith Kunden- schnittstellen HTML Javascript
74. @DanielRosowski Deployment !74
75. @DanielRosowski Deployment Release early and deploy early! Operating frühstmöglich ins Boot holen Zentrales Monitoring und Logging unbedingt empfehlenswert! Eigenständiger CI/CD Lifecycle !75
76. @DanielRosowski Zentrales Logging / Monitoring Kunden- schnittstellen Verarbeitung Reporting Faktura Self-
 Service … REST API Monolith !76
77. @DanielRosowski CI/CD Jenkins / GoCD / Teamcity / … Chef / Puppet / Ansible / … Docker / K8S !77 Build Test Provisioning Deploy Test Pre-
 Prod Prod
78. @DanielRosowski Arbeits- organisation !78
79. @DanielRosowski Lessons Learned und Anti-Patterns !79
80. @DanielRosowski Antipattern 
 „Ivory Architect“ Architekturarbeit ist Teamarbeit Architektur sollte nicht im Elfenbeinturm entworfen werden Die Entwickler wissen selber am besten, welche Stellen die größten Probleme verursachen 80 © http://dilbert.com
81. @DanielRosowski Antipattern 
 „Big Bang“ Mit kleiner unabhängiger Funktionalität starten Gefühl für Sizing entwickeln Erste Erfahrungen mit Multi- Deployment sammeln Gefahr des „Microlith“ 81 © https://www.popsci.com
82. @DanielRosowski Antipattern 
 „Half Measures“ Serviceschicht und User Interface werden modularisiert Daten liegen weiterhin in einem monolithischen Schema Oder anders herum: Daten und Service und monolithische UI 82 © https://www.cafepress.com/+breakingbad_half_measures_tile_coaster,1716311230
83. @DanielRosowski Antipattern 
 „Stuck-in-Between“ Am Anfang wird eine Verschlechterung der Architektur bewusst in Kauf genommen Wenn der Schritt nicht komplett vollzogen wird, stehen wir hinterher schlechter da! 83 © https://martinfowler.com/articles/break-monolith-into-microservices.html
84. @DanielRosowski Antipattern 
 „Dance around“ Kernsystem wird nicht angegangen, da zu komplex zu hohes Risiko Es werden nur periphere Module gebildet (zumeist technischer Natur) 84
85. @DanielRosowski Vielen Dank! !85
86. @DanielRosowski Quellen Monolithen http://www.codingthearchitecture.com/2014/11/19/what_is_a_monolith.html https://microservices.io/patterns/monolithic.html http://highscalability.com/blog/2014/7/28/the-great-microservices-vs-monolithic-apps-twitter-melee.html https://m.signalvnoise.com/the-majestic-monolith-29166d022228 Architektur https://en.wikipedia.org/wiki/Software_entropy https://erik.doernenburg.com/2010/04/dependency-structure-matrix/ http://thinkrelevance.com/blog/2011/11/15/documenting-architecture-decisions Microservices / SCS / ISA https://leanpub.com/microservices-primer/read https://scs-architecture.org/ https://isa-principles.org/ https://martinfowler.com/bliki/CanaryRelease.html !86