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.
Getreu dem Motto "choose Microservices for the benefits and not because your codebase is a mess." (Zitat: Simon Brown), beleuchtet die Session typische Problemstellungen aus großen Projekten und zeigt auf, für welche dieser Microservices eine Lösung darstellen und für welche eher nicht. Anhand verschiedener Real-Life-Anforderungen, werden alternative Architekturen als Lösungsansätze gezeigt und bewertet.
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)
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)
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
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
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?
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
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
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!“
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