Die Matrix: Enterprise-Architekturen jenseits von Microservices
0 gefällt mir299 aufrufe
Das Dokument behandelt die Herausforderungen und Vorzüge von Microservices im Vergleich zu monolithischen Architekturen, insbesondere in Bezug auf Skalierbarkeit, Agilität und Fachlichkeit. Es wird erläutert, wie Microservices eine effizientere Softwareentwicklung ermöglichen können, jedoch auch Herausforderungen wie Kommunikation und Überwachung mit sich bringen. Lars Röwekamp betont die Notwendigkeit einer klaren Trennung von Verantwortlichkeiten und eine modulare Architektur, um komplexe Systeme besser zu managen.
Die Matrix: Enterprise-Architekturen jenseits von Microservices
- 1. #WISSENTEILEN Die Matrix: Enterprise Architekturen jenseits von Microservices #WISSENTEILEN Lars Röwekamp CIO New Technologies @mobileLarson | @_openknowledge
- 2. #WISSENTEILEN ÜBER OPEN KNOWLEDGE Branchenneutrale Softwareentwicklung & IT-Beratung
- 3. #WISSENTEILEN ÜBER MICH Wer bin ich - und wenn ja, wie viele? • CIO New Technologies • Enterprise & Mobile • Autor, Speaker, Coach & Mentor • Snowboard & MTB Enthusiast (a.k.a. “stets bemüht“) Lars Röwekamp (a.k.a. @mobileLarson)
- 4. #WISSENTEILEN Der böse, böse Monolith
- 5. #WISSENTEILEN a.k.a. „Big Ball of Mud“
- 13. #WISSENTEILEN MONOLITH ACHTUNG: von Natur aus böse! So kann ich nicht arbeiten!
- 14. #WISSENTEILEN „Glaub mir, Microservices sind das ‚next big Thing‘!“
- 15. #WISSENTEILEN Die DNA von Microservices „A microservices ecosystem (ME) is a platform of services each encapsulating a business capability. Developers can build, test and release each microservice independently. ME enforces an organizational structure of autonomous long standing teams, each responsible for one or multiple services.“ (Zhamak Dehghani, ThoughtWorks)
- 16. #WISSENTEILEN
- 17. #WISSENTEILEN einfach(-er) Fachlichkeit ist einfach zu verstehen
- 18. #WISSENTEILEN schnell(-er) Service startet schneller als Monolith
- 19. #WISSENTEILEN lokal(-er) interne Änderungen nur lokal sichtbar
- 21. #WISSENTEILEN isoliert(-er) eigener Prozess je Service
- 22. #WISSENTEILEN skalierbar(-er) Fachlichkeit als Basis der Skalierung
- 24. #WISSENTEILEN MI CR O SER VI CES ARCHI TEC TURE unabhängig • entwickeln • testen • deployen • skalieren So will ich arbeiten!
- 25. #WISSENTEILEN MI CR O SER VI CES ARCHI TEC TURE Ok, es gibt Challenges …
- 26. #WISSENTEILEN MI CR O SER VI CES ARCHI TEC TURE Ok, es gibt Challenges … • Communication
- 27. #WISSENTEILEN MI CR O SER VI CES ARCHI TEC TURE Ok, es gibt Challenges … • Communication
- 28. #WISSENTEILEN MI CR O SER CES ARCHI TEC TURE Ok, es gibt Challenges … • Communication VI
- 29. #WISSENTEILEN MI CR O SER CES ARCHI TEC TURE SORRY! The service is temporary not available Ok, es gibt Challenges … • Communication • Resilience
- 30. #WISSENTEILEN MI CR O SER VI CES ARCHI TEC TURE Ok, es gibt Challenges … • Communication • Resilience • Monitoring
- 31. #WISSENTEILEN MI CR O SER VI CES ARCHI TEC TURE Ok, es gibt Challenges … • Communication • Resilience • Monitoring ?
- 32. #WISSENTEILEN MI CR O SER VI CES ARCHI TEC TURE Ok, es gibt Challenges … • Communication • Resilience • Monitoring ? ? ? ? ?
- 33. #WISSENTEILEN MI CR O SER VI CES ARCHI TEC TURE Ok, es gibt Challenges … • Communication • Resilience • Monitoring • Security
- 34. #WISSENTEILEN MI CR O SER VI CES ARCHI TEC TURE Ok, es gibt Challenges … • Communication • Resilience • Monitoring • Security
- 35. #WISSENTEILEN MI CR O SER VI CES ARCHI TEC TURE Ok, es gibt Challenges … • Communication • Resilience • Monitoring • Security • Data & TX
- 36. #WISSENTEILEN MI CR O SER VI CES ARCHI TEC TURE Ok, es gibt Challenges … • Communication • Resilience • Monitoring • Security • Data & TX • Configuration
- 37. #WISSENTEILEN MI CR SER VI CES TEC TURE O ARCHI Ok, es gibt Challenges … • Communication • Resilience • Monitoring • Security • Data & TX • Configuration • Versioning
- 38. #WISSENTEILEN MI CR SER VI CES TEC TURE O ARCHI Ok, es gibt Challenges … • Communication • Resilience • Monitoring • Security • Data & TX • Configuration • Versioning
- 39. #WISSENTEILEN MI CR SER VI CES TEC TURE VI v2 O ARCHI v2 Ok, es gibt Challenges … • Communication • Resilience • Monitoring • Security • Data & TX • Configuration • Versioning
- 40. #WISSENTEILEN MI CR SER VI CES TEC TURE VI O ARCHI v3 v2 Ok, es gibt Challenges … • Communication • Resilience • Monitoring • Security • Data & TX • Configuration • Versioning VI v3
- 41. #WISSENTEILEN MI CR SER VI CES TEC TURE VI VI v3 O ARCHI v3 v2 Ok, es gibt Challenges … • Communication • Resilience • Monitoring • Security • Data & TX • Configuration • Versioning ?
- 42. #WISSENTEILEN MI SER VI CES TEC TURE VI VI v3 ARCHI v3 v2 Ok, es gibt Challenges … • Communication • Resilience • Monitoring • Security • Data & TX • Configuration • Versioning deprecated O CR
- 43. #WISSENTEILEN Hilfe, ich will meinen Monolithen zurück!
- 44. #WISSENTEILEN
- 45. #WISSENTEILEN Warum eigentlich noch mal Microservices?
- 46. #WISSENTEILEN Was waren noch mal die Problem? • Umsetzungstaus • Release Qualität • Robustheit • Kosten • Zukunftsfähigkeit • Skalierbarkeit* *Entwicklungs- vs. Laufzeit
- 47. #WISSENTEILEN Was waren noch mal die Problem? • Umsetzungstaus • Release Qualität • Robustheit • Kosten • Zukunftsfähigkeit • Skalierbarkeit #1 stark verwässerte Fachlichkeit #2 fehlende Trennung von Zuständigkeiten #3 Abhängigkeiten innerhalb der Architektur
- 48. #WISSENTEILEN Was waren noch mal die Problem? • Umsetzungstaus • Release Qualität • Robustheit • Kosten • Zukunftsfähigkeit • Skalierbarkeit viel zu viele Abhängigkeiten in der Entwicklung, im Testing und zur Laufzeit
- 49. #WISSENTEILEN „Auflösen der Abhängigkeiten“ *wo möglich und keine zusätzliche Komplexität geschaffen wird.
- 50. #WISSENTEILEN Fachlichkeit „zurück“ in den Fokus Step #1
- 53. #WISSENTEILEN Status Quo Infrastructure-driven Architecture • technische Injection • technische Transaktionen • technische Scopes • technische Methoden
- 54. #WISSENTEILEN TX
- 55. #WISSENTEILEN Problemkind Schichtenmodell • UI Controller via CDI Managed Beans • Service Facade und Services via EJB/CDI • Persistenz via EntityManager und Entities • Alles nur Infrastruktur! • Wo steckt eigentlich die fachliche Domain?
- 56. #WISSENTEILEN TX
- 57. #WISSENTEILEN TX
- 58. #WISSENTEILEN TX
- 59. #WISSENTEILEN Fachlichkeit im Fokus UC-001: „create Customer“ • Kunde neu erfassen und speichern • Begrüßungs-Mail an Neukunden versenden • Call Center Agent als Audit-Info speichern
- 60. #WISSENTEILEN
- 61. #WISSENTEILEN Wie steht‘s eigentlich mit Transaktionen?
- 62. #WISSENTEILEN
- 63. #WISSENTEILEN TX
- 64. #WISSENTEILEN TX
- 65. #WISSENTEILEN Step #1: fachliche Injektion CDI Producer Methods & Fields • CDI Producer Methods & Fields • @Produces zur Erzeugung von Objekten • @Qualifier zur fachlichen Qualifizierung
- 66. #WISSENTEILEN
- 69. #WISSENTEILEN Step #2: fachliche Transaktionen Transaktionen auf Use-Case Ebene • keine @EJB Facade • @Transactional
- 70. #WISSENTEILEN TX
- 71. #WISSENTEILEN TX
- 72. #WISSENTEILEN
- 73. #WISSENTEILEN Step #3: fachlicher Scope Use-Case vs. Session • Anti-Pattern „pumped-up“ Session • Conversation exakt so lange wie benötigt • @ConversationalScoped
- 74. #WISSENTEILEN
- 75. #WISSENTEILEN Step #4: fachliche Methoden a.k.a. „no more doAll(…)-Methods“ • Primärer Use Case: create Customer • Sekundärer Use Case: send Welcome Mail • Sekundärer Use Case: trace Trainee Audit Info • Sekundärer Use Case: if tenant X …
- 76. #WISSENTEILEN Step #4: fachliche Methoden Idee der Domänen-Events • Primärer Use Case löst Event aus • Sekundäre Use Cases reagieren auf Event
- 77. #WISSENTEILEN
- 78. #WISSENTEILEN
- 79. #WISSENTEILEN Step #4: fachliche Methoden CDI Events zur losen Kopplung • Event Object & Event Producer • Observer Methoden
- 80. #WISSENTEILEN
- 81. #WISSENTEILEN
- 82. #WISSENTEILEN Fachlichkeit im Fokus Business-driven Architecture, d.h. ... • fachliches Modell* • fachliche Injection • fachliche Transaktionen • fachliche Scopes • fachliche Methoden *DDD, Rich Domain Model
- 83. #WISSENTEILEN TX
- 84. #WISSENTEILEN TX
- 85. #WISSENTEILEN TX
- 86. #WISSENTEILEN TX
- 88. #WISSENTEILEN Monolithic Architecture Service-based Architecture „Big Ball of Mud“ ? Best-of-both-Worlds Architecture Abhängigkeit stark schwach
- 89. #WISSENTEILEN Monolithic Architecture Service-based Architecture „Big Ball of Mud“ *The Modular Monolith, Simon Brown Modular* Architecture
- 90. #WISSENTEILEN • high cohesion • low coupling • business capabilities • bounded context / aggregates • encapsulated data • substitutable • composable • deployable • upgradeable • replaceable • scalable all Vorteile von „Modular“ plus unabhängig … Services Modular
- 91. #WISSENTEILEN Unabhängigkeit in der Entwicklung und im Testing • high cohesion • low coupling • business capabilities • bounded context / aggregates • encapsulated data • substitutable • composable Modular „Mehr verlange ich doch gar nicht vom Leben!“
- 92. #WISSENTEILEN Modular Monolith Wie erhalte ich die modulare Struktur?
- 93. #WISSENTEILEN „The code structure should reflect the architectural intent.” Simon Brown - „The modular Monolith“ Simon Brown
- 94. #WISSENTEILEN George Fairbanks - „Just enough Software Architecture“ Model-Code Gap George Fairbanks
- 95. #WISSENTEILEN CustomersController << interface >> CustomersService CustomersServiceImpl << interface >> CustomersRepository Package by Layer de.openknowledge.app.web de.openknowledge.app.service de.openknowledge.app.data <<uses>> <<uses>> DbCustomersRepository
- 97. #WISSENTEILEN Package by Feature CustomersController << interface >> CustomersService CustomersServiceImpl << interface >> CustomersRepository de.openknowledge.app.customers <<uses>> <<uses>> DbCustomersRepository
- 98. #WISSENTEILEN CustomersController << interface >> CustomersService CustomersServiceImpl << interface >> Customers de.openknowledge.app.web de.openknowledge.app.domain de.openknowledge.app.data <<uses>> <<uses>> Package by Ports/Adapter Domain* (inside) Infrastructure (outside) DbCustomersRepository *DDD
- 99. #WISSENTEILEN CustomersController << interface >> CustomersService CustomersServiceImpl << interface >> CustomersRepository Add a new Feature … de.openknowledge.app.web de.openknowledge.app.service de.openknowledge.app.data <<uses>> <<uses>> DbCustomersRepository <<uses>>
- 100. #WISSENTEILEN Big Ball of Mud „A big ball of mud is a casually, even haphazardly, structured system. Its organization, if one can call it that, is dictated more by expedience than by design.“ by Brian Foote & Joseph Yoder
- 101. #WISSENTEILEN Aber wir haben doch REGELN! Architecture Principles geben Regeln vor. Dev Reviews & Tools finden Verstöße, oder? • Inspection von Code UND anderen Artifakten • jqAssistant, SonarGraph/Cloud, jDepend • ArchUnit (Arch Regeln als UnitTests) • Spring Moduliths Framework
- 102. #WISSENTEILEN Modularisierung* und ihre Probleme Package pro … • Layer: rein technische Sicht • Features: übergreifende Fachlichkeit • Ports & Adapters: Wrapper über Warpper • ???? *the code structure should reflect the architectural intent
- 103. #WISSENTEILEN CustomersController << interface >> CustomersComponent << interface >> CustomersRepositoty Package by Component* de.openknowledge.app.web de.openknowledge.app.customers <<uses>> DbCustomersRepository CustomersComponentImpl <<uses>> *grouping of related functionality behind a nice clean interface
- 104. #WISSENTEILEN Business Data Package by Component public API als „undurchlässige“ Grenze (Access Modifiers / Network Boundaries) Business Data Component Microservice Public API Public API
- 109. #WISSENTEILEN „Use encapsulation to minimise the number of potential dependencies.”* Simon Brown *vermeide public Keyword wann immer möglich!
- 110. #WISSENTEILEN Modularisierung via Artifacts* v1 v1 v1 v1 v1 v1 v1 v1 v1 * mehrere JARs (aber trotzdem nur eine Version)
- 111. #WISSENTEILEN Modularisierung via Repos* v1 v1 v2 v1 v2 v1 v5 v1 v7 * mehrere JARs und mehrere Versionen
- 112. #WISSENTEILEN Modularisierung via Artifacts/Repos v1 v1 v1 v1 v1 v1 v1 v1 v1 Build Artifact pro Fachlichkeit • jedes Modul erhält eigenes Build Artifact • einige wenige „common“ / „core“ Artifacts • Zugriffskontrolle* über die Dependecies • Testen einzelner Module möglich * und ggf. Versionierung
- 113. #WISSENTEILEN Eigene Artifacts/Repos … v1 v1 v1 v1 v1 v1 v1 v1 v1 aber was ist mit dem User Interface? • eigenes Basismodul für UI-Core-Klassen und Ressourcen (Menu, CSS, JS, …) • eigenes Modul je Fachlichkeit für spezielle Ausprägungen (Customer Menu, UI-Logic, Wizwards, …)
- 114. #WISSENTEILEN Eigene Artifacts/Repos … v1 v1 v1 v1 v1 v1 v1 v1 v1 aber was ist mit der Datenbank? • eigene Tabelle je Modul • JOINS nur auf Tabellen eines Moduls Keine geteilten Tabellen, aber referenzielle Integrität über Modulgrenzen hinweg.
- 116. #WISSENTEILEN Die eigentliche Frage ist nicht „Microservices?“
- 117. #WISSENTEILEN Die eigentliche Frage ist „Was will ich verbessern?“
- 118. #WISSENTEILEN „So einfach wie möglich!“ … und so komplex wie notwendig!
- 119. #WISSENTEILEN via Scopes* via Artifacts via Services via Repos v1 v1 v1 v1 v1 v1 v1 v1 v1 v1 v3 v7 v2 v1 v2 v3 v4 v1 Complexity Level 1 Complexity Level 2 Complexity Level 3 Complexity Level 1000 v1 Wie erhalte ich Struktur? you‘r here you‘r here you‘r here you‘r here *und Fokus auf Fachlichkeit
- 121. #WISSENTEILEN Kontakt LARS RÖWEKAMP CIO NEW TECHNOLOGIES lars.roewekamp@openknowledge.de +49 (0)441 4082 – 0 @mobileLarson @_openknowledge OFFENKUNDIGGUT
- 122. #WISSENTEILEN Bildnachweise #01 © diy13 – shutterstock.com All other pictures inside this presentation orginate from pexels.com, pixabay.com, flaticon.com or were created by my own.