First-cut-is-the-deepest - OOP 2020€¦ · Cloud Foundry Discovery HashicorpConsul … 22...
Transcript of First-cut-is-the-deepest - OOP 2020€¦ · Cloud Foundry Discovery HashicorpConsul … 22...
1
Version:
Java-Software-Modularisierung – aber wie?Empfehlungen mit und gegen den Trend
20.1
Version:
The First Cut Is The DeepestEmpfehlungen mit und gegen den Trend
20.1
1
2
2
3
Ihre Sprecher
Trainer, Berater, Entwickler
Christian Dedek & Thorsten Maier
@ThorstenMaierChristian Dedek
4
Ihre Sprecher
Trainer, Berater, Entwickler
Thorsten Maier
@ThorstenMaier
3
4
3
5
6
Anwender brauchen
keine Modularisierung
5
6
4
7
Modul
Modul
Modul
Modul
Modul
Modul
Modul Modul
Modul
Modul
Modul
Modul
8
Modul
Modul
Modul
Modul
Modul
Modul
Modul Modul
ModulModul
Modul
7
8
5
ModulModul
9
Modul
Modul
Modul
Modul
Modul
Modul Modul
Modul
Modul
Modul
ModulModul
Modul
10
Modul
Modul
Modul
Modul
Modul
Modul Modul
ModulModul
Modul
Modul
Modul
ModulModul
9
10
6
11
Router Service
Product Service
Meta Info Service
Search Service
12
Kapselung
„Ich setze ein Modul in einem anderen Kontext ein
und es funktioniert nicht“
11
12
7
13
Cluelessness„Ahnungslosigkeit“
14
13
14
8
15
Auswirkungen von
Modularisierung
„Mit Modularisierung kann
man kein Geld sparen“
16
15
16
9
17
①
Build-System
18
Flugzeug startet
Kubernetes Cluster mit Microservices startet
Stabile Service-Konstellation des Autopilots
dynamisch bestimmen
17
18
10
19
Verhalten und Standorte der
Komponenten unseres Systems
verändern sich ständig
20
?
Mit wem kann / soll ich kommunizieren?
nicht erreichbar
Startetgerade
19
20
11
21
Verzeichnis-dienst
1. registrieren
2. Dienst finden
3. Dienst nutzen
z.B.:
Netflix Eureka
Apache ZooKeeper
Cloud Foundry Discovery
Hashicorp Consul
…
22
Auflösung der passenden Artefakte zur Build-Zeit
rootProject.name = 'module-demo'
include 'moduleA', 'moduleB'
dependencies {
implementation project(':moduleA')
}
module-demo1.0
modulBmodulA
21
22
12
• Gängige Build-Systeme unterstützen Multi-Module-Builds problemlos
• Relativ einfach
• Qualitätssicherung eines definierten Modul-Sets
23
Build-System – Vorteile
• IDE-Support ist brüchig
• Jede Änderung erfordert• Rebuild
• Versionsnummer
• QA-Zyklus
• Deployment
24
Build-System – Nachteile
23
24
13
25
②
Java Platform Module System
26
25
26
14
27
28
27
28
15
29
30
Java 9 Module
Modul: Main
Main
Modul: Service
API
Impl
29
30
16
31
Exportierte Packages und Abhängigkeiten
module de.oio.main {
requires java.logging;
requires de.oio.util;
}
module de.oio.util {
exports de.oio.util;
}
module java.base {
exports java.lang;
exports java.util;
[...]
}
implizit
explizit
module java.logging {
exports java.util.logging;
}
explizit
32
Transitive Abhängigkeiten
module de.oio.m1 {
requires de.oio.m2;
}
module de.oio.m2 {
requires de.oio.m3;
}
module de.oio.m3 {
exports de.oio.m3;
}
31
32
17
33
Transitive Abhängigkeiten
module de.oio.m1 {
requires de.oio.m2;
}
module de.oio.m2 {
requires transitive de.oio.m3;
}
module de.oio.m3 {
exports de.oio.m3;
}
34
Module und Reflection
module de.oio.main {
requires de.oio.util;
}
module de.oio.util {
exports de.oio.util;
}
33
34
18
35
Module und Reflection
module de.oio.main {
requires de.oio.util;
}
module de.oio.util {
exports de.oio.util;
opens de.oio.util;
}
• Relativ einfache Moduldeklaration
• einfacher initialer Migrationspfad
• Ein abstrakter Datentyp existiert nur einmal
• Toolsupport scheint sich schnell zu entwickeln
• DI und Reflection konzeptionell bearbeitet
36
JPMS – Vorteile
35
36
19
• Alle Module müssen auf den gleichen abstrakten Datentypen aufbauen
• keine Versionierung
• keine Laufzeitaustauschbarkeit von Modulen
• Bisher wenig reale Praxiserfahrung
37
JPMS – Nachteile
③
Post-Monolith
38
37
38
20
39
③
Modularisierung über Prozessgrenzen
Anwendung mit 3 Bausteinen
40
39
40
21
41
Deployment auf einem Server
Anwendung mit 3 Bausteinen
42
Anwendung mit 3 Bausteinen
Baustein wird 4 mal benötigt
41
42
22
43
Anwendung mit 3 Bausteinen
Nachteile
wird nur 2 mal benötigt
Änderung an erfordert Reploy von
Baustein wird 4 mal benötigt
44
Unabhängige ArtefakteAnwendung mit 3 Bausteinen
Baustein wird 4 mal benötigt
43
44
23
45
Unabhängige Artefakte
Flexible Skalierung auf 3 Server
Anwendung mit 3 Bausteinen
Baustein wird 4 mal benötigt
46
Unabhängige ArtefakteVorteile
Isolierte Entwicklung
Isolierte Fehler
Isoliertes Deployment
Flexible Skalierung
…
Flexible Skalierung auf 3 Server
45
46
24
47
Unabhängige ArtefakteNachteil
Kommunikation über
Prozess- und Netzwerkgrenzen
Verteilte Datenverarbeitung
Flexible Skalierung auf 3 Server
48
Kommunikation
asynchron synchron
47
48
25
49
Asynchrone Kommunikation
Entkoppelt Sender und Empfänger
Verhindert Fehlerketten
Sender muss nicht warten
Barista
50
Kunde BecherwarteschlangeKassierer
Ausgabe
http://www.enterpriseintegrationpatterns.com/ramblings/18_starbucks.html
„Starbucks Does Not Use Two-Phase Commit”
49
50
26
KafkaTopic
Container
JAR
Container
JAR
Kubernetes Pod
Container
JAR
Container
JAR
Kubernetes Pod
52
Post-Monolith – Vorteile
SkalierungAustauschbarkeit
51
52
27
53
Post-Monolith – Nachteile
8 Irrtümer der verteilten Datenverarbeitung
Netzwerk ist ausfallsicher
Latenzzeit = 0
Datendurchsatz ∞
Netzwerk ist sicher
Netzwerktopologie ist stabil
1 Netzwerkadministrator
Kosten des Datentransports = 0
Netzwerk ist homogen
Bill Joy, Tom Lyon, L Peter Deutsch und James Gosling
54
Post-Monolith – Zielarchitektur
Router Service
Product Service
Meta Info Service
Search Service
53
54
28
55
Fazit
• Java bietet etwas, aber für manche Anwendungsfälle zu wenig
• Über einen längeren Zeitraum haben sich viele mit Build-System-Modularisierung beholfen
• JPMS löst uns einige der alten Probleme
• Post-Monolithe bringen viel Nutzen, das allerdings zu hohen Kosten
56
Fazit
55
56
29
• Modularisierung nur bei konkretem Nutzen und nicht zum Selbstzweck
• Modularisierung kostet Geld! Nachträglich wird es noch teurer
• Modularisierung muss in Zeiten von Microservices trotz aller Agilität Up-Front eingeplant werden
• Vgl. „The First Cut Is The Deepest”
57
Fazit
Fragen?
58
57
58
30
Vielen Dank für Ihre Aufmerksamkeit!
59