Latest / Coding Buddies | Tech & Dev-Mindset / #130 Monolith vs. Microservices – Dein Architektur-Check

Transcript

#130 Monolith vs. Microservices – Dein Architektur-Check · Coding Buddies | Tech & Dev-Mindset

0:00
Es gibt den Begriff bin ich der Meinung, das heißt glaube ich
0:02
Micro Frontend oder so. Lass mich nicht lügen, habe ich
0:07
bitte lügen. Nicht im Podcast Coding Buddies.
0:10
Dein Podcast rund um Softwareentwicklung und
0:12
aktueller Tech News herzlich Willkommen.
0:27
Halli Hallo und herzlich Willkommen zur neuen Folge vom
0:30
Coaling Buddies Podcast. Ich begrüße Dich ganz herzlich
0:33
zur neuen Folge, wie ich gerade meinte und natürlich auch
0:36
logischerweise den Tino hier an meiner Seite, der auf gar keinen
0:38
Fall fehlen darf und deswegen Tino was geht ab jetzt hab ich
0:42
dir deine Frage geklaut, aber egal was geht.
0:44
Ab Moin Moin fabi, ja was geht denn ab?
0:49
Also krass, dass du mir einfach meine Frage klaust.
0:51
Ich musste kurz ganz spontan reagieren, was ich darauf
0:53
antworte und ich frag einfach zurück, was geht ab den
0:56
Signature musst du mir lassen. Ja tut mir leid, tut mir leid,
0:59
manchmal weißt du manchmal kann ich nicht anders so was.
1:04
Geht ab, ist halt auch in meinem Sprachgebrauch einfach auch
1:07
dabei. Deswegen ja, aber es ist
1:11
natürlich ist natürlich dein Ding im Podcast, das verstehe
1:13
ich. Bestimmt also bitte ja.
1:16
OK, gut, lass das nicht zur Krise ausbrechen hier, sondern
1:19
lass weitermachen und ich beantworte dir die Frage, was
1:22
geht ab. Mir geht es sehr gut, mir geht
1:24
es sehr sehr gut, ich hab richtig Bock auf die Folge ich
1:28
glaub du hast auch n spannendes Thema mitgebracht, das kommt ja
1:32
aus deiner Feder sagt man das so?
1:34
Ja ich glaube und ich hab Bock da mit dir drüber zu sprechen,
1:37
aber bevor wir so richtig reinstarten mit dem Thema.
1:41
Noch mal ganz kurz die Anmerkung, Wieso oft jetzt schon
1:44
in den Folgen auch jetzt noch mal die Erinnerung an das kleine
1:48
Glöckchen, falls ihr das zum Beispiel bei Spotify findet und
1:52
auf unseren Podcast geht, dann gibt es da so ne kleine Glocke,
1:54
dann könnt ihr quasi. Benachrichtigung anschalten
1:57
immer wenn ne neue Folge rauskommt ja OK, sie kommt jetzt
2:00
schon die ganze Zeit immer Donnerstag 18:00 Uhr, das wisst
2:03
ihr natürlich, aber so als kleiner Reminder könnt ihr dann
2:07
Benachrichtigung bekommen, also drückt da ruhig mal drauf.
2:09
Dann wird wirklich keine Folge mehr verpasst.
2:10
Dann wird auf keinen Fall ne Folge verpasst.
2:12
Und falls euch der Podcast gefällt, hier auch noch mal den
2:15
Reminder. In den Shownotes findet ihr
2:16
einen Link zu einer Spendenseite, falls ihr uns
2:18
unterstützen möchtet, dann vielen vielen Dank dafür, Leute.
2:22
Das ehrte uns und das freut uns und deswegen dafür schon mal
2:25
vielen, vielen Dank. Ja, auf jeden Fall.
2:27
Und ich, wenn wir gerade beim Dankeschön sind, möchte ich mich
2:30
auch generell noch mal bei allen Hörern und Hörerinnen bedanken,
2:34
die hier immer so fleißig mithören uns.
2:37
Das ehrt uns natürlich und das freut uns total, dass wir auch
2:40
regelmäßig mal schöne ich sag mal Kommentare bekommen auf
2:44
verschiedenen Plattformen, zum Beispiel auch bei Twitch oder
2:46
so, dass euch der Podcast gefällt, dass ihr uns auch durch
2:49
den Podcast zum Beispiel gefunden habt und so.
2:51
Das ist deswegen auch noch mal da in die Richtung ganz, ganz
2:53
großen lieben Dank, freut uns mega, ja absolut fabi und vor.
2:57
Allem auch danke fürs Feedback zu folgen.
2:59
Ja, also das finde ich halt mega, wenn wir noch so
3:02
Anmerkungen kriegen, Ergänzungen, auch
3:04
Themenvorschläge das. Ich mein, dieser Community
3:08
Gedanke ist der Grund, warum wir coaling Buddies auch ins Leben
3:10
gerufen haben und das Macht die ganze Sache ja nur noch umso
3:13
besser. Also vielen vielen Dank auch
3:14
dafür, absolut. Und da würde ich sagen, damit
3:18
wir jetzt auch noch mal n bisschen in die Podcast Folge
3:21
eintauchen können, haben wir ja heute das n neues Thema was ich
3:25
so n bisschen mitgebracht hab beziehungsweise was heißt
3:27
mitgebracht. Wir machen das ja mal so, dass
3:30
wir irgendwie ne wir brainstorm mehr beide so welche Folge wir
3:33
vielleicht mal wieder haben wollen kriegen von euch auch
3:34
manchmal n paar Ideen. Diesmal geht es jetzt um
3:38
Microservices versus Monoliten, Monoliten versus Microservices.
3:42
Wie auch immer ne, also eigentlich n Thema, was ja in
3:45
vielen Teams auch immer mal wieder diskutiert wird,
3:47
zumindest kenn ich das auch aus der Vergangenheit, zumindest zum
3:51
Beispiel, dass es da auch immer mal so ne kleine Diskussion gab.
3:54
Wie macht man es jetzt, sollte man vielleicht das die Software
3:58
als Monolith. Bauen oder als Microservice
4:01
beziehungsweise sollte man den Monolith aufspalten in ein in in
4:05
Microservices und so weiter das heißt es geht ja heute n
4:09
bisschen um Architektur. Genau.
4:11
Also es geht jetzt mal nicht so um Coding Pattern zum Beispiel,
4:14
sondern wirklich um Architekturentscheidung in dem
4:18
Softwareprojekt, und das sind jetzt 2 Ansätze, die wir da
4:22
jetzt quasi besprechen wollen, die auch gegensätzlich sind.
4:27
Haben aber beide natürlich ihre vor und Nachteile und also die
4:30
sie mitbringen. Ne diese Ansätze und es wäre
4:33
natürlich cool, wenn wir genau das heute mal beleuchten.
4:36
Fabi, Was sind die vor und Nachteile?
4:38
Ich könnte mir vorstellen ich ich guck dich an und ich seh es
4:41
in deinen Augen, dass du auch schon wieder irgendwie ne
4:43
Analogie bei hast, weil du grinst schon so, du freust dich
4:45
schon so richtig diese Analogie zu bringen und als Fazit würde
4:51
ich es sehr spannend finden. Wenn wir irgendwie zu dem Punkt
4:54
kommen, wann eignet sich wann was, wann eignet sich, welcher
4:58
Ansatz so? Das wäre der richtige Satz
5:01
gewesen. Ja, genau.
5:04
Definitiv. Ich lach übrigens, das ist das
5:06
das das trägt sich gegenseitig, weißt du wenn du von Analogie
5:10
redest, dann muss ich schon wieder lachen und deswegen
5:12
denkst du, dass ich schon, dass ich lache, weil ich schon wieder
5:14
ne Analogie was ist das? Freuen uns einfach, dass wir uns
5:18
sehen, hier durch den Bildschirm fahren.
5:20
Du kannst es ruhig ehrlich sein, natürlich natürlich nee, aber
5:22
Analogie natürlich. Ich find wie gesagt ich find
5:26
Analogien sind eigentlich immer ganz angenehm, kann man sich
5:28
vielleicht einmal grob vorstellen worum es überhaupt
5:30
geht, sozusagen ne, auch wenn man vielleicht gerade gar nicht
5:33
so richtig im Thema drin steckt und.
5:36
Wenn wir jetzt diese diese Monolithen und Microservices mal
5:41
so als uns als Häuser vorstellen, dann gibt es ja zum
5:44
Beispiel weiß nicht, es gibt ja so reihenhaussiedlungen, ne und
5:48
es gibt jetzt zum Beispiel auch weiß nicht so riesengroße
5:52
Häuser, wo ganz viele Leute drin wohnen, ne, also du hast.
5:55
Da so Mehrfamilienhäuser. Genau, Mehrfamilienhäuser.
5:58
Ja, ich stell mir jetzt was richtig Großes vor.
6:00
Weißt du so 1 wo einfach keine Ahnung 100 Wohnungen drin sind
6:03
still so n Wolkenkratzer n. Müllabbau.
6:07
Genau, den Plattenbau in New York.
6:11
Ja oder halt ne. Wie gesagt so so einfach so
6:13
Reihenhäuser, so ne ganze Siedlung wo mal ganz viele
6:15
kleine Häuser sind weißt du ja, aber halt dann eben
6:18
Einfamilienhäuser und im Endeffekt wenn du jetzt sagst OK
6:24
du hast jetzt ne diese beiden häuserarten ne kann man sich ja
6:29
vielleicht schon vorstellen OK was von beiden ist jetzt
6:31
eventuell so der Monolith von beiden?
6:37
Guckst und fragst. Ich denke an das ist ne Antwort.
6:39
Ja, das ist ja dann auf jeden Fall das Mehrfamilienhaus ne,
6:43
weil du ja jetzt viele Parteien unter einem Dach hast sozusagen.
6:46
Ja genau. Und wenn du jetzt zum Beispiel
6:49
sagst, OK, du willst irgendwie deinen Nachbarn besuchen, dann
6:51
musst du ja das Haus nicht verlassen.
6:53
Wenn du jetzt. Weiß ich nicht.
6:56
Sagst irgendwie das Dach ist undicht, ne oder irgendwo keine
6:59
Ahnung. Regnet es rein, dann hast du ja
7:02
womöglich n Wasserschaden, nicht nur in einer Wohnung, sondern
7:06
vielleicht in mehreren Wohnungen, vielleicht im Worst
7:08
Case im ganzen Haus. Und wenn du jetzt aber zum
7:10
Beispiel sagst, ja OK, ich möchte jetzt vielleicht das Haus
7:13
streichen, dann fängst du ja im Normalfall auch nicht an zu
7:15
sagen, OK, ich streich jetzt nur meine eigene Wohnung n bisschen,
7:18
so mach ich mal weiß, sondern wird ja im Endeffekt das gesamte
7:21
Haus gestrichen, ne? Also ja, gerade wenn es um
7:24
Fassade geht, ne, dann fängst du ja nicht an, nur auf Höhe einer
7:27
Etage das zu streichen genau, sondern das ganze Haus sozusagen
7:31
ne. Richtig genau.
7:32
Und da gegenüberstehend jetzt, wenn du das so siehst, hast du
7:36
dann dann als sozusagen die Repräsentation der
7:38
Microservices? Werden dann diese
7:40
Reihenhaussiedlung ne oder was weiß ich?
7:42
Nimm ne Siedlung mit kleinen Häusern wie auch immer, ist
7:44
eigentlich auch egal, aber da ist es ja so, dass zum Beispiel
7:47
du hast. Ein also jedes Haus hat n
7:51
eigenen Eingang, ne bei dem großen Haus kommst du ja immer
7:53
durch den gleichen Eingang unten rein, da hast du auch unten
7:56
immer den gleichen Schlüssel. Wie gesagt alle wohnen im
7:58
gleichen Haus, wenn du deinen Nachbarn besuchen willst, musst
8:00
du nicht mal das Haus verlassen, in dem Fall von den kleinen
8:02
Häusern der Siedlung, da musst du halt dein Haus irgendwie
8:04
verlassen und wenn jetzt zum Beispiel sowas wie n
8:08
Stromausfall ist bei einem Haus, dann hast du es ja nur in dem
8:11
Haus und nicht in dem anderen also ich geh jetzt mal davon
8:13
aus, dass wir jetzt nicht irgendwie n flächendeckenden
8:14
Stromausfall in der ganzen Stadt haben.
8:16
Ja. Kein Blackout so komplett genau.
8:19
Und weiß ich nicht. Wenn du jetzt genau das gleiche,
8:22
du willst dein Haus streichen, du kannst dein Haus streichen,
8:24
du musst aber nicht noch das Haus vom Nachbarn streichen und
8:26
wenn du, weil sie nicht sagst, OK du hast n undichtes Dach, ja
8:29
dann hast du leider n undichtes Dach, aber dein Nachbar nicht
8:31
zwangsläufig ne, das heißt es ist halt das eine.
8:34
Dieser Monolith ist halt alles grob gesagt in einem drin, da
8:38
ist alles quasi verpackt in einem großen Paket und bei den
8:42
bei der Reihenhaussiedlung, da hast du halt die das sind die
8:44
Microservices, da sind halt alles kleine und.
8:46
Pakete und jedes Paket steht irgendwo für sich und macht halt
8:50
so sein Ding. Ne?
8:51
Ja, das ist eigentlich ne ganz coole Analogie, also gehen wir
8:55
noch mal davon aus. Man betrachtet also wir als
8:59
Softwareentwickler oder wir, die an einem Softwareprojekt
9:01
arbeiten, ne sind so gesehen die Besitzer dieser Häuser, ne hab
9:06
ich jetzt dieses Mehrfamilienhaus oder diesen
9:08
Plattenbau, wo jetzt so ganz viele Familien drin wohnen oder
9:11
halt so ne Siedlung und ich hab einzelne Häuser die getrennt
9:14
sind voneinander aber mein. Also mein Eigentumssinn ne mein
9:18
Komplex abbilden für diesen einzelnen Familien dann und das
9:22
find ich, zeigt halt schon auch gut vor und Nachteile ne es ist
9:26
ja sowohl vor als auch n Nachteil in so einem
9:28
Mehrfamilienhaus, dass alle Parteien davon betroffen sind
9:33
was ich mache ne beispielsweise ich Streich die Fassade neu.
9:38
Ja. Es ist natürlich n großer
9:40
Aufwand, weil es n großes Haus ist.
9:41
Allerdings. Alle Parteien da drin haben
9:44
jetzt n Haus mit einer neuen Fassade, was frisch und schön
9:46
aussieht, beispielsweise die Solaranlage die aufs Dach kommt.
9:52
Ne kannst du halt auch für alle Parteien nutzen, dann
9:54
beispielsweise ne. Also alles so Sachen auch
9:58
Erneuerung, Erweiterung betrifft immer alle Parteien da drin
10:02
Vorteil Nachteil es geht was kaputt, dann geht es für alle
10:06
kaputt wie du ja meintest. Und das ist genau im
10:11
Umkehrschluss, also quasi schon gegensätzlich bei dieser
10:15
Siedlung. Ja, wie du meintest, wenn ein
10:18
Haus kaputt ist, sind die anderen noch heile, wenn ich 1
10:21
aber saniere, sind die anderen immer noch alt so, und das finde
10:25
ich verdeutlicht schon sehr gut das Konzept oder beispielsweise
10:28
noch weil das später n großes Thema wird.
10:31
Ich möchte jetzt alle Parteien im Haus benachrichtigen, dass
10:35
Umbaumaßnahmen stattfinden, oder?
10:37
Einfach so n Newsletter hinhängen sag ich mal ne, dass
10:41
irgendwas passiert, dann kann ich in diesem großen
10:44
Mehrfamilienhaus ja unten nen Aushang machen, Zettel und alle
10:48
gehen dran vorbei, weil sie ja über das gleiche Treppenhaus
10:50
oder über den gleichen Eingang kommen und können den Lesen.
10:53
Ja wenig Aufwand geht schnell. Wenn ich jetzt aber ne Siedlung
10:57
hab mit 1015 Häusern muss ich jetzt überall so n Zettel im
10:59
Briefkasten werfen. Ja, wenn du es per Post
11:02
Versendest Ey Post ist teuer geworden.
11:04
Porto ist. Das ist halt so.
11:06
Ist halt wirklich so, aber weißt du, da hast du halt den Aufwand
11:10
um alle zu informieren, musst du natürlich auch zu jedem
11:12
einzelnen gehen, dann ja klar ja, also ich geh jetzt nicht
11:15
davon aus, dass du einfach so n Zettel an der Tür nagelst.
11:18
Deswegen mal in n Briefkasten geworfen und das sind halt auch
11:22
so diese unterschiedlichen Konzepte die sich auf die
11:24
Softwareentwicklung übertragen lassen.
11:26
Ja. Ja, auf jeden Fall finde ich.
11:29
Auf jeden Fall waren auch noch mal gute Beispiele dabei, wenn
11:32
wir uns jetzt zum Beispiel angucken, OK, was ist jetzt
11:34
wirklich, wenn wir jetzt auf die technische Ebene gehen, was ist
11:37
eigentlich dann Monolith? Ich glaube, es ist schon n
11:39
bisschen klar geworden, würde ich sagen, wo wo es da hingeht,
11:43
trotzdem noch mal so, um es auf n Punkt zu bringen ist es ja am
11:48
Ende Monolith ne Anwendung die als einzige.
11:53
Sag ich jetzt mal zusammenhängende Codebasis
11:55
entwickelt und übertrieben wird, so könnte man es ja eigentlich
11:57
sagen. Ne ja bedeutet also du hast mehr
12:01
oder weniger alles in einem Projekt.
12:02
Du hast vielleicht ne gemeinsame Datenbank an der Stelle
12:05
beispielsweise und das Deployment oder ich sag mal
12:09
changes für deine Anwendung betrifft immer die komplette
12:12
Anwendung ja also wenn du jetzt sagst OK du hast n.
12:15
Ne Webanwendung. Ich find daran kann man es
12:17
irgendwie mal wunderbar erklären, weil du da halt
12:19
wirklich so einfach auch du hast so mehrere Komponenten, ne.
12:21
Du hast dann vielleicht ne Datenbank, du hast n Backend, du
12:23
hast n Frontend. Wenn du aber alles irgendwie
12:26
zusammen in einem Knödel hast, ne, dann ist es ja so, dass
12:31
sagen wir mal, du veränderst irgendwie was an an deiner
12:34
Website allein schon sagen wir mal nur irgendwas an der UI soll
12:38
n bisschen anders aussehen, ne, aber die Funktionalität bleibt
12:40
an sich irgendwie die gleiche. Und du veränderst das und willst
12:44
jetzt aber diese Änderung sozusagen an den User die Userin
12:48
bringen, dann hast du ja quasi den den Effekt, dass du halt
12:52
sagst. OK, pass auf, dadurch, dass du
12:53
alles in einem Projekt hast, musst du das gesamte oder wird
12:57
das gesamte Projekt deployed, das heißt du hast irgendwo auch
13:01
vielleicht ne im worst case sag ich jetzt mal vielleicht auch ne
13:04
Downtime von deinem Backend, weil das Backend kurz einmal neu
13:08
deployed wird, ne, je nachdem wie deine Infrastruktur
13:10
aussieht, aber. Du hast eigentlich nichts am
13:12
Backend geändert, aber dein Backend wird mit deployed ne so
13:15
das meine ich damit. Es ist halt sehr eng gekoppelt
13:18
dann einfach. Genau richtig und Microservices.
13:22
Da sieht es ja dann tatsächlich auch einfach anders aus, ne?
13:26
Ja, also der Grundgedanke von den Microservices ist ja, dass
13:30
ich ne Anwendung in viele oder sagen was heißt vieles immer
13:34
projektgrößen abhängig ja, aber in ich sag mal viele kleine
13:37
unabhängige Services unterteile. Die jeweils einen
13:41
Funktionsbereich abdecken. Ja, also das heißt, ich mach mir
13:45
jetzt mein ganzes Projekt so mundgerecht in Häppchen und
13:51
alles erfüllt so seine Aufgabe und wird miteinander verknüpft,
13:55
dass sie zwar autark leben können, aber im gesamten mein
13:58
komplettes Projekt in der Funktionalität abbilden, genauso
14:00
wie der Monolith. Ja.
14:02
Also so n ganz einfacher schnitt, wie du ihn gerade
14:05
genannt hast, wär mein Frontend ist einzeln, mein Backend ist
14:08
einzeln und die Datenbank wird auch zum Beispiel einzeln
14:10
verwaltet. Ja beispielsweise das ist jetzt
14:14
sehr grob geschnitten, das geht natürlich noch viel feiner ne n
14:17
Frontend hat ja auch verschiedene Funktionalitäten am
14:21
Ende wieder ne, also n Frontend kann ja in mehreren Bereichen
14:24
auch unterteilt werden, was ja auch Sinn macht, wenn ich den
14:26
Microservices. Ansatz verfolge, da kommen wir
14:29
bestimmt später noch mal bei den Vorteilen, denn noch mal genauer
14:31
hinzu, ich meine, wir haben auch in vergangenen Folgen da schon
14:35
mal so n Beispiel gebracht, was wir aufgreifen können.
14:37
Erinner mich dran, dass ich dran denke bis später.
14:42
Genau. Und der Vorteil dabei ist,
14:43
beziehungsweise was das heißt am Ende, dass du diese einzelnen
14:47
Services, diese einzelnen Bestandteile natürlich auch
14:49
einzeln deployen kannst. Wenn ich jetzt am Frontend was
14:52
ändere, dann muss ich diese Änderung deployen und den Kunden
14:56
zur Verfügung stellen. Aber ich habe keinen keinen
14:59
Effekt, sag ich mal aufs Backend, also am Backend
15:01
passiert nichts, da wird nicht ne neue Version erzeugt, die im
15:04
Endeffekt die gleiche ist wie vorher sozusagen.
15:07
Ja, es ist bleibt halt einfach der gleiche stand.
15:10
Und ich hab halt den Vorteil, dass ich die einzelnen Services
15:14
auch mit der Datenhaltung beispielsweise so verwenden
15:17
kann, was sie auch wirklich nur brauchen.
15:18
Sie sehen halt nur Sachen, die sie brauchen und sie verwenden
15:21
nur Sachen, die sie brauchen. Ja, also ich kann das halt
15:23
wirklich autark leben lassen und hab keine große Kopplung mehr,
15:28
das alles zusammenhängt, was du damit aber dir einkaufst und das
15:33
hat man an dem Newsletter Beispiel in der Analogie
15:36
gesehen. Ich muss natürlich für
15:39
Kommunikation zwischen diesen Services sorgen, weil es ja
15:42
jetzt nicht mehr ein großer Blob ist, sondern kleine
15:46
Bestandteile, die aber ja Daten austauschen müssen, die
15:49
informiert werden müssen, damit das große Ganze auch
15:51
funktioniert. Ja, ja, auf jeden Fall.
15:54
Hast du da vielleicht so n Beispiel noch?
15:56
Also wir, wir hatten ja. Glaube ich schon öfter mal für
16:00
so. Also haben wir jetzt glaube ich
16:02
weiß gar nicht, ob wir das explizit gesagt hatten, aber in
16:04
ein oder mehreren Folgen, die wir früher, also ne alten Folgen
16:08
haben wir auf jeden Fall schon mal das Beispiel von E Commerce
16:10
System genommen. Ich finde daran kann man das
16:12
eigentlich immer ganz angenehm erklären, wie jetzt zum Beispiel
16:15
Microservices vielleicht, wie man sich das vorstellen kann,
16:18
also du hast ja im Endeffekt. Du gehst ja auf irgend ne Seite
16:21
ne so, dann hast du vielleicht zum Beispiel deinen Frontend als
16:25
kleinen Service irgendwie. Du meintest ja n Frontend muss
16:28
nicht auch unbedingt ein. Ich nenne es jetzt mal Service
16:32
sein, also ein Microsoft. Es gibt es gibt den Begriff bin
16:35
ich der Meinung, das heißt glaube ich Micro Frontend oder
16:38
so, lass mich nicht lügen, habe ich bitte lügen.
16:42
Nicht hier im Podcast habe ich. Auf jeden Fall mal mal von
16:45
gehört, wollte ich mich auch noch mal ein bisschen genauer
16:47
mit auseinandersetzen, habe ich aber auch noch nie
16:48
mitgearbeitet, finde ich aber auch eigentlich ganz spannend,
16:50
aber angenommen du hast jetzt das Frontend einfach als ganzes
16:53
und du greifst darauf zu, das wird halt angezeigt, du holst ja
16:56
aber deine Daten von den einzelnen Services, zum Beispiel
16:59
die Produkte, du hast irgendwelche.
17:00
Irgendwo ne Produktpalette wo du halt in deinem E Commerce
17:04
Service halt irgendwas suchen kannst.
17:05
Ne, das heißt du greifst auf diese Datenbasis zu, wo du dein
17:08
Produkt hast, wo du sagst, OK diese Produktpalette hab ich
17:11
halt eben und die kann ich jetzt anzeigen.
17:12
Wenn du jetzt weitergehst und sagst ich pack mir das jetzt in
17:15
den Warenkorb, dann sagt der Warenkorb zum Beispiel alles
17:17
klar, ich hab jetzt irgendwie diese waren bei mir drin ne das
17:21
ist vielleicht ein anderer Service.
17:24
Als zum Beispiel der Service, der dann dahinter steht und zum
17:28
Beispiel die Möglichkeit der der Suche in diesen Produkten
17:31
anbietet. Und du hast vielleicht noch
17:33
einen nächsten Service, der dir zum Beispiel sagt, OK, wenn du
17:35
jetzt aber wirklich bezahlen willst, dann läuft der die
17:38
Zahlungsabwicklung halt eben über noch einen separierten
17:40
Service, um sich das vielleicht noch mal ein bisschen besser
17:44
vorstellen zu können, weil wir gesagt haben, wieso deployed man
17:47
jetzt zum Beispiel, wenn du jetzt.
17:48
Ne, wenn das jetzt n Monolith wäre.
17:50
Wir können ja auch sagen, ein Monolith oder Microservices, du
17:53
kannst ja die gleiche Anwendung, kannst du ja in beiden
17:56
Architekturen irgendwie abbilden, ne, also du kannst ja
18:01
sagen OK ich ich pack alles zusammen, es ist jetzt zum
18:04
Beispiel ein Backend zum Beispiel n Spring Boot Backend
18:06
nur mal so als Beispiel ne und da hast du jetzt den Warenkorb
18:10
drin, du hast den Bezahlservice da drin und du hast da
18:12
vielleicht irgendwie noch ne diese den.
18:15
Ist dein deine deine Datenbasis mit den ganzen Produkten da drin
18:17
und so weiter ne alles zusammen in einen Topf geworfen und das
18:23
Frontend zum Beispiel ist auch noch mit da drin und das ist
18:25
alles n Repository oder es sind alles unterschiedliche
18:28
Repositories auf denen du einzelne Changes machen kannst,
18:30
an denen auch wiederum ne einzelne Pipeline zum Beispiel
18:33
hängt. So als so kann man sich das ja
18:35
zum Beispiel auch vorstellen, dass man sagt, OK, das ist halt.
18:39
Diese auch irgendwo ne gewisse Art von Kopplung der Datenbasis
18:44
deiner Repositories und so weiter ne um halt eben bei
18:47
Changes zum Beispiel bei Monolithen alles gleichzeitig zu
18:50
deployen oder microservice einzeln so ne, weil weiß nicht
18:54
ob das so rübergekommen ist vorher, aber das ist mir gerade
18:56
noch so eingefallen. Ja, ist auch gutes Beispiel.
18:59
Ich find auch gut, dass du das E Commerce Beispiel genommen hast,
19:01
weil das was ich jetzt gerade im Kopf hatte war sehr ähnlich.
19:04
Wir hatten ja mal so über Lieferdienste gesprochen und
19:06
dann auch gesagt, dass das ja so unterteilt ist, damit du halt
19:10
nicht immer strenge Kopplung hast.
19:11
So wie. Ja, du kannst jetzt nur mit
19:12
Paypal bezahlen, so nach dem Motto und da bietet sich dann
19:15
halt auch so ne Architektur einfach an.
19:16
Ne, dass du sagst, OK, ich hab Microservices wie n Bezahlsystem
19:21
wie n lokalisierungssystem und so weiter und also Service ich
19:25
hab jetzt System gesagt, das sind ja Services für n
19:27
Gesamtsystem. Da.
19:29
Genau, aber. Welche vor und Nachteile ist
19:33
eigentlich immer der spannende Punkt?
19:35
Ne, weil man muss ja jetzt sagen OK ich hab n neues projekt ich
19:39
hab n Kontext ne ich weiß was grob also man weiß nie was zu
19:44
100% implementiert werden muss, das ist die Realität aber ich
19:47
hab so ne grobe vor also Vorstellung was erledigt werden
19:50
muss und soll jetzt ne Architekturentscheidung zum
19:53
Beispiel treffen dann muss man ja abwägen was sind jetzt so die
19:56
vor und Nachteile da würde ich gerne mit dir drüber sprechen
19:59
magst du mal? Mit dem monoliden Ansatz mal
20:02
anfangen welche Vorteile du da drin siehst und welche
20:06
Nachteile. Ja, gerade weil wir eben auch
20:09
gesagt hatten, dass man ja beides machen kann.
20:12
Ne, es ist ja auch wirklich interessant zu sagen, OK, wann
20:15
kann man denn vielleicht was verwenden, weil ich finde, wenn
20:18
man sich das erst mal anhört, so ganz objektiv.
20:23
Und vielleicht das zum ersten Mal hört, finde ich.
20:25
Klingt Microsoft ist irgendwie cooler, dass man nicht so sagt,
20:27
so OK, warum soll ich denn Monolithen nehmen, wenn da alles
20:31
irgendwie eng gekapselt ist? Du hast alles irgendwie ne weiß
20:35
nicht ist es. Irgendwie schwer wartbar
20:38
irgendwann ne, was jetzt beispielsweise n Nachteil ist,
20:40
wenn das Ganze wächst. Beispielsweise hab ich auch
20:43
schon selber erlebt, dass du irgendwann n Riesenprojekt hast,
20:45
wo du dir denkst, so boah, ich kann hier gar nichts mehr
20:47
anfassen, ohne dass irgendwie das eine vom anderen abhängt,
20:50
weil halt irgendwie sehr enge Kopplungen irgendwie stattfinden
20:54
oder es gibt halt eben genau durch solche engen Kopplungen
20:56
oder so von verschiedenen, Ich nenn es jetzt mal Services in
21:00
Anführungsstrichen, die im Monolithen gekapselt sind.
21:03
Dass da irgendwie Seiteneffekte oder Side Effects auftreten
21:05
weißt du, das ist halt das sind natürlich Nachteile, die relativ
21:08
schnell auftreten können, wenn du alles irgendwie miteinander
21:10
verwurstelt hast, ne, was aber n Vorteil natürlich ist, ist,
21:15
dass. Du eigentlich n bisschen
21:17
einfacher starten kannst und das ganze Setup ne du sagst OK, ich
21:20
nehm mir jetzt ein Repository, ich baller da jetzt in dem
21:23
Beispiel was wir hatten in Frontend rein Backend was auch
21:25
immer das ist alles da drin und du musst jetzt jetzt zum
21:30
Beispiel nicht gleich ne riesen Infrastruktur aufbauen ne weil
21:34
mit Microservices hast du ja irgendwo auch dann ist jetzt n
21:39
bisschen Spoiler Alert sorry aber du hast natürlich n
21:42
bisschen mehr Overhead ne bei der ganzen Infrastruktur kommen
21:45
wir ja gleich noch mal drauf. Und es ist natürlich auch von
21:48
Vorteil, dass du halt dadurch, dass du n gemeinsamen Code hast,
21:52
erleichtert es dir auch am Anfang.
21:54
Und ich sag jetzt extra am Anfang eines Projektes natürlich
21:56
auch die Zusammenarbeit ne, weil du halt gerade wenn jetzt zum
22:00
Beispiel irgendjemand neu ins Team kommt, sagst, OK, das ist
22:02
unsere Codebasis, bitteschön. Wie gesagt, wenn es größer wird,
22:07
irgendwann schwer wartbar und schwer handelbar.
22:09
Irgendwann weil wenn es riesengroß ist, hast du
22:10
natürlich irgendwann den Punkt, dass irgendwann wer reinkommt
22:12
und sagt, Boah, ist ja super viel, keine Ahnung, check ich
22:14
nicht wo fang ich denn jetzt an so ne.
22:17
Genau. Wo muss ich denn überhaupt jetzt
22:19
im Repository nachschauen? Wo geht es denn hier los?
22:22
Genau das sind halt auch schon sehr, sehr wichtige Punkte, ne
22:25
am Start bietet sich das, also fühlt sich das natürlich erstmal
22:29
richtig an, weil du wie ja meintest microservice Ansatz
22:33
bedeutet. Overhead, weil du ja auch diese
22:35
Kommunikation aufbauen musst. Ja, du musst ja, du hast ja dann
22:38
einzelne Services, die aber irgendwie vernetzt werden müssen
22:40
und miteinander arbeiten und kommunizieren müssen.
22:42
Da ist natürlich der Monolithenansatz erstmal
22:45
praktischer, ne weil was auch n großer Punkt ist.
22:48
Und das darf man auch nicht unterschätzen, weil das auch
22:50
wirklich n Vorteil ist. Wenn ich jetzt mein ganzes
22:54
Projekt zum Beispiel als Monolith Abbilde und ich mache
22:57
ne Änderung, beispielsweise wie du meintest vorhin am Frontend,
23:01
kann es sein, dass das Backend nicht betroffen ist.
23:04
Ne und so gesehen ne neue Version kriegt was n Nachteil
23:07
wäre, weil es unnötig ist. Was aber auch Fakt ist, wenn ich
23:10
diese Änderung mache und das in meinen Monolithen mache und
23:14
teste, sehe ich natürlich auch. Muss ich denn am Backend was
23:18
ändern? Ne durch diese Kopplung hast du
23:20
natürlich auch den Vorteil Sachen nicht zu übersehen, sage
23:25
ich mal. Definitiv weißt du was ich
23:27
meine. Voll also, dass du einfach
23:29
sagst, warte mal, wenn ich das hier änder, ne, ich brauche
23:31
jetzt zum Beispiel mehr Daten im Frontend, Oh das das stellt das
23:35
Backend aber gar nicht zur Verfügung, das sehe ich dann
23:37
sofort, weil es halt nicht mehr zusammenpasst.
23:39
Ne, Na du hast ja zum Beispiel gerade ja auch von Kommunikation
23:42
gesprochen, ne und ich hatte tatsächlich auch schon mal den
23:46
Fall, also da hatten wir auch so n microservice Ansatz mal
23:50
benutzt, ist schon n paar Jahre her, da haben wir ich glaub das
23:53
waren so. 3. Microservices würd ich es jetzt
23:56
mal nennen oder? Im Endeffekt war es
23:59
wahrscheinlich eher noch so ne Art Monolith plus microservice
24:03
so aber Fakt ist auf jeden Fall, es waren auf jeden Fall 2 oder
24:08
ich glaub sogar 3 Komponenten die halt eben zusammengearbeitet
24:11
haben ne und wir haben uns halt eben um diese Komponenten
24:14
gekümmert und hatten dann irgendwie beispielsweise die
24:16
haben mit ich glaube über Rest kommuniziert.
24:20
Und da war es dann so, dass beispielsweise wir irgendwie an
24:23
der Restschnittstelle von unserem System zu unserem System
24:26
wiederum etwas geändert haben, aber nur auf der einen Seite,
24:29
dann haben wir uns irgendwann gefragt, das lief jetzt nicht
24:33
produktiv, aber auf einer Stage, wieso das nicht mehr
24:35
funktioniert oder warum der Fehler da auftritt, ne oder n
24:39
Fehler da den wir da. Sag ich mal identifiziert haben
24:42
haben wir dann irgendwie gemerkt, ja gut, OK hier
24:43
Monitoring war gut, alles alles schick, alles toll, haben wir
24:46
relativ schnell identifiziert, dass man, dass wir halt einfach
24:49
vergessen haben an der Stelle beim anderen Service was
24:52
anzupassen, aber es kommt halt relativ schnell vor.
24:55
Wie du meintest, du testest dein 1 System ab, du testest das
24:58
andere System ab, du hast da vielleicht irgendwo sag ich mal
25:01
n mog zu dieser Schnittstelle ne und hast vielleicht in dem
25:04
Moment aber nicht so n übergreifenden Test vielleicht
25:07
zwischen den verschiedenen Systemen und selbst wenn du
25:09
diese Tests hast, dann wird es meistens trotzdem auch immer n
25:12
bisschen komplexer. Ne ja, und dann natürlich n ganz
25:16
großer Faktor dabei ist, ich weiß jetzt nicht wie viele ihr
25:19
damals im Team wart und wie umfangreich das Projekt war. 6
25:23
Leute. 6 Leute. Ja, das ist ja aber noch
25:27
überschaubar von der Teamgröße. Also es sind schon also 6
25:30
Entwickler. Entwicklerinnen würde ich jetzt
25:31
mal denken, das ist schon ne gute Mannstärke oder Fraustärke
25:35
wie sagt man aber es ist kein Riesenprojekt oder kein riesen
25:42
Team. Ja und deswegen sag ich mal sind
25:44
dieser Monolitenansatz. Ist auch so n bisschen abhängig
25:48
wie erfolgreich der sein kann. Auch von der Skalierbarkeit.
25:51
Wieviel Leute arbeiten da drauf, wieviel Varianten gibt es von
25:55
diesem Projekt? Ja, also von dieser
25:57
Implementierung, ich find das ist n ganz ganz großer Punkt
26:00
dabei den man berücksichtigen muss ist es n relativ statisches
26:05
Projekt, das heißt ich hab so eine Anwendung, die hat zwar
26:07
viele Bestandteile aber es gibt nur diese Anwendung, es gibt
26:11
keine Variation dieser Anwendung.
26:14
Na und? Da arbeiten jetzt fest 6 Leute
26:16
dran, beispielsweise bei euch, dann dann ist das vertretbar,
26:21
das als Monolith zu machen, weil du die Vorteile dann haben
26:23
kannst und gar nicht so Riesen Nachteile hast am Ende.
26:27
Aber jetzt stell dir vor, du hast sowas wie austauschbare
26:33
Elemente da drin, ne Varianten zum Beispiel vom Frontend.
26:37
Ja also du hast. Du hast n normales Frontend?
26:40
Dann hast du noch ne mobile App und so weiter ne Desktop
26:42
application und so weiter wir gehen jetzt mal nicht von so
26:44
Cross Plattform Entwicklung aus. Ja sondern du machst das jetzt
26:46
nativ für alles und immer mehr und immer mehr und dann gibt es
26:49
Varianten, dann gibt es unterschiedliche Schnittstellen,
26:54
unterschiedliche Produkte und dann fächerst du irgendwie
26:57
dieses Projekt auf und versuchst das alles in den Monolithen rein
27:01
zu graben ja ja warte mal hier brauchen wir jetzt ne andere
27:05
Variante ja komm mach n Brunch auf.
27:07
Ja, so richtig jetzt. Jetzt gehen wir in die
27:08
Versionierung, machen Branch auf und dann haben wir n neuen
27:11
Entwicklungszweig, der auch nie wieder zusammenführt, weil die
27:13
komplett unterschiedlich voneinander jetzt entwickelt
27:16
werden, weil die einfach 2 Varianten sind, Variante A und
27:19
Variante B unseres Produkts beispielsweise und dann merkst
27:23
du es schon so mit dem Monoliten ey, jetzt haben wir das ganze
27:26
Riesenprojekt als 2 Varianten, obwohl sich 10% nur
27:31
unterscheiden, ja. Ne, aber ich mach das jetzt auch
27:34
nicht über irgendwie konfigurierbar oder so, das ist
27:36
einfach zu krass einfach ne das kriegst du nicht mehr gehandelt,
27:39
das skaliert nicht mehr. Also was machen wir jetzt und
27:42
dann kommt auch so n microservice Ansatz ins Spiel wo
27:44
du sagst na ja gut, aber wenn du einfach nur diesen Server also
27:46
wenn du das als einzelnen Server hättest und du tauschst den aus
27:51
ist doch alles cool ja also dann dann bau ich mir nur so n mein
27:55
Cluster anders aus und Tausch nur diesen kleinen Bestandteil
27:58
aus und schon funktioniert es alles wieder definitiv klingt ja
28:00
auch verlockend ne? Also lass uns mal so über vor
28:03
und Nachteile von Microservices reden.
28:05
Klingt sehr verlockend. Ja, also wie gesagt ne.
28:13
Also du hast ja gerade glaube ich gerade von Vorteil, die
28:16
Skalierbarkeit schon angesprochen, Teams können
28:21
unabhängig voneinander entwickeln und deployen, das ist
28:23
natürlich, weil du ja gerade meintest die Teamgröße ne spielt
28:25
natürlich da an der Stelle ne ne starke Rolle, klar und.
28:33
Ja, du kannst halt auch unterschiedliche Tech Stacks
28:35
benutzen. Vielleicht ne also weil du ja
28:37
gerade auch zum Beispiel meintest so du hast verschiedene
28:42
vielleicht Varianten und je nach Variante könnte es ja vielleicht
28:46
auch sein, dass du vielleicht, also ich meine jetzt Variante
28:48
ne, also im Sinne von von App du willst jetzt nicht eine Cross
28:51
Plattform App machen, sondern du nutzt halt vielleicht für jede
28:54
Anwendung, für den, für die jedes Frontend vielleicht eine
28:57
andere Technologie, ne. Und du kannst ja zum Beispiel
29:01
auch sagen, der Bezahltservice beispielsweise, der muss
29:04
unglaublich, ich sag jetzt einfach mal aus der Hüfte
29:08
geschossen, so sehr performant sein, was aber vielleicht n
29:11
anderer Service nicht unbedingt sein muss.
29:14
Demzufolge kannst du vielleicht auch unterschiedliche
29:15
Programmiersprachen nehmen, weil du halt sagst, OK, da hast du
29:18
vielleicht ne, ne ne höhere. Also du musst halt gucken was
29:21
für Anforderungen brauchst du denn für die verschiedenen
29:23
Services, kannst dann viel besser darauf dann das ganze
29:26
Anpassen, aber Nachteile hatten wir glaub ich auch schon so n
29:29
bisschen angesprochen von Microservices.
29:31
Genau also den ersten Punkt, den du auch Recht schnell genannt
29:33
hast, weil den kann man, den darf man einfach nicht vergessen
29:35
dabei. Das wär unfair.
29:37
Ist natürlich, dass du dir damit ne komplexe Infrastruktur
29:41
einkaufst. Ne, also?
29:43
Monitoring, Logging, das sind so Stichwörter, die so essentiell
29:47
sind. Wenn ich diesen diesen
29:48
Architekturansatz fahre, weil es klingt verlockend, dass du jetzt
29:53
einzelne Elemente hast und wie gesagt, gerade wenn es um
29:56
Varianten geht oder so, ist das auch wirklich n Riesenvorteil,
30:00
aber ich muss ja auch mitkriegen, wenn irgendwas nicht
30:02
stimmt, ja, also ich arbeite die ganze Zeit am Service A
30:07
entwickel den weiter und Service B und C liefen ja, das ging ja
30:10
und dann mach ich irgendeine Änderung an A.
30:13
Dass B und C auf einmal zum Beispiel mit der Kommunikation
30:15
nicht mehr zufrieden sind und nicht mehr die Daten kriegen,
30:17
die sie brauchen. Oder vielleicht doch, aber
30:20
anders formatiert, was auch immer.
30:21
Also es ändert sich zum Beispiel, was an der
30:23
Schnittstelle, aber ich seh das nicht, ich arbeite an A die
30:27
Ployders, das läuft das Ding, ich guck mir das an, zum
30:30
Beispiel so n Teil vom Frontend ne und alles ist cool und ich
30:33
krieg aber dann wenn ich kein Monitoring, kein Logging hab gar
30:35
nicht mit, dass B und C gerade. Wirklich dauerhaft Fehler
30:39
werfen? Ja und gar nicht mehr wirklich
30:41
funktionieren. Und ich kenn das auch.
30:43
Ich mein das ich find, das klingt immer so.
30:45
Ja natürlich musst du das irgendwie, das musst du halt
30:48
irgendwie sicherstellen, aber und ich finde das ist auch
30:51
wirklich n wichtiger Punkt den man glaub ich auch schnell mal
30:55
unterschätzt, ist halt eben dieses Monitoring, dieses
30:58
Logging und klar du welches zu haben.
31:03
Warum nicht auf jeden Fall. Klar willst du Monitoring und
31:06
Logging ja, aber mach es mal richtig, mach es mal so, dass du
31:10
auch wirklich relativ schnell verstehst, was das Problem ist
31:13
und das ist finde ich auch ne ich sag mal unterschätzte Sache,
31:18
weil man logischerweise sich sofort hinstellt und sagt klar
31:21
braucht man das, ist ja No brainer, aber das richtig zu
31:24
machen. Finde ich ist echt auch n
31:27
Knackpunkt wo man auch ne Menge von lernen kann und also so so
31:32
ging es uns auch ne so wie gesagt was ich vorhin eben
31:34
meinte, das Beispiel was ich mal hatte am Anfang war unser unser
31:37
Monitoring auch noch nicht gut, irgendwann haben wir es dann
31:40
ausgebaut weil wir relativ schnell gemerkt haben wir wissen
31:42
dass es gerade nicht mehr funktioniert, aber wir wissen
31:45
nicht warum es nicht mehr funktioniert ne also auch die
31:47
Observability dahinter. Die einfach irgendwie nicht mehr
31:50
richtig hingehauen hat. Ne so, und dann denkst du dir so
31:53
OK, wir haben vielleicht Monitoring irgendwie
31:55
eingerichtet und n logging, aber eigentlich wissen wir trotzdem
31:58
gar nicht warum, also wie wir es wie wir es fixen können, was
32:03
überhaupt das Problem ist so ne. Da noch ganz kurz die Anmerkung,
32:09
Liebe Zuhörerinnen, lieber Zuhörer, falls dich das Thema
32:12
Monitoring und Logging interessiert und du dir denkst,
32:14
so ah ja, da könnt ich wahrscheinlich auch noch mehr
32:17
machen. In unserer Def Ops Reihe.
32:19
Die ist zwar schon abgeschlossen, aber da gibt es
32:22
ne spezielle Folge zu dem Thema, dann hör da gern mal rein, ist
32:25
super interessant und bringt auf jeden Fall das Projekt weiter
32:28
nach vorne, wenn man diese Prinzipien die wir da besprechen
32:31
auch umsetzt. Ja, definitiv so.
32:35
Jetzt bin ich n bisschen raus und zwar vor und Nachteile
32:39
Microsofts, was mich jetzt eigentlich interessiert Tino ist
32:42
OK, es gibt logischerweise ne du kannst mit, du kannst es als
32:45
Monolith machen, du kannst das Microsoft machen, du hast da von
32:48
beiden vor und Nachteile, aber wann ist denn jetzt zum Beispiel
32:50
wenn wir uns jetzt sagen OK wir haben jetzt, wir sind jetzt in
32:52
der Praxis unterwegs, wann ist denn vielleicht was eventuell
32:54
besser ne also irgendwo müssen wir uns vielleicht orientieren
32:58
und sagen OK macht es irgendwie Sinn wenn man an der und der
33:01
Stelle das und das macht ja. Fangen wir noch mal bei
33:06
Monolithen an. Wann ist das sinnvoll, also
33:10
gerade am Anfang eines Projektes ist es sehr oft sinnvoll, das
33:15
möchte ich gleich mal vorweg sagen, gerade wenn ich noch so
33:19
in der Machbarkeitsphase bin, vielleicht NMVP bauen möchte,
33:25
dann brauche ich nicht, also dann brauche ich diesen Overhead
33:29
einfach nicht, da muss ich nicht ne komplexe Infrastruktur
33:31
aufbauen. Um Microservices als
33:35
Architekturansatz abbilden zu können?
33:37
Ja, weil wie gesagt, dieser Overhead, der ist nicht zu
33:39
unterschätzen, gerade wenn es Richtung Pipeline geht, ne, dass
33:42
ich einzelne Services quasi integrieren und deployen kann,
33:47
das da muss man dann schon ne Menge machen um das aufzusetzen
33:51
und beim MVP verbrenne ich da ziemlich viel Zeit,
33:53
beispielsweise gerade wenn ich n kleines Team bin, was ja oft der
33:56
Fall ist, wenn ich. Etwas n Prototypenbaue ja, also
34:00
so NMVP machst du ja nicht mit 20 Leuten.
34:01
Da sitzt du vielleicht allein oder zu zweit dran und gerade
34:04
wenn es schnell gehen soll, die Geschwindigkeit ne Rolle spielt,
34:10
dann würde ich da halt ganz klar n Monolith n Ansatz wählen am
34:12
Anfang, denn Fakt ist, es ist ja nicht in Stein gemeißelt, ich
34:17
hoffe du weißt was ich meine damit also du kannst diesen
34:21
Ansatz ja auch wie ihr es im Projekt macht oder gemacht habt,
34:24
das ist ja Vergangenheit. Ändern, also wieder umbauen oder
34:30
oder so Stück für Stück adaptieren.
34:33
Ja, auf jeden Fall. Also es ist es, ich sag mal, nie
34:35
zu spät, auch zu sagen, OK, du ziehst jetzt aus deinem
34:39
Monolith, vielleicht identifizierst du und sagst OK,
34:41
das ist jetzt vielleicht n Service, der irgendwie wichtig
34:44
ist, der wirklich abgekapselt für eine.
34:48
Wie nennt man das für für eine Verantwortlichkeit?
34:51
Da ist ne wie zum Beispiel ne Authentication oder so ne wo du
34:54
sagst OK diesen Service, den können wir einfach mal
34:56
rausziehen, den können wir abkoppeln aus unserem Monolithen
35:00
und da machen wir n kleinen Microservice draus und dann ist
35:02
es ja auch nicht schlecht zu sagen OK angenommen du kommst an
35:06
diesem Punkt ne Microservices draus zu machen aus bestimmten
35:09
Gründen, dann ist es halt ja auch nicht verkehrt es nach und
35:14
nach zu machen, also sowieso ne Übergangsphase zu zu haben.
35:18
Und das, was halt noch übrig bleibt, bleibt dann halt übrig.
35:21
So ne. Also angenommen du hast jetzt
35:22
vielleicht irgendwie so am Ende noch so n ich nenn es jetzt mal
35:26
salopp gesagt so n kuddelmuddel wo du nicht mehr ne irgendwie ne
35:29
wo du nicht mehr ne Verantwortlichkeit rausziehen
35:32
kannst. Ne und gerade wenn man jetzt zum
35:35
Beispiel sagt, OK wann passiert denn sowas?
35:36
Also erstmal ist es natürlich wichtig und ich find da muss man
35:40
natürlich gucken, man kann das natürlich auch irgendwie
35:42
dahingehend vorbereiten, dass es besser funktioniert, ne das als
35:46
erstes mal. Aber kommen wir gleich noch mal
35:49
drauf zurück, was jetzt zum Beispiel was ich finde ist,
35:53
wieso sollte man überhaupt vielleicht auf Microservices
35:55
gehen? Also ne jetzt im Sinne von warum
35:58
in der Praxis microservice, wann macht es Sinn?
36:01
Also wir hatten ja jetzt zum Beispiel logischerweise, du
36:02
kannst ja erst mal das nehmen so mehr oder weniger vom Monolithen
36:05
und das Umdrehen und sagen ja gut, wenn du n großes Team hast.
36:07
Klar da wenn du mehr Leute hast stehst.
36:10
Dir nicht auf den Füßen. Da kannst du halt einfach ein
36:13
kleines Team wieder nehmen oder draus machen und sagen, OK, du
36:17
hast ein riesengroßes Team. Ist ja blöd, die Kommunikation
36:20
dazwischen 1000 teammembern das ist ja riesen Overhead, da
36:25
kommst du ja gar nicht mehr zum Arbeiten.
36:26
Wieviel meetings willst du irgendwann halten, damit du
36:28
irgendwann auf eine Reinigung kommst?
36:30
In einem riesen Monoliten, also Microservices, kleine
36:33
Verantwortlichkeiten, kleine Teams für die entsprechenden
36:35
Verantwortlichkeiten wie zum Beispiel ein Authentication
36:37
Service bringt natürlich aber auch was wenn du sagst OK.
36:41
Du hast jetzt zum Beispiel deinen Authentication Service
36:43
und du willst ihn jetzt zum Beispiel 5 mal in 5 Produkten,
36:46
die du irgendwie rausbringst. Brauchst du ne Authentication,
36:48
dann mach doch einen Authentication Service, dann
36:50
brauchst dich nur einmal anmelden, kannst dich überall
36:51
anders anmelden, ne so in die Richtung, das ist ja zum
36:55
Beispiel auch noch ne Sache. Weiß nicht was.
36:58
Das ist aber n wichtiger. Punkt.
36:59
Ja. Ne.
37:01
Ja, also wie gesagt, wir hatten die Komplexität des Produkts ne
37:04
wenn es Varianten gibt, wenn es unterschiedlich, also wenn es
37:07
einfach. Kein geradliniger
37:10
Entwicklungszweig ist sozusagen ne beziehungsweise nee, das
37:13
klingt jetzt sehr repolastig, ich will es gar nicht so
37:16
formulieren, aber wenn die Funktionalität, nennen wir es
37:20
mal so ne, die Funktionalität des Produkts vielseitig ist und
37:24
es Varianten gibt, einfach das ist einfach der Punkt dahinter,
37:28
dann kann man halt auch sagen, OK, vielleicht ist n
37:31
Microservices Ansatz sinnvoll. Gerade hinsichtlich auch so
37:36
Features. Wenn du sagst, nicht jeder
37:39
Endverbraucher, jeder Kunde am Ende hat jedes Feature zum
37:42
Beispiel Na von meinem Produkt auch wieder so n Punkt wo ich
37:46
sagen kann na ja aber dann hab ich ne gewisse Komplexität wenn
37:50
alles auf einem Haufen ist sozusagen und ich dann wieder
37:52
dafür sorgen muss, aber Sachen müssen an sein müssen aus sein,
37:55
der kriegt die Version der kriegt die Version.
37:58
Dann dann, wenn ich sowas merke, dann kann man halt wirklich auf
38:01
jeden Fall über diesen Microservices Ansatz nachdenken,
38:03
ob man nicht in die Richtung geht.
38:04
Ja, mit dem pro Abo kriegst du Halt 80% der Services und mit
38:07
dem Ultimate Abo kriegst du dann.
38:10
Wie immer und mit Free kannst du mal 5 Minuten testen.
38:17
Genau jetzt hast du dich rausgemacht.
38:18
Ja, aber das genau, also wenn diese wenn es viele
38:21
Abhängigkeiten auch zu anderen Systemen gibt und so und dann
38:24
ich das halt. Nicht entkoppeln möchte, weil
38:27
ich jedes Mal dann bei jeder Änderung mir denke, oh jetzt ey,
38:29
keine Ahnung, jetzt muss ich hier von 500 Funktionalitäten
38:33
hab ich eine geändert und ich muss aber 500 so gesehen neu
38:36
versionieren und neue Deployen obwohl da nichts passiert ist.
38:38
Ne sowas find ich ist halt auch ärgerlich dann also ich find das
38:42
dann merk ich halt auch so, dass es von Architektur manchmal so
38:45
ist. Ah jetzt mach ich jetzt weißt du
38:46
jetzt deploye ich das ganze System.
38:50
Dauert alle Tests laufen ne, du hast halt ne große Pipeline
38:54
dahinter, aber eigentlich hast du nur an einem kleinen
38:56
Bestandteil was geändert und du hättest eigentlich nur 5 Tests
38:58
laufen lassen müssen, so übertrieben gesagt und dann
39:01
denkst du dir auch so und n Punkt, den haben wir vorhin
39:08
nicht so richtig klar herausgestellt glaub ich ist
39:10
wenn was schiefgeht, dann gilt das für deinen ganzen
39:13
Monolithen, zum Beispiel, dass die Pipeline sagt ist nicht.
39:17
Weil dieser eine Test jetzt rot ist.
39:18
Das war, es klappt nicht noch mal alles laufen lassen.
39:22
Wenn ich das jetzt auf microservice Ebene mache und
39:24
diese der die Pipeline einfach viel schneller als für diesen
39:27
kleinen Service kann ich ja viel schneller das fixen und dann
39:30
deployen, richtig. Ja toll, wenn man noch mal, so
39:36
ich ich überlege gerade so was man so vielleicht so tippmäßig
39:38
so auch mitgeben kann. Also.
39:42
Aber ich hab, ich weiß nicht, ich glaube, du hast es auch
39:45
schon beides mal erlebt zu sagen okay man macht irgendwie was
39:47
monolithisch, man fängt vielleicht monolithisch angeht,
39:52
dann irgendwann vielleicht denkt, dann kommt man irgendwann
39:54
an den Punkt, wo man sagt, Boah Ey, irgendwie passt das jetzt
39:56
nicht mehr, haben wir privat ja auch schon gehabt, haben
39:59
teilweise, da hast du ja auch einiges gemacht, auch direkt
40:03
sozusagen einzelne Services sozusagen dann aufgesetzt, also
40:07
so, ich sag mal Micro Service Ansatz, aber wenn man jetzt zum
40:10
Beispiel sagt Ey okay irgendwie ist Microsoft ist cool und.
40:12
Ich hab jetzt aber Monolith. Was könnte man machen oder man
40:16
sagt OK wir haben jetzt aber NMVP gebaut, es ist jetzt
40:19
monolithisch und ich will jetzt aber irgendwie das ganze
40:23
aufspalten. Hast du da n Tipp was also was
40:28
man machen könnte vielleicht zu sagen OK wir haben ne fängst
40:31
monolithisch an, bist gerade dabei oder du weißt.
40:34
Ne wie ich meinte, MVP ist gerade los, aber wahrscheinlich
40:37
wird es irgendwann microservice kann man da schon irgendwie
40:40
drauf achten, dass man vielleicht das ganze n bisschen
40:43
Smoothie dann hinbekommt? Ja, fangen wir mal mit der
40:49
Infrastruktur an. Die ist natürlich nicht so
40:51
umfangreich logischerweise, es hat mir auch als Vorteil
40:53
genannt, wie bei Microservices, aber Grundprinzipien gelten für
40:57
beide Ansätze. Stichwort Tracing, logging,
41:00
Monitoring. Alles was wir schon genannt
41:02
hatten, gilt ja für beides, also bitte es nicht falsch verstehen,
41:05
wenn ich sage ich nehm monolithen, dann brauch ich das
41:07
alles nicht. Nein, so ist es nicht, das heißt
41:10
diese ganzen Ansätze, diese Pipeline einfach auch schon
41:13
vernünftig aufbauen, dass man sie adaptieren kann, auseinander
41:16
trennen kann, auch wieder verwenden kann, Bestandteile
41:19
dafür für einzelne ne, dass ich dann zum Beispiel mehrere kleine
41:22
hab, aber halt das alles schon gut vorbereitet, frühzeitig
41:27
Einsätze. Dann auf Entwicklungsebene ein
41:32
Monolith bedeutet nicht, dass ich spaghetticode schreiben
41:34
darf. Das heißt, ich muss ja trotzdem
41:38
ne gute Softwarearchitektur aufsetzen, auch bei einem
41:41
Monolithen, dass ich in der Lage bin, später das ganze zerlegen
41:46
zu kann, ne zerlegen zu können, so falls ich dann sage, ich
41:50
möchte doch auf den microservice Ansatz gehen, dass ich halt die
41:53
Möglichkeit hab n Freischnitt zu machen.
41:55
Ne, dass ich so Teile raustrenne und sie auslagere und das wären
41:59
so Sachen, worauf ich jetzt persönlich achten würde.
42:02
Halt wie gesagt einmal die diese Infrastruktur Sache, die
42:06
Automatisierung ne dass du ne vernünftige Pipeline hast,
42:08
vernünftiges Monitoring, dass dieser Overhead quasi nicht so
42:13
riesig wird wenn ich es Umbau weil ich ja einfach n Teil auch
42:15
beim Monolithen schon brauche und dass ja auf Code Ebene halt
42:19
auch schon. Nicht also ich würde nicht von
42:22
Anfang ansagen, oh, ich muss das jetzt unbedingt im Kopf haben,
42:25
so ne, aber einfach sag ich mal best practices verwenden, damit
42:30
du später auf so remit refactoring diese Freischnitte
42:33
machen kannst. Ja, also gerade wenn man jetzt,
42:36
ich hatte ja vorhin so auch angesprochen, dass mit der
42:38
Authentication, du kannst halt zum Beispiel n Authentication
42:42
Service schon in deinen Monolithen reinballern ja, das
42:45
nennt man ja auch vielleicht so besser, wenn du so ne
42:47
serviceschicht hast oder so in deinem Monolithen.
42:50
Kannst du natürlich die auch hinstellen und sagen, gut, ich
42:52
hab bau das da jetzt schon schön also modular rein ne kannst
42:57
natürlich aber auch sagen auch keine Ahnung ich mach das hier
42:59
ich mach das da so richtig so wild West Abhängigkeiten durch
43:04
den ganzen Code von A nach B ziehen so wie es halt gerade
43:08
passt. Ne wild West das sollte man
43:11
natürlich n bisschen vermeiden und ich ich denke dann kann man
43:15
eigentlich n ganz guten Shift hinkriegen von.
43:20
Von einem Monolithen zum Beispiel, hinzu einem
43:23
Microservice oder sich halt diesen, diesen Weg halt
43:26
entspannt offen lassen. Ne, also ich sag mal so,
43:28
Vorbereitung ist ja die halbe Miete, ich glaub sagt man das so
43:31
war das. Sagt man so gut.
43:33
Ja, es ist genauso ein. Also du sagst das sehr oft so,
43:38
das war vielleicht der Erste, das erste Sprichwort, was ich
43:41
seit langem mal wieder richtig hart da war, sehr gut.
43:45
Was, was ja eigentlich noch irgendwie ganz interessant ist.
43:47
Zumindest hab ich jetzt auch noch mal drüber nachgedacht.
43:48
Wir haben ja auch gerne auch mal, sagen wir mal Leute in
43:52
unserer Community, die vielleicht auch noch n bisschen
43:55
im Bereich Starter, Beginner, Anfänger, Anfängerin, wie auch
43:58
immer man das nennen möchte, so in der Softwareentwicklung sind
44:01
und wenn man sich jetzt vielleicht so ne ich ich stell
44:05
ich, ich versuch mich immer selbst in mich hineinzuversetzen
44:07
und angenommen, ich würde jetzt diese Folge hören und würde mir
44:09
denken so. Boah Mist ey, jetzt muss ich.
44:12
Jetzt hab ich wieder das nächste was ich irgendwie machen muss.
44:14
Microservice ist gar keine Ahnung, ich muss ja erstmal noch
44:17
überhaupt erstmal meine erste richtige Anwendung bauen, da bin
44:19
ich ja gerade dabei oder so was kann man was, was könnten wir
44:24
denn Tino, was könnten wir denn mal so jemandem der sagt oder
44:28
die sagt Ey ich bin gerade am Anfang, was ist denn die bessere
44:33
Wahl für die entsprechende Person, die gerade am Anfang
44:36
steht, wenn man sagt Ey du Boss willst ne Anwendung bauen.
44:40
Mach mal hier Monolith oder Microservice.
44:45
Ja, Take Home Message. Jetzt wird's spannend, gerade
44:51
als Einsteiger oder Einsteigerin schreibe ich ja eher kleinere
44:56
Projekte, also kleinere Softwarelösungen.
44:59
Ja, das sind so erste kleine Projekte, da würde ich mir über
45:02
Microservices gar keine Gedanken machen, also wenn ich wirklich
45:05
richtig. Anfänger, Anfängerin bin und das
45:08
nicht negativ gemeint, überhaupt nicht, nicht sich sag ich mal
45:13
überwältigen lassen von dieser Inputflut.
45:16
Ja, weil IT Soft Entwicklung ist.
45:18
Unglaublich vielseitig und umfangreich und erdrückend, wenn
45:21
man es alles gleich berücksichtigen möchte, deswegen
45:24
codet einfach los Monolithen Ansatz was ihr braucht rein in
45:28
das Projekt, fertig. Ganz einfach, da würde ich mir,
45:32
man macht sich am Anfang ja auch um die Pipeline einfach denn
45:34
auch noch keine Gedanken, deswegen monolithenansatz ja,
45:38
wenn ich aber sage, nein, jetzt ist es so n Projekt, das möchte
45:42
ich wirklich langfristig machen, ja, also das ist ne
45:45
Softwarelösung, die brauche ich beispielsweise und die möchte
45:47
ich verwenden oder ich möchte sie vielleicht sogar anderen
45:49
schon zur Verfügung stellen, wieso ne erste kleine App,
45:52
vielleicht ne Website ne also n Frontend und so weiter dann.
45:57
Würde ich sagen, gut, wieviel bin ich im Team, bin ich
45:59
alleine, ist es n privates Projekt, würde ich weiterhin den
46:02
Monolithen Ansatz machen, aber halt Richtung Infrastruktur wie
46:06
wir meinten das alles vorbereiten, aufbauen, dass man
46:09
sagt ich hab ne vernünftige Pipeline, wirklich noch mal der
46:12
reminder wir haben da ne ganze Reihe zu gemacht zu dev Ops mit
46:16
Hilfe dieser Reihe kann man sich schon mal die erste kleine
46:19
Pipeline aufbauen, dass man einfach da rein wächst, weil das
46:21
ist. Wenn man mehr Erfahrung hat, ein
46:23
sehr, sehr wichtiges Thema, was einen immer begleiten wird man,
46:26
es gibt keinen Weg drumherum, ja so und dann irgendwann kann man
46:33
ja mal sagen, ey, ich möchte jetzt mal Microservices machen,
46:36
ja, ich möchte das mal verwenden und dann kann man sich ja auch
46:39
gezielt mal n Projekt nehmen und sagen, ich, wie würde ich das
46:42
denn splitten ja also ich hab jetzt meine Erfahrung gesammelt,
46:45
ich hab. Ich hab so n Monolithen Projekt
46:48
umgesetzt. Ich hab zum Beispiel n Backend n
46:49
Frontend laufen, das ist zwar alles irgendwie eng gekoppelt,
46:52
aber das läuft dann sich zu überlegen ey wie kann ich das
46:56
denn Split? Ja.
46:58
Weißt du? Ja, find ich gut.
47:00
Also im Endeffekt denk ich mir halt auch so.
47:02
Gerade am Anfang ist es halt sinnvoll diese Komplexität halt
47:05
auch gering zu halten, weil weiß ich nicht, du bist ja vielleicht
47:08
auch noch gerade in so einem in so bei bestimmten Grundlagen
47:11
vielleicht, vielleicht bist du bei manchen Sachen schon weiter,
47:13
aber woanders bist du noch bei Grundlagen irgendwie.
47:16
Und dann bringt es dir halt auch noch nichts, wenn du quasi
47:18
sagst, OK, ich muss jetzt aber schon irgendwie meine
47:22
Infrastruktur aufbauen, weißt du ja, ich brauch jetzt unbedingt n
47:25
Cloud Service, zum Beispiel keine Ahnung, du kannst das ja
47:27
auch irgendwie lokal machen, aber beim beim Microservice
47:30
kommst du ja relativ schnell irgendwann zu Docker und Docker
47:33
finde ich ist auch n ist jetzt nicht n Riesenthema aber ist n
47:36
Thema so, das heißt da musst du halt auch erst mal wieder n
47:39
bisschen reinkommen. Wenn du aber gerade noch
47:41
woanders bist, ist es natürlich am Anfang schwierig, dann wirst
47:43
du vielleicht irgendwie überladen, ne und das?
47:45
Lässt sich dadurch vermeiden. Ich find was wichtig ist ist,
47:49
dass man jetzt sich nicht hinstellt und sagt, das ist zum
47:52
Beispiel so n Tenor den ich höfter mal irgendwie dann so am
47:56
Anfang auch mitbekommen hatte. Monolithen sind schlecht, so
48:00
mach das nicht, das ist das ist von gestern, mach lieber
48:02
microservice, das ist cool so, wir hatten ja mal das Ganze so
48:07
durchgesprochen, ist es nicht so und gerade wenn du am Anfang
48:10
bist find ich es monoli überhaupt nicht schlecht so,
48:12
wenn du irgendwann dir aber denkst, ja.
48:15
Was ist denn jetzt n großer Unterschied zwischen einem
48:17
Monolithen und einem und einem Microservice?
48:19
Dann fragt dich immer, OK, macht dein Monolith mehr als eine
48:23
Sache oder macht es mehrere Sachen ne so also ist da zum
48:27
Beispiel ne Authentication drin, ist da vielleicht irgendwie
48:29
keine Ahnung irgendwas drin was was hatten wir n Beispiel E
48:33
Commerce hast du da Zahlungsmittel hast du da
48:37
irgendwie lokalisierungsservice hast du vielleicht noch so ne
48:40
Art was weiß ich. Denkt dir irgendwas aus, du
48:46
weißt ne, also hast hast du diese ganzen Sachen drin und
48:48
wenn du aber n microservice hast, dann machen die Sachen
48:50
alle nur das. Also du hast wirklich nur das
48:52
ist für steht für sich alleine und du hast jetzt zum Beispiel
48:57
so n Microservice der irgendwie sagt OK du bist jetzt zum
48:59
Beispiel an der und der, also ne bist da und da lokalisiert.
49:03
Dann sagt der aber nicht ja, du bist aber jetzt da und da
49:06
lokalisiert und ich weiß, dass Anwendung x da lokalisiert ist.
49:11
Baba BAB so nach dem Motto sondern ne du hast also das ist
49:14
ja quasi ich will jetzt nicht stateless sagen, aber du dieser
49:18
Service, der ist erstmal an sich relativ dumm, der kennt zum
49:22
Beispiel vielleicht nicht unbedingt irgendwelche
49:25
großartigen Details von irgendeiner vom vom anderen
49:31
Service, ne. Und da das find ich so.
49:34
Die hat halt eine gekapselte Funktionalität.
49:36
Genau, und das ist halt immer so n bisschen die, die die
49:39
Schwierigkeit finde ich dann auch irgendwann wirklich zu
49:41
sagen, OK, das ist jetzt eine Verantwortlichkeit, das ist n
49:43
Service und das muss man vielleicht auch erstmal
49:45
irgendwie lernen, was halt auch wieder irgendwie n bisschen mit
49:47
Reinspielt in das Ganze. Mach es dir erstmal nicht zu
49:50
kompliziert, wag es erstmal rein, fang mit Monolithen an und
49:54
prinzipiell ist spricht auch nicht immer irgendwas gegen
49:57
Monolithen. Ne es ist halt immer die Sache
49:59
was braucht man gerade, was hilft, was ist wichtig, was
50:02
passt. Das genau das Problem bei
50:04
Monolith ist einfach, dass dieser Begriff sag ich mal so n
50:09
bisschen ja so n so n Schatten mit sich bringt, der weil er
50:13
einfach auch oft im Zusammenhang mit so alten.
50:18
Projekten verwendet werden, so Legacy Sachen, die aber seit 20
50:22
Jahren irgendwie am Leben gehalten werden und.
50:24
Dieses typische historisch. Gewachsene und dann redet man
50:27
ganz oft von er ist so n altprojekt und da ist so n
50:30
riesen Monolith drin und da ist es einfach Chaos.
50:33
Ja, aber Monolith in dem Grundarchitekturansatz bedeutet
50:37
nicht Chaos. Also man sagt nicht zu einem
50:39
Projekt, was total chaotisch ist.
50:40
Oder guck mal so n richtiger Monolith, aber so wird es oft
50:43
verwendet oder einem verkauft und das ist halt einfach dem
50:46
nicht gerecht und nicht fair. Wir haben das ja auch sehr
50:48
objektiv hier betrachtet, ich sag mal so, Fakt ist beide
50:53
Ansätze können komplettes Chaos werden und beide Ansätze können
50:56
auch sehr gut funktionieren und wir haben ja die vor und
50:58
Nachteile genannt. Wann man was bevorzugen sollte
51:02
und auch gesagt, dass man aber beide auch verwenden kann um
51:05
Sachen umzusetzen und deswegen würde ich sagen Fabi, Danke für
51:09
den Talk war n sehr cooles Thema was du so mitgebracht hast.
51:13
Ich fand es auch sehr spannend da jetzt noch mal so wirklich
51:15
ausführlich drüber nachzudenken und du, liebe Zuhörer, liebe
51:18
Zuhörer, was sind denn deine Erfahrungen damit?
51:21
Das würde uns brennend interessieren, hast du mit
51:24
beiden Ansätzen gute Erfahrungen gemacht oder schlechte oder
51:26
bevorzugt? Bevorzugst du einen Fall?
51:29
Besonders gegenüber dem anderen. Ja, bist du Team Microservices
51:34
Team Microservices oder Team Monolith?
51:37
Lass es uns wissen, schreib uns die Mail zum Podcast findest du
51:41
in den Shownotes auch alle anderen Plattformen?
51:43
Meld dich auf dem Kanal deiner Wahl, wir werden die Antworten
51:45
wir freuen uns über jede Nachricht, ansonsten Tausch dich
51:50
gerne auch auf n Discord mit unserer Community aus, das sind
51:53
immer so coole Themen worüber man diskutieren kann, da freuen
51:55
sich die Leute die schon da sind, da bin ich mir sicher.
51:58
Wir sind ne super entspannte Runde.
52:00
Ihr seid alle herzlich eingeladen und wenn dir der
52:04
Podcast gefällt, lass auch gerne ne Bewertung da, das hilft uns
52:07
ungemein und ansonsten würde ich sagen, hören wir uns alle in der
52:12
nächsten Folge wieder, habt ne gute Zeit bis dahin ciao ciao
52:16
deine Coding Bodys gemeinsam besser.