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.