Hilfe, ich will meinen Monolithen zurück!
•
0 gefällt mir•491 views
Man gewinnt den Eindruck, Microservices seien die Universallösung für all unsere (Architektur-)Probleme. Dabei sind Microservices lediglich Mittel zum Zweck. Was also, wenn meine Probleme nicht zur Lösung „Microservices“ passen? Ist es nach wir vor legitim, einen Monolithen zu bauen? Oder gibt es andere Architekturansätze, mit denen sich Monolithen aufbrechen lassen? In der Session werfen wir einen kritischen Blick auf Microservices und beleuchten – immer ausgehend von bestehenden Problemfeldern – eine Reihe alternativer Architekturen.
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Ähnlich wie Hilfe, ich will meinen Monolithen zurück!
Ähnlich wie Hilfe, ich will meinen Monolithen zurück! (20)
Mehr von OPEN KNOWLEDGE GmbH
Mehr von OPEN KNOWLEDGE GmbH (20)
Hilfe, ich will meinen Monolithen zurück!
- 1. #WISSENTEILEN Hilfe, ich will meinen Monolithen zurück! Lars Röwekamp CIO New Technologies @mobileLarson | @_openknowledge #WISSENTEILEN
- 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“
- 7. #WISSENTEILEN MONOLITH nix als Probleme - Umsetzungsstau - Robustheit - Release Qualität - Kosten - Zukunftsfähigkeit - Skalierbarkeit
- 9. #WISSENTEILEN MICROSERVICES to the Rescue - einfach(er) - schnell(er) - lokal(er) - frei(er) - isoliert(er) - skalierbar(er) - agil(er)
- 10. #WISSENTEILEN MONOLITH ACHTUNG: von Natur aus böse! So kann ich nicht arbeiten!
- 11. #WISSENTEILEN MI CR O SER VI CES ARCHI TEC TURE unabhängig • entwickeln • testen • deployen • skalieren So will ich arbeiten!
- 12. #WISSENTEILEN MI CR O SER VI CES ARCHI TEC TURE Ok, es gibt Challenges …
- 13. #WISSENTEILEN MI CR O SER VI CES ARCHI TEC TURE Ok, es gibt Challenges … • Communication
- 14. #WISSENTEILEN MI CR O SER VI CES ARCHI TEC TURE Ok, es gibt Challenges … • Communication
- 15. #WISSENTEILEN MI CR O SER CES ARCHI TEC TURE Ok, es gibt Challenges … • Communication VI
- 16. #WISSENTEILEN MI CR O SER CES ARCHI TEC TURE SORRY! The service is temporary not available Ok, es gibt Challenges … • Communication • Resilience
- 17. #WISSENTEILEN MI CR O SER VI CES ARCHI TEC TURE Ok, es gibt Challenges … • Communication • Resilience • Monitoring
- 18. #WISSENTEILEN MI CR O SER VI CES ARCHI TEC TURE Ok, es gibt Challenges … • Communication • Resilience • Monitoring ?
- 19. #WISSENTEILEN MI CR O SER VI CES ARCHI TEC TURE Ok, es gibt Challenges … • Communication • Resilience • Monitoring ? ? ? ? ?
- 20. #WISSENTEILEN MI CR O SER VI CES ARCHI TEC TURE Ok, es gibt Challenges … • Communication • Resilience • Monitoring • Security
- 21. #WISSENTEILEN MI CR O SER VI CES ARCHI TEC TURE Ok, es gibt Challenges … • Communication • Resilience • Monitoring • Security
- 22. #WISSENTEILEN MI CR O SER VI CES ARCHI TEC TURE Ok, es gibt Challenges … • Communication • Resilience • Monitoring • Security • Data & TX
- 23. #WISSENTEILEN MI CR O SER VI CES ARCHI TEC TURE Ok, es gibt Challenges … • Communication • Resilience • Monitoring • Security • Data & TX • Configuration
- 24. #WISSENTEILEN MI CR SER VI CES TEC TURE O ARCHI Ok, es gibt Challenges … • Communication • Resilience • Monitoring • Security • Data & TX • Configuration • Versioning
- 25. #WISSENTEILEN MI CR SER VI CES TEC TURE O ARCHI Ok, es gibt Challenges … • Communication • Resilience • Monitoring • Security • Data & TX • Configuration • Versioning
- 26. #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
- 27. #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
- 28. #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 ?
- 29. #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
- 30. #WISSENTEILEN Hilfe, ich will meinen Monolithen zurück!
- 31. #WISSENTEILEN
- 32. #WISSENTEILEN Warum eigentlich noch mal Microservices?
- 33. #WISSENTEILEN Was waren noch mal die Problem? • Umsetzungstaus • Release Qualität • Robustheit • Kosten • Zukunftsfähigkeit • Skalierbarkeit* *Entwicklungs- vs. Laufzeit
- 34. #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
- 35. #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
- 36. #WISSENTEILEN „Auflösen der Abhängigkeiten“ *wo möglich und keine zusätzliche Komplexität geschaffen wird.
- 37. #WISSENTEILEN Fachlichkeit „zurück“ in den Fokus Step #1
- 40. #WISSENTEILEN Status Quo Infrastructure-driven Architecture • technische Injection • technische Transaktionen • technische Scopes • technische Methoden
- 41. #WISSENTEILEN TX
- 42. #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?
- 43. #WISSENTEILEN TX
- 44. #WISSENTEILEN TX
- 45. #WISSENTEILEN TX
- 46. #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
- 47. #WISSENTEILEN
- 48. #WISSENTEILEN Wie steht‘s eigentlich mit Transaktionen?
- 49. #WISSENTEILEN
- 50. #WISSENTEILEN TX
- 51. #WISSENTEILEN TX
- 52. #WISSENTEILEN Step #1: fachliche Injektion CDI Producer Methods & Fields • CDI Producer Methods & Fields • @Produces zur Erzeugung von Objekten • @Qualifier zur fachlichen Qualifizierung
- 53. #WISSENTEILEN
- 56. #WISSENTEILEN Step #2: fachliche Transaktionen Transaktionen auf Use-Case Ebene • keine @EJB Facade • @Transactional
- 57. #WISSENTEILEN TX
- 58. #WISSENTEILEN TX
- 59. #WISSENTEILEN
- 60. #WISSENTEILEN Step #3: fachlicher Scope Use-Case vs. Session • Anti-Pattern „pumped-up“ Session • Conversation exakt so lange wie benötigt • @ConversationalScoped
- 61. #WISSENTEILEN
- 62. #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 …
- 63. #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
- 64. #WISSENTEILEN
- 65. #WISSENTEILEN
- 66. #WISSENTEILEN Step #4: fachliche Methoden CDI Events zur losen Kopplung • Event Object & Event Producer • Observer Methoden
- 67. #WISSENTEILEN
- 68. #WISSENTEILEN
- 69. #WISSENTEILEN Fachlichkeit im Fokus Business-driven Architecture, d.h. ... • fachliches Modell* • fachliche Injection • fachliche Transaktionen • fachliche Scopes • fachliche Methoden *DDD, Rich Domain Model
- 70. #WISSENTEILEN TX
- 71. #WISSENTEILEN TX
- 72. #WISSENTEILEN TX
- 73. #WISSENTEILEN TX
- 75. #WISSENTEILEN Monolithic Architecture Service-based Architecture „Big Ball of Mud“ ? Best-of-both-Worlds Architecture Abhängigkeit stark schwach
- 76. #WISSENTEILEN Monolithic Architecture Service-based Architecture „Big Ball of Mud“ *The Modular Monolith, Simon Brown Modular* Architecture
- 77. #WISSENTEILEN • high cohesion • low coupling • business capabilities • bounded context / aggregates • encapsulated data • substitutable • composable • deployable • upgradeable • replaceable • scalable alle Vorteile von „Modular“ plus unabhängig … Services Modular
- 78. #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!“
- 79. #WISSENTEILEN Modular Monolith Wie erhalte ich die modulare Struktur?
- 80. #WISSENTEILEN „The code structure should reflect the architectural intent.” Simon Brown - „The modular Monolith“ Simon Brown
- 81. #WISSENTEILEN George Fairbanks - „Just enough Software Architecture“ Model-Code Gap George Fairbanks
- 82. #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
- 84. #WISSENTEILEN Package by Feature CustomersController << interface >> CustomersService CustomersServiceImpl << interface >> CustomersRepository de.openknowledge.app.customers <<uses>> <<uses>> DbCustomersRepository
- 85. #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
- 86. #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>>
- 87. #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
- 88. #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
- 89. #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
- 90. #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
- 91. #WISSENTEILEN Business Data Package by Component public API als „undurchlässige“ Grenze (Access Modifiers / Network Boundaries) Business Data Component Microservice Public API Public API
- 96. #WISSENTEILEN „Use encapsulation to minimise the number of potential dependencies.”* Simon Brown *vermeide public Keyword wann immer möglich!
- 97. #WISSENTEILEN Modularisierung via Artifacts* v1 v1 v1 v1 v1 v1 v1 v1 v1 * mehrere JARs (aber trotzdem nur eine Version)
- 98. #WISSENTEILEN Modularisierung via Repos* v1 v1 v2 v1 v2 v1 v5 v1 v7 * mehrere JARs und mehrere Versionen
- 99. #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 Dependencies • Testen einzelner Module möglich * und ggf. Versionierung
- 100. #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, …)
- 101. #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.
- 103. #WISSENTEILEN Die eigentliche Frage ist nicht „Microservices?“
- 104. #WISSENTEILEN Die eigentliche Frage ist „Was will ich verbessern?“
- 105. #WISSENTEILEN „So einfach wie möglich!“ … und so komplex wie notwendig!
- 106. #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
- 108. #WISSENTEILEN Lars Röwekamp, @mobileLarson Kontakt: lars.roewekamp@openknowledge.de kontakt@openknowledge.de Besten Dank! #WISSENTEILEN
- 109. #WISSENTEILEN #001 thx to Andrea Picaquadio (pexels.com) #006 thx to Mike van Schoonderwalt (pexels.com) #008 thx to Andrea Picaquadio (pexels.com) #030 thx to Andrea Picaquadio (pexels.com) #102 thx to Andrea Picaquadio (pexels.com) Alle weiteren Bilder der Präsentation sind entweder von pexels.com, pixabay.com oder von mir selbst erstellt. Bildernachweis