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