Ein Geek kommt selten allein Cover

Ein Geek kommt selten allein

Stephan Hochhaus

Since 01/2024 16 Episoden

Microservices mit Florian Rademacher

Der heilige Gral der Softwarearchitektur

08.05.2024 76 min

Zusammenfassung & Show Notes

In unserer Podcast-Folge "Ein Geek kommt selten allein" tauschen Florian Rademacher und ich Gedanken über Microservices in der Software-Architektur aus. Wir reflektieren darüber, wie sich Softwareentwicklung und Architektur im Laufe der Zeit verändert haben, wobei wir Microservices und ihre Vor- und Nachteile besonders hervorheben. Florian betont, dass Microservices darauf abzielen, komplexe Software-Systeme skalierbar und wartbar zu machen, indem sie abgegrenzte fachliche oder Infrastrukturfunktionalitäten darstellen, die unabhängig voneinander ausführbar sind. Im Verlauf des Podcasts erörtern wir die Grundlagen von Microservices und deren Architektur. Wir vertiefen uns in Themen wie hohe Kohäsion und lose Kopplung in Softwaremodulen, die Vorteile von Microservices im Vergleich zu Monolithen sowie die Bedeutung einer sorgfältigen Modularisierung, die auf Netzwerk-Kommunikation basiert. Wir gehen auch auf Herausforderungen von Microservices ein, wie beispielsweise Authentifizierung und Skalierung, und betonen, dass nicht jede Anwendung für eine Migration zu Microservices geeignet ist. Jede Architektur muss individuell evaluiert werden, bevor eine Entscheidung getroffen wird. Die Diskussion dreht sich auch um die verschiedenen Kommunikationsformen bei Microservices, von synchroner bis asynchroner Kommunikation, sowie den Einsatz von Message Brokern. Wir unterstreichen, dass die Wahl der Architektur von verschiedenen Faktoren abhängt, wie Team-Erfahrung und Projektanforderungen. Es wird deutlich gemacht, dass die Entscheidung zwischen Monolithen und Microservices sorgfältig abgewogen werden sollte und dass Skalierungsoptionen wie horizontale und vertikale Skalierung bei Microservices eine wichtige Rolle spielen. Schließlich werden Integrationstests und deren Komplexität im Hinblick auf Microservices diskutiert. Wir heben die Essenz von Testing, vor allem von Edge-Cases, hervor und diskutieren die Implementierung von Microservices in der Cloud sowie die Bedeutung von modellgetriebener Softwareentwicklung. Wir schließen mit dem Fazit, dass Microservices nicht die universelle Lösung für jedes Unternehmen sind und dass ihr Einsatz sorgfältig abgewogen werden sollte. Zum Schluss geben wir Informationen zur Microservices-Community und bieten die Möglichkeit, mit Florian auf LinkedIn in Kontakt zu treten.

Der heutige Gast ist Florian Rademacher, Consultant bei der codecentric AG. Ihr findet ihn auf LinkedIn oder in der Microservices.community.

Transkript

Geek

00:00:00

Gemeinsam mit Florian Rademacher spreche ich über Microservices in der Software-Architektur. Ihr hört Ein Geek kommt selten allein, den Podcast rund um Digitalisierung. Hallo und herzlich willkommen zu Ein Geek kommt selten allein, dem Podcast für mehr Konkretheit in der Digitalisierung. Mein Name ist Stephan und gemeinsam mit meinen Gästen mache ich eine Bestandsaufnahme, wohin uns die letzten 40 Jahre Digitalisierung in Deutschland gebracht haben und wie es von hier aus weitergehen kann.

Florian

00:00:39

In dieser Folge spricht der Geek mit Florian Rademacher. Hallo Stephan, hallo an die Zuhörer da draußen. Ich habe zum 1. November bei der Codecentric als Berater angefangen, war davor lange in der Wissenschaft unterwegs und habe im Bereich Microservice-Architektur und Architekturmodellierung promoviert. Und hoffe, dass ich dadurch qualifiziert bin, ein bisschen was über dieses Thema zu sagen. Insbesondere Microservices, die ja heute nach wie vor in aller Munde sind in der Software-Architektur-Community und auch darüber hinaus. Wo sich aber mittlerweile so ein bisschen Ernüchterung einstellt an diversen Stellen, über die wir gleich auch gerne mal einmal diskutieren können. Was so die Vor- und Nachteile dieses Architekturstils denn eigentlich sind.

Geek

00:01:19

Das Thema. Du hast es ja schon gesagt, alle Nase lang kommt mal irgendein Begriff in die Software-Welt. Der ist der Heilsbringer, der ist das Lösungswort, womit man alle Probleme der Digitalisierung loswerden kann. 2011 war es, glaube ich, Marc Andresen hat gesagt, Software frisst die Welt. Deswegen, wenn wir über Digitalisierung sprechen, müssen wir auch über Softwareentwicklung sprechen, müssen wir über die Software sprechen, die diese Welt und die Digitalisierung am Laufen halten soll. Somit sind wir bei der Frage, wie kann man eigentlich gute Software machen? Wie hat sich Software bauen und Softwarearchitektur in den letzten Jahren verändert? Und da das Thema so massig groß ist und 40 Jahre Softwarearchitektur in 40 Minuten würden bedeuten, dass jedem der Kopf schwirrt, reden wir heute mal eigentlich nur über dieses Thema Microservices. Wo kommen die Microservices her? Was machen wir damit? Wie ist Software eigentlich besser geworden durch Microservices? Oder warum wird es eben nicht besser durch Microservices? ist. Vielleicht kannst du einmal kurz herleiten, aus welchem Hintergrund heraus quasi Microservices erwachsen sind. Also was gab's vor Microservices? Wie sah Software aus in den dunklen alten Tagen?

Florian

00:02:24

Also im Endeffekt kommt dieser Microservice-Gedanke, die sind auch so, witzigerweise auch um 2011, 2012 rum wurde dieser Begriff geprägt. So 2014, 15 kam das dann immer mehr in den Mainstream rein. Vor allem auch, weil große Player, große Companies da draußen, Netflix, Amazon, Spotify, das sind immer so die Platzhirsche, die man da nennt. Die sehr viel Werbung für Microservices gemacht haben. Dadurch wurde das Ganze eben extrem populär. Und grundsätzlich ist der Gedanke bei Microservices, dass du sagst, du hast ein komplexes Software-System und dieses Software-System skaliert entweder nicht mehr vernünftig, zum Beispiel mit einer hohen Benutzerzahl, oder aber ist extrem schwer zu warten, oder aber eben beides. Und da sollten Microservices dann eben helfen, wo ich mir dann konkreter Gedanken darüber mache, wie strukturiere ich eigentlich meine Software-Architektur und eben nicht nur die Architektur, sondern vor allem auch meine Entwicklungsorganisationen, meine Entwicklungsteams. Das ist so ein bisschen, wo der Gedanke herkommt. Wir werden gleich wahrscheinlich noch darüber sprechen, was ein Microservice konkret tatsächlich ist. Vorher sah die Welt so aus, dass tatsächlich viele Menschen da draußen, die sich mit Softwarearchitektur auskennen, eigentlich schon so ein Microservice-Gedanken ein bisschen verfolgt hatten, geht vor allem um. Starke oder hohe Kohäsion, lose Kopplung von Komponenten, können wir gleich auch noch ein bisschen ins Detail ansteigen, eigentlich alle schon irgendwie in dieselbe Richtung gedacht haben, es fehlte aber irgendwie so ein gemeinsamer Oberbegriff und dann hat man sich mal auf so einem Architektur-Workshop getroffen und da haben diese Leute dann festgestellt, das waren dann so Leute wie Martin Fowler, James Lewis, die dann da waren, die auch genau diesen Microservice-Begriff eben geprägt haben, festgestellt, ach, wir machen ja eigentlich alle so ein bisschen schon irgendwie in diese Richtung, dasselbe und jetzt müssen wir mal ein gemeinsames Oberthema dazu finden und hat dann gesagt, okay, das nennen wir jetzt Microservice. Ob der Begriff jetzt gut oder schlecht gewählt ist, darüber kann man sich auch streiten. Der Schmerz, weswegen man Microservices oder man diesen Gedankengang dann an der Stelle gegangen ist, ist so ein bisschen einmal aus so einer Monolithenwelt raus. Große, komplexe Software-Systeme, die ein riesengroßer, schwerer Block sind, sind schwerer zu skalieren.

Geek

00:04:20

Aber lass uns das ein Stückchen tiefer legen. Was macht Software überhaupt komplex? Also Taschenrechner versus Facebook oder so. Weil es gibt ja Software, die ist komplex und es gibt Software, die ist vielleicht ein bisschen einfacher, geradliniger. Aber was sind die Faktoren, die dafür sorgen, dass Software komplex wird?

Florian

00:04:39

Schwierig zu beantworten oder sagen wir mal nicht schwierig zu beantworten, aber alle Faktoren in dem Moment zu identifizieren, die da reinspielen. Also es ist sicherlich so, dass natürlich die Komplexität der Fachdomäne oder die Größe der Fachdomäne oder auch der Fachlichkeit, die ich abbilden will, eine Software komplexer macht. Also sagen wir mal, so ein Netflix mit seiner Fachlichkeit, mit dem, was es so tut, ist sicherlich deutlich komplizierter als vielleicht ein Taschenrechnerprogramm, das jetzt jemand in der Ausbildung oder einem Bachelorstudent oder sowas da irgendwie mal implementiert. Das ist einmal der Umfang, der Funktionsumfang, die Fachlichkeit, die Komplexität der Fachlichkeit selber, aber eben auch solche Dinge wie meine Entwicklungsorganisation. Wie bin ich eigentlich als Unternehmen strukturiert? Wie gut sind meine Kommunikationsflüsse im Unternehmen? Wie effizient kann ich überhaupt arbeiten? Bin ich vielleicht stärker von Politik getrieben? Also eher vielleicht Dinge, die jetzt aus einer Entwickler- oder Architektenbrille eher irrational sind oder irrational erscheinen mögen. Also das sind alles so Dinge, die Softwareentwicklung an sich komplex machen können und Software kann natürlich auch dadurch komplex werden, dass Technologien zum Beispiel extrem schwierig oder schwieriger sind als andere Technologien. Weiß ich nicht, eine Container-Orchestration-Plattform vernünftig aufzusetzen ist vielleicht auch schwieriger als einen Maven vernünftig zu betreiben bei mir lokal. Also das sind auch Dinge, die da reinspielen. Aber die Komplexität ergibt sich zumindest im Bereich Microservices eher daraus, dass ich sage, ich habe große komplexe Domänen und ich muss meine Software vernünftig aufteilen, sodass sie skalierbar ist auf der einen Seite und auch wartbar bleibt oder wartbarer wird auf der anderen Seite.

Geek

00:06:05

Ich bin ja jetzt so alt, dass früher meine Software immer auf Disketten kam und dann irgendwann auf CDs und erst ganz viel später gab es das irgendwie über das Internet. Und alle Software, die über CDs kommt und die ich mir installiert habe, also alles, was Fat Client ist, also mein Word vor der 365-Ära, wo es im Internet war und dergleichen, all diese Dinge, stelle ich mir vor, sind eigentlich klassische Monolithen. Also das ist halt ein fettes Ding, das ich installiere und alles, was im Netz ist, das kann entweder fett sein oder oder Microservices haben oder bin ich da auf der falschen Fährte? Also ist quasi alles, was ich als Fettclient auf meinem Rechner habe, Tendenziell eher mal kein Microservice.

Florian

00:06:42

Also beim Monolithen oder diese Unterscheidung Microservices-Monolithen ist so, dass du sagst, wenn ich Software habe, deren Komponenten nicht alleine lauffähig sind und die auch nicht verteilt sind, also die ich jetzt nicht auf mehrere Rechenknoten zum Beispiel verteilen kann, dann betrachtet man diese Software als monolithisch. Manche sagen auch, dass dann zum Beispiel die Prozesse, die von dieser Software gestartet oder ausgeführt werden, dass die im selben Adressraum laufen. Das ist aber schon sehr technisch. Du sagst eigentlich, wenn ich eine Software habe, Komponenten sind nicht verteilt und sind nicht unabhängig voneinander ausführbar. Ich brauche immer eine Ausführungsumgebung, wo das Ganze drin läuft, dann ist es ein Monolith. Und Microservices ist ein zusammenhängendes Software-System, das logisch zusammenhängt, dessen Komponenten ich aber unabhängig voneinander ausführen kann, die ich verteilen kann auf verschiedenen Rechenknoten. Das würde man dann eher als Microservice-Architektur bezeichnen.

Geek

00:07:32

Mal so eine richtig dumme Frage. Als ich dann weitergegangen bin, nach den CDs und so weiter, und die erste Webseite kam, da kam der LAMP-Stack. Das heißt, es gibt das Linux-Ding, da gibt es eine Apache, eine MySQL-Datenbank, ein bisschen PHP, und da drinnen gibt es ein WordPress oder dergleichen. Ist alles von denen dann auch ein Microservice? Also ist dann meine Datenbank sozusagen ein Microservice, mein Apache ist ein Microservice?

Florian

00:07:53

Es gibt Menschen, die würden jetzt darauf antworten, ja. Ich sehe das ein bisschen anders. Ich sehe das so, ein Microservice ist eigentlich in der Mehrzahl etwas, das eine fachliche Funktionalität abdeckt. Fachlich im Sinne von, wir befinden uns in irgendeiner Fachdomäne. Und in dieser Fachdomäne erfüllt dieser Microservice eine bestimmte dedizierte Aufgabe. Nehmen wir sowas wie, ein Beispiel ist immer irgendwie Benutzerverwaltung. Nun kann so eine Benutzerverwaltung natürlich auch unfassbar komplex sein. Aber wenn wir jetzt mal irgendwie so uns sagen, du hast jetzt eine Komponente, die ist dafür verantwortlich, einen Benutzer anzulegen, Benutzer zu ändern, Benutzer zu löschen. Dann kannst du diese Funktionalität in einen Microservice packen und das funktioniert auch wunderbar. Und du hast dann vielleicht aber auf der anderen Seite, wenn wir mal jetzt bei dem Netflix-Beispiel nochmal bleiben, hast du dann vielleicht einen Microservice, der ist für das Streaming verantwortlich. Das heißt, du hast dann zwei Microservices schon mal. Der eine ist für die Nutzerverwaltung, der andere ist für Streaming verantwortlich. Beides sinnvolle Funktionen innerhalb dieser Fachdomäne Video-Streaming. Und das würde man dann eher als Microservice bezeichnen. Dass wir im Hintergrund noch Datenbanken und solche, sagen wir mal, eher technischen Komponenten haben, das ist klar, das gehört dazu. Die werden aber in der Regel nicht als Microservices betrachtet. Kleine Anekdote vielleicht am Rand, weil ich gerade sagte, Es gibt Leute, die sagen, das sind Microservices. Ich habe mal mit jemandem gesprochen, der hat gesagt, wenn ich es in einen Docker-Container packe und im Docker-Container starten kann, ist es ein Microservice. Das betrachte ich anders, sehen auch einige andere Leute anders, hat den Hintergrund, dass Container und Microservices, können wir vielleicht auch nochmal ein bisschen tiefer darüber sprechen, sich gegenseitig befruchtet haben. Also ohne Container ist so eine Microservice-Architektur eigentlich nur sehr schwer denkbar, weil Container dir Virtualisierung mitbringen, weil sie dir Skalierbarkeit mitbringen, hast du ein Kubernetes oder irgendwie sowas, Autoscaling, all diese Dinge wird durch Container extrem vereinfacht und dadurch wird die Microservice-Entwicklung auch extrem vereinfacht, weil du besser oder einfacher oder automatisierter skalieren kannst. Genau.

Geek

00:09:47

Versuchen wir mal das jetzt so ein bisschen zu, also ich merke, du hast eine Definition, es gibt verschiedene Definitionen, wie können wir für uns jetzt definieren, das ist ein Microservice. Wenn ich meiner Mama versuche zu erklären, dies ist ein Microservice, was ist das?

Florian

00:10:00

Ein Microservice ist eine Softwarekomponente, die entweder eine abgegrenzte fachliche Funktionalität oder eine Infrastrukturfunktionalität abbildet. Fachlich, was ich gerade sagte, eine Benutzerverwaltung oder Videostreaming. Die aber auf der anderen Seite unabhängig von anderen Komponenten ausführbar ist. Bedeutet, ich kann einen Microservice starten selber auf meinem Rechner und auf einem anderen Rechner kann ich einen anderen Microservice starten. Und das ist auch ein wichtiger Punkt und deswegen bringen Microservices auch viel in Richtung Organisation mit und Organisationsumstrukturierung. Ein Microservice wird in der Regel immer von genau einem Team betreut. Das heißt, ein Team von Entwicklern, vielleicht auch von Operators, da gibt es auch verschiedene Ansätze zu Team-Topologies und diese Dinge, ist immer für ein Microservice verantwortlich. Kann natürlich für mehrere Microservices verantwortlich sein, aber ein Microservice wird immer von genau einem Team betreut. Das ist so eine der klassischen Definitionen. Also abgegrenzte Funktionalität und du hast dieses eine Team, was dafür verantwortlich ist, kann Microservices unabhängig von anderen starten und Microservices sind für alles verantwortlich oder für alles selbst verantwortlich, was so Dinge betrifft wie, wie baue ich jetzt eine Interaktion mit einem anderen Microservice auf oder mit einem anderen System auf. Das heißt, du hast nicht mehr so diese Dinge mit, wir sind in einem Monolithen, die Dinger, also Microservices die Komponenten in einem Monolithen kommunizieren irgendwie miteinander über. Interprozesskommunikation, irgendwie im Rahmen des Rechners oder sowas, sondern bei Microservices habe ich in der Reihe Netzwerkkalls und diese Netzwerkkalls müssen meine Microservices auch selbstständig abbilden. Das heißt, ich habe sehr viel Verantwortung in den Services selber drin liegen und dadurch eine sehr starke Provision der Services, aber auch eine sehr lose Kopplung. Das ist so. Die Definition und die Vorteile des Ganzen, genau.

Geek

00:11:51

Ich habe immer so ein Bild im Kopf, wenn ich über Microservices nachdenke. Ich weiß nicht, ob du Rick and Morty kennst.

Florian

00:11:56

Ja.

Geek

00:11:56

Es gibt da eine Folge, da sitzen sie alle beim Frühstückstisch und da gibt es diesen kleinen Roboter. Und er fragt immer, what's my purpose? You pass butter.

Florian

00:12:04

Ja.

Geek

00:12:05

Ist das quasi akkurat? Also für diejenigen, die es nicht kennen, ihr solltet Rick and Morty gucken. Aber das ist halt dieser eine Roboter, dieser hochentwickelte Roboter, dessen einziger Purpose ist es eben, die Butter weiterzugeben. Ist das sozusagen die Idee des Microservices. Es macht ja eine Business-Funktion, es hat einen Value, oder?

Florian

00:12:23

Richtig, genau.

Geek

00:12:23

Und ansonsten macht er nichts.

Florian

00:12:26

Genau, also er macht diese eine Funktionalität, die er eben umsetzt. Auch darüber kann man sprechen, wie groß ist diese Funktionalität, welchen Umfang hat sie? Darüber kann man alles diskutieren, aber ein Microservice setzt genau eine Funktionalität im Rahmen in der Regel eine Business-Funktionalität und in den meisten Fällen eine Business-Funktionalität optimal um. Was man sehr oft da findet, ist eben dieser Zusammenhang zu diesem Unix-Gedanken, Also da draußen die Leute, die irgendwie Linux benutzen und auch Mac-User sind damit wahrscheinlich stark vertraut und Menschen, die heute Windows mit dem WSL benutzen, wahrscheinlich auch. Also ich habe verschiedene Dienstprogramme und jedes Jahr Dienstprogramme macht eine Sache dafür aber richtig gut und ich kann diese Dienstprogramme hintereinander schalten. Und das ist eigentlich eine Analogie, die bei Microservices eigentlich auch genauso zutrifft.

Geek

00:13:07

Okay, das heißt, im Grunde genommen gibt es das schon lange. Also diese CD-Sache, die ich eben gesagt habe mit Monolithen auf meinem Rechner, stimmt nicht so ganz, sondern es stimmt so in Teilen. Es gibt schon modulare Ansätze und eigentlich nimmt man verschiedene kleine Teile, die machen alle ein Stückchen der Wertschöpfungskette und die kombiniert man einfach clever und einer der Gründe, über den wir jetzt ja schon gesprochen haben, ist sehr stark das Organisatorische, also wie kann ich es schaffen? Ich stelle mir immer die Frage, ich habe letztens gelesen, Spotify lässt wieder 900 Engineers gehen, die haben irgendwie 1600 Engineers. Und jetzt ohne Scheiß, Spotify lässt mich Musik hören und sagt mir, diese Musik solltest du auch hören. Und ich frage mich, wie man jahrelang daran arbeiten kann und 1.600 Engineers bei Laune hält, dass sie auch was tun können. Aber tatsächlich unabhängig davon, wo jetzt die Arbeit herkommt, dass sie arbeiten können, bedeutet ja, dass sie sich möglichst irgendwie aufteilen können. Seien es irgendwelche Themen wie ein Team muss sich eine Pizza teilen können und so weiter. Du kannst ja nicht 1.600 Leute an demselben Ding arbeiten lassen. Wer kann denn so einen Planungsaufwand leisten? Das kann ja keiner. Also musst du es ja irgendwie schneiden. Und Microservices helfen uns zu schneiden. Und die Frage ist aber jetzt, wo schneidet man denn eigentlich? Also woher weiß ich, wie klein ich das machen muss und gibt es da Best Practices, gibt es da Ideen? Also was sind so die Heuristiken, nach denen man vorgeht, um zu sagen, okay, das ist jetzt eine Funktion, die lohnt es sich in einem Microservice zu machen und darf man vielleicht auch mal zwei in einem Microservice haben?

Florian

00:14:32

Es keine allumfassende Antwort gibt, meiner Meinung nach. Also zunächst mal, was du gerade sagtest mit dem Schneiden und Software vernünftig aufteilen und auch, dass dein Office, das du vielleicht irgendwie von der CD auf deinem Rechner installiert hast und sowas, dass das sauber strukturiert ist. Das stimmt alles. Also diese Dinge mit hoher Kohäsion, lose Kopplung, vernünftige Schnittstellen. Kannst du nochmal kurz.

Geek

00:14:52

Du hast es schon zum zweiten Mal gesagt, lose Kohäsion und die Kopplung.

Florian

00:14:56

Hohe Kohäsion, lose Kopplung.

Geek

00:14:57

Ja, sorry.

Florian

00:14:58

Genau, ist eigentlich so ein Ding, das ist so seit seit den 70er Jahren schon, glaube ich, zum Prinzip erhoben worden, was eben grundlegende Qualitätsattribute von einem Software-Modul eben sind. Hohe Kohäsion bedeutet, dass ich in meinem Modul oder meiner Funktion. Meiner Klasse, meiner Methode, also in jedem Stück oder jedem Ansatz, mit dem ich irgendwie meinen Quellcode strukturieren kann, im Endeffekt zusehe, dass die Dinge zusammengehörig, zusammengefasst sind, die sich auch im gleichen Maße ändern. mindern. Bedeutet sowas wie, wenn ich jetzt ein Modul Benutzerverwaltung habe, habe ich da alle Funktionen irgendwie drin, die was mit Benutzerverwaltung zu tun haben, weil ich weiß, wenn irgendwas an der Benutzerverwaltung kaputt ist oder ich muss irgendwas hinzubasteln oder sowas, muss es irgendwie erweitern, dann weiß ich, ist dieses Modul davon betroffen und im besten Fall ist auch nur dieses eine Modul davon betroffen. Und lose Kopplung bedeutet im Endeffekt, dass ich sage, dass ich die Abhängigkeiten zwischen meinen Modulen oder meinen Methoden, meinen Klassen, was auch immer, möglichst minimiere, möglichst minimal halte. Bedeutet, wenn jetzt irgendwie jemand mit der Benutzerverwaltung interagieren muss, dann bietet das Modul der Benutzerverwaltung hoffentlich eine vernünftige Schnittstelle an, über die das getan werden kann und auch nur über diese Schnittstelle oder API, also nur darüber, über diesen Abstraktionsmechanismus, kann ich mit den Funktionen in meinem Benutzerverwaltungsmodul sprechen. Alle anderen Konzepte, Funktionen, Klassen, die irgendwas mit Benutzerverwaltung zu tun haben, sind in diesem Modul gekapselt und nur über diese Schnittstelle nach außen erreichbar und auch nur diejenigen, die ich freigebe. Das ist das, was man eigentlich möchte. Also Dinge, die sich in gleichem Maße ändern, zusammenfassen, kapseln und dann über vernünftige Schnittstellen nach außen geben und die sind auch nur über diese Schnittstellen erreichbar. Dann kann ich nämlich kontrollieren, welche Konzepte werden wo in meiner Software benutzt. Ich habe eine bessere Testbarkeit, all diese Dinge. Und hohe Kohäsion, genau, ist auf der einen Seite eben die Zusammenfassung von Dingen, die sich in gleichem Maße ändern. Lose Kopplung ist eben möglichst Abhängigkeiten zu minimieren und das sind Prinzipien, die kennt man in der Softwareentwicklung, Softwareengineering seit den 70er Jahren. Es ist ein alter Hut sozusagen.

Geek

00:17:03

Das wäre auch genau meine Frage. Wenn wir jetzt, Objekte, Klassen, Libraries, Module haben. Wo unterscheidet sich das auf der anderen Seite von Microservices? Der einzige Unterschied, den ich so für mich heute sehe, ist, die machen eine Netzwerkkommunikation. Bei den anderen gehen die über Sockets oder sonst was. Man weiß nicht, wie die genau kommunizieren, aber werden die schon schaffen. Aber im Grunde scheint mir das architekturell ähnlich zu sein. Nur, dass du diesen verteilten Aspekt hast. Also Microservices dürfen nochmal eine Netzwerkverbindung oder sonst wie Restfull sind die ja meistens, dass du irgendwie über Restschnittstellen gehst. Und bei dem anderen, da gelten ja dieselben Prinzipien dann, dass man sagt, teile deine Software mal sinnvoll auf, weil in der Informatik lernen wir, Probleme klein zu machen, dann gibt es eine Separation of Concerns und jedes Problem wird in seinem Kontext bearbeitet, dann ein bisschen Don't Repeat Yourself, dass man den Code nicht immer Copy-Paste in alles reinmacht, also irgendwie schlau schneiden, dass man nicht zu viele Abhängigkeiten hat, aber doch schon klare Zuständigkeiten in der Software. Und da scheint mir Netzwerkverbindung quasi das konstituierende Element für Microservices zu sein oder ist das zu kurz gegriffen?

Florian

00:18:09

Ja, es ist ein bisschen zu kurz gegriffen tatsächlich, weil du bei den anderen Prinzipien, die ich genannt habe, gerade bei so bei Monolithen und so, da kann es ja halt passieren, du hast das Ganze in der Regel in einer Codebase und jetzt hast du jemanden da, der kennt die Architektur nicht. Softwarearchitektur ist ja nur noch was, das durch Code quasi abgebildet wird, aber die ich jetzt nicht auf einen Blick sofort erfassen kann. Gerade wenn es ein riesengroßes, komplexes System ist, sehe ich nicht, wie die intendierte Architektur ist. Außer ich habe eine saube, vernünftige Dokumentation. Vielleicht habe ich auch im Architekturtest, die es ja mittlerweile auch Ansätze für gibt, die im Endeffekt die Struktur überprüfen und die auch sicherstellen, dass ich diese Struktur nicht brechen kann. Wenn ich jetzt aber eine große Codebase habe, dann, wer verbietet es mir denn, wenn ich jetzt all diese Mechanismen nicht in place habe? Habe, zum Beispiel jetzt in der Benutzerverwaltung eine Klasse zu verwenden, die vielleicht public ist, die aber gar nicht intendiert dafür ist, dass ich sie in irgendeinem anderen Modul meiner Software verwende. Also weiß ich nicht, sowas wie Rechnungserstellung. Das Rechnungserstellungsmodul benutzt jetzt auf einmal irgendein Konzept aus der Benutzerverwaltung, auf das es überhaupt gar keinen Zugriff haben sollte, weil es keinen Sinn macht. Und bei Microservices ist es ja so, jeder Microservice ist eigentlich eine eigenständige Applikation. Die Codebases sind in der Regel getrennt. Wenn es nicht der Fall ist, so zwingt dich doch zumindest eine Microservice-Architektur genau in dieser Richtung zu denken, nämlich in eigenständigen Applikationen. Und dann kann ich nicht sagen, ich greife jetzt aus der einen Applikation auf eine Klasse in der anderen Applikation zu, weil es eben getrennte Applikationen sind. Das heißt, dieser Trennungsgedanke und dieser lose Kopplungsgedanke übersteigt eigentlich das, was du bei einem Monolithen hast. Was damit zu tun hat, was du gesagt hast, Netzwerk-Calls auf jeden Fall, weil wenn ich Netzwerk-Calls machen will, dann habe ich in der Regel zwei Applikationen, die getrennt sind, die auf verschiedenen Maschinen laufen können, die miteinander reden müssen. Bei Monolithen ist es halt alles irgendwie im Rahmen Interprozess-Kommunikation. Da sehe ich das ja gar nicht. Da bin ich gar nicht dazu gezwungen zu denken in Applikationen, die verteilt sind. Also wirklich in einem echten, richtigen, verteilten System, wo meine Komponenten auch verteilt sind. Ja, also das ist der, dadurch, wenn du die Vorteile an Microservice-Architektur wirklich heben willst, musst du in verschiedenen Applikationen denken, die über Netzwerk-Calls miteinander sprechen, das ist richtig. Das zwingt dich dann eben dazu, auch eine vernünftige Modularisierung zu machen und nicht mehr irgendwie, oder du kommst nicht mehr so schnell in die Verlegenheit zu sagen, ich nutze jetzt Bestandteile an Quellcode, die in einem anderen Modul liegen oder einem anderen Microservice liegen, weil es technisch gar nicht mehr möglich ist. Nichtsdestotrotz, die andere Frage, was du sagtest, und das ergibt sich im Endeffekt daraus, wie schneide ich meine Software denn vernünftig in Microservices? Und da gibt es keine Best Practices. Also es gibt jetzt nichts, wo du sagen kannst, ich habe jetzt folgende Software und ich mache jetzt diese fünf Schritte und dann bin ich in einer Microservice-Architektur. Sondern es gilt eben das Prinzip, schneide deine Software so, dass du in jedem Microservice, dass er eine Funktionalität abbildet. Jetzt ist die Frage, was ist eine Funktionalität? Ist das sowas wie Benutzer erstellen, ändern, löschen? Das ist meine Funktionalität, die hängt an dem Benutzerkonzept. Oder aber sage ich, ich mache aus jeder von dieser Funktion einen eigenen Microservice, hat man auch schon gesehen, tendenziell wahrscheinlich eher nicht. Es gibt aber da in dem Moment keine, dass du sagst, ich habe mal mit jemandem gesprochen, der meinte irgendwie, Microservice sollte nicht mehr als 100 Lines of Code haben. Das ist vollkommen, also in meinen Augen vollkommen falscher Rat. Rad, genau, weil dann habe ich irgendwie weiß ich nicht, eine Applikation, die hat 20.000 Lines of Code, ja und dann habe ich da eben meine 200 Microservices, damit jeder von denen irgendwie nur 100 Lines of Code hat. Das wird schwierig, vor allem wie du schon sagst, Netzwerk-Calls, Netzwerk-Calls sind teuer, dauern lange oder länger als jetzt irgendwie eine Interprozess-Kommunikation und wenn dann meine Software am Ende einfach deutlich langsamer ist als vorher, warum sollte sie dann jemand benutzen wollen? Also welche Vorteile habe ich mir dadurch erkauft? Keine. Zumal die Strukturierung an der Stelle wahrscheinlich auch nicht sinnvoll gewählt ist. Jetzt kann man sagen, okay, ich meinte ja gerade sowas wie Wartbarkeit, Skalierbarkeit spielt auf jeden Fall mit einer Rolle rein. Das sind wichtige Dinge, die ich berücksichtigen muss, nur ich habe am Ende immer den Trade-off oder ich muss immer gucken, dass ich dahingehend optimiere, dass ich sage, ja, ich habe jetzt diese Skalierbarkeit und Wartbarkeit erreicht, aber ich habe immer noch relativ wenige oder nur so viele Microservices, wie ich tatsächlich brauche, um eben diese Vorteile zu heben und sie nicht dadurch zu reduzieren. Zunichtet zu machen, dass ich sage, ich habe jetzt sehr, sehr viele Netzwerk-Calls und das ganze Ding ist langsamer als vorher. Also das ist schon, das ist ein Trade-Off, den hast du immer und in meiner Meinung nach findest du das auch nur raus, indem du, wenn du jetzt einen Monolithen hast, den du umsetzen willst oder meinetwegen baust du auch was Neues from scratch, indem du die ganze Zeit immer im Blick hast, das kann mir passieren und auch regelmäßig misst, wie gut sind wir jetzt eigentlich im Moment und vielleicht muss ich Funktionalitäten auch wieder zusammenlegen. Kann dir auch passieren. Aus pragmatischen Gründen, du sagst, konzeptionell sind diese Funktionalitäten sauber voneinander getrennt, aber die werden diese beiden Microservices, wo diese Funktionalitäten drin liegen, tauschen sich so oft aus, dass es eigentlich Sinn macht, die wieder zusammenzulegen, weil sonst ist es unfassbar langsam. Also das ist immer so Trade-off-Theorie-Pragmatik.

Geek

00:23:06

So wie bei Datenbanken, wenn du sagst, normalisiere ich alle meine Daten, mache ich es nach Lehrbuch oder mache ich es nach reeller Welt, wo ich es verwenden möchte, da ist es vielleicht sinnvoll, dann bestimmte Daten doch redundant zu halten oder sonst wie anarbeitig zu machen. Wo du es jetzt auch gesagt hast, es sind ja verschiedene Applikationen, die Microservices und wir hatten über den Overhead auch schon gesprochen und eigentlich ist es ja tatsächlich so, dass die jetzt viel mehr Aufwand sind, weil jede einzelne Komponente muss ja auch Authentifizierung mitbringen, muss ja vieles mitbringen, muss ja auch über Konsistenzen nachdenken. Also wenn zwei Instanzen gleichzeitig sind, über Skalierung reden wir gleich noch, wenn es mehr Microservices gibt, die für dasselbe zuständig sind, weil wir das ja auch noch machen können. Also musst du quasi so ein Multithreadedness über Netzwerke hinkriegen. Aber bleiben wir erstmal bei den eigentlichen Herausforderungen der Microservices. Ist es, ich habe eine Netzwerkkommunikation und ich möchte jetzt irgendwie sicherstellen, dass nur authentifizierte Player mitmachen dürfen. Ist das nicht allein schon eine ganze Menge Overhead für Pass the Butter als einzelne Funktion?

Florian

00:24:04

Ja, ist es. Deswegen kann man auch nicht jedes System da draußen, und das macht nicht Sinn, jedes System da draußen nach Microservices zu migrieren, nur weil jetzt irgendwie große Player das gesagt haben. Es gibt so ein famous quote, ich weiß jetzt gerade den Namen leider nicht von der Person, die das gesagt hat, dass es schön und gut ist, dass dass Microservice-Architekturen ja von Netflix, Amazon, Spotify und sowas propagiert werden. Aber du bist nicht Netflix, Amazon, Spotify in 99 Prozent der Fälle.

Geek

00:24:28

Und dagegen kann man halten, Shopify, vermutlich das größte Projekt auf Ruby on Rails, war zu meinem letzten Kenntnisstand ein kompletter Monolith, bewusst gewählter modularer Monolith.

Florian

00:24:39

Vollkommen in Ordnung. Also das ist etwas, bevor ich jetzt die Entscheidung treffe, meinen Monolithen irgendwie zu zersägen und nach Microservices zu migrieren, etwas, das ich in der Regel vorher tun sollte. Ich sollte wirklich gucken, ist der Schmerz, den ich empfinde, groß genug, dass es das rechtfertigt? Also habe ich Skalierungsprobleme? Habe ich eine riesengroße Nutzerzahl, die sowas rechtfertigt? Habe ich extreme Wartbarkeitsprobleme? Denn bevor ich jetzt irgendwie sage, ich habe einen gut funktionierenden Monolithen, na klar hat der irgendwie seine Kinderkrankheiten, vielleicht sind Dinge nicht so geschnitten, wie es sein sollte. Man hat an einigen Stellen vielleicht auch irgendwie über die Jahre, wenn es historisch gewachsen ist, mal nicht auf die Architektur geachtet. Alles fein, kann passieren. Aber dann sollte ich erstmal überlegen, kann ich diese Probleme mit einem Refactoring des bestehenden Codes unter Beibehaltung der Architektur aus der Welt räumen? Oder muss ich wirklich eine Migration Richtung Microservices machen? Brauche ich das überhaupt? Und wie gesagt, in der Regel ist die Antwort darauf, nein. Muss man ganz klipp und klar sagen. Und das ist, meine ich auch mit Ernüchterung vorhin, das ist etwas, was viele mittlerweile erkennen. Ich habe jetzt die Tage auch irgendwo einen Artikel gelesen auf einem, sage ich mal, einschlägigeren Portal, so im IT-Bereich, wo eben drin stand, ja, viele Mittelständler erkennen mittlerweile, ey, das mit der Microservice-Migration war keine gute Idee, wir gehen wieder zurück. zurück.

Geek

00:25:52

Die Frage ist, was man sich davon verspricht. Da kommt dann mein Produktlerherz mit raus und bei der Architektur ist es ja auch so. Ich kann halt nicht auf alles optimieren. Ich habe halt bestimmte Dinge, auf die kann ich optimieren und da gilt es natürlich zu sagen, was sind eigentlich meine Architekturprämissen? Was möchte ich tun? Möchte ich Skalierbarkeit? Möchte ich Geschwindigkeit? Möchte ich Sicherheit? Bei einer Bank ist es sicherlich eher nicht so das Thema, es muss möglichst schnell sein, sondern wäre ganz gut, wenn das Geld, was auch verschickt wird, jemals ankommt. Somit ist bei denen die oberste Prämisse nicht, es muss ganz schnell gehen, sondern es muss da sein. Also jemand, der sein Erspartes verliert, wird dauer. Bei jemand anders, der vielleicht ein Gewinnspiel online anbietet, ist es vielleicht nicht so wichtig, dass jede Anfrage durchkommt, weil die wissen gar nicht, dass sie nicht durchgekommen sind, können sie sich sagen. Aber es muss halt irgendwie schnell gehen oder es muss skalierbar sein. Das System muss nicht zusammenbrechen, wenn alle Leute gleichzeitig um 16.25 Uhr einmal kurz drauf klicken, Antwort A ist die richtige, in irgendeinem Online-Ding. Und so gilt es eben rauszufinden und zu sagen, was sind eigentlich meine Architekturprinzipien, nach denen ich jetzt optimieren möchte, was ist mir wichtig in der A-B-Klasse und dann vielleicht, was ist auch gar nicht wichtig. Und dann kommst du, glaube ich, relativ schnell, wir sprachen schon kurz über Datenbanken, kommst du zu verteilten Systemen einfach und dann bist du mitten in CAP-Land, wo du halt sagst, das CAP-Theorem, was der ein oder andere da draußen vielleicht schon kennt, wo man sagt, jedes verteilte System zeichnet sich halt durchaus, es hat drei verschiedene Arten von Eigenschaften. Das eine ist, was war nochmal, C stand für Kapazität, nicht Kapazität. Konsistenz. Konsistenz, genau. C ist Konsistenz, dass die Daten also stimmen zwischen den verteilten Nodes. Wenn ich zwei Server habe, auf denen mein Girokonto geführt wird.

Florian

00:27:26

Synchronisiert, ja.

Geek

00:27:27

Wäre das cool, wenn auf beiden stehen würde, dass ich 1.000 Euro auf dem Konto habe.

Florian

00:27:30

Ja.

Geek

00:27:31

Das ist Konsistenzthema. Dann war das Availability-Thema. Also das heißt, ich kann darauf zugreifen. Ich kann sowohl bei dem einen als auch bei dem anderen abfragen, ob ich 1.000 habe. Und dann habe ich das dritte, Ausfallsicherheit. Das heißt, wenn der eine ausfällt, hat der andere meine Daten. Jetzt das Problem bei dem CAP-Theorem, dass man sagt, alles drei wirst du nicht kriegen, weil du musst halt dich für zwei entscheiden. Du kannst nicht sowohl alle Daten überall haben und es muss sofort verfügbar sein und es kann ausfallsicher sein, sondern du musst halt entweder sagen, die Daten sind konsistent und verfügbar, dann sind sie aber nicht ausfallsicher, weil dann gibt es halt kleine Ausfallzeiten für die Synchronisierung oder du hast ausfallsicher und available, aber dann sind sie nicht konsistent, weil dann kann es sein, dass sie auseinander gehen. Und Microservices müssten dann ja eigentlich auch das klassische CAP-Phänomen mitbringen, oder?

Florian

00:28:17

Ja, klar. Also wir reden von verteilten Systemen. Das heißt, alle Vor- und Nachteile verteilter Systeme habe ich bei Microservices auch. Also das fängt bei sowas an wie CAP-Theorien und Datenkonsistenz. Sehr oft tradet man eben das C gegen A und P. Das hast du auf jeden Fall. Du hast aber auch solche Dinge wie, du musst dir ja das grundlegende Kommunikationsparadigma erstmal angucken. Also was heißt das? Bedeutet im Endeffekt, wie oder auf welche Art kommunizieren meine Microservices miteinander? Und das meine ich jetzt nicht technisch und das meine ich auch nicht im Sinne von Synchron-Asynchron, was sicherlich auch nochmal eine wichtige Entscheidung ist, die zu treffen, sondern sowas wie mache ich Choreografie oder Orchestrierung? Also das heißt, habe ich zum Beispiel einen Microservice, der fünf andere Microservices anweist, was sie zu tun haben und auch die Koordination übernimmt, das wäre dann der Orchestrator, oder habe ich eine Choreografie, das bedeutet, meine Microservices sind eigentlich Aufrufketten. Ein Microservice ruft den nächsten auf, der ruft wiederum den nächsten auf und so weiter und so fort. Das sind auch Dinge...

Geek

00:29:17

Flache oder starke Hierarchien sozusagen. Also einer hat den Chef da in dem Ring oder...

Florian

00:29:22

Denn wenn ich den Chefansatz fahre, also sprich Orchestrierung mache, dann erhöhe ich ja wieder die Abhängigkeiten, weil ich bin auf diesen einen Orchestrator immer angewiesen, dem muss es geben. Wenn der mal irgendwann nicht funktionieren sollte, dann geht auf einmal nichts mehr in Anführungszeichen. Und bei einer Choreografie, da sind es dann Aufrufcalls. Dann geht es halt an die nächste Microservice-Instanz. Okay, die geht vielleicht kaputt, aber dann kann vielleicht der Vorgänger-Microservice nochmal einen anderen Microservice aufrufen oder eine Instanz dieses Microservices wieder aufrufen. Also das ist eben auch eine Frage, die da eine Rolle spielt. Nebenläufigkeit ist sowieso schon schwierig, wenn ich eine Monolithen irgendwie habe. Nebenläufigkeit ist generell schwierig. Threading, klassisches Threading.

Geek

00:30:03

Erklär kurz Nebenläufigkeit.

Florian

00:30:04

Naja, dass eben verschiedene Bestandteile meines Codes quasi parallel ausgeführt werden könnten. Weil mein Betriebssystem, der Scheduler, so schlau ist zu sagen. Schneide jetzt irgendwie den Programmablauf in Zeitscheiben und es sieht quasi so aus, als würden verschiedene Bestandteile meines Codes parallel ablaufen, auch wenn sie das jetzt effektiv gar nicht tun, aber es wirkt so. Viele Probleme, die du hast, kannst du parallelisieren. Das ist eine ganz schöne Sache, dadurch werden die Dinge schneller, weil du deine Prozessorkerne optimaler ausnutzt. Und das habe ich jetzt vielleicht bei einem Monolithen auf meinem lokalen Rechner, aber wenn ich jetzt irgendwie meine Software habe und das sind Microservices und ich habe zehn Microservices, die verteile ich auf zehn Server, dann kann es mir natürlich passieren, dass da Dinge, oder dann wird es mir passieren, dass da Dinge parallel laufen, dass der eine Microservice vielleicht damit eine Aufgabe schneller fertig ist als ein anderer Microservice. Das heißt, ich brauche irgendeine Koordinierung, weil die vielleicht sich an einem gemeinsamen Punkt die Ergebnisse wieder zusammengefasst werden müssen und all solche Dinge. Also das ist etwas, was bei einem verteilten System im Bauch sozusagen mit drin ist und was ich auch niemals umgehen kann. Und das sind alles Sachen, mit denen ich mich vorher auseinandersetzen muss. Also was du gerade sagtest, CAP-Theorem spielt eine Rolle, diese Geschichte mit Orchestrierung, Choreografie, dann so Sachen wie mit Nebenläufigkeit sind alles Komplexitäten, die ich mir bei einer Microservice-Architektur mit reinhole. Und da muss ich eben dann am besten vorher so eine Art Bilanz schon ziehen und einen Abgleich machen. Ist es mir das wert? Sind die Schmerzen in Skalierbarkeit, in Wartbarkeit so groß, dass ich das wirklich haben will und dass ich das wirklich in Kauf nehme? Dem muss man sich gewahr werden, auf jeden Fall.

Geek

00:31:38

Lass uns über State sprechen.

Florian

00:31:39

Über State, ah, sehr gerne.

Geek

00:31:41

Wo wir beim Orchestrator schon sind. Wer weiß eigentlich, was da gerade Phase ist, wo es gerade langläuft? Weil wir haben ja eigentlich einen Prozess, der mehrschrittig ist, also entweder in der choreografierten Fassung, der mehrere Stages durchläuft, einen Antrag für eine neue Versicherung, wo Prüfungen durchgehen, wo vielleicht nochmal Tarife gecheckt werden. Also alles, was irgendwie mehrschrittig ist und abläuft, hat ja irgendeine Art von State. Also wenn ich es in einem Schritt machen kann, dann bin ich bei dem Taschenrechner-Beispiel mit wenig Komplexität, dann muss ich mir keine States merken. Was ist State? Wie merkt man sich das bei Microservices? Wo sind die Herausforderungen?

Florian

00:32:18

Also State grundsätzlich erstmal, Übersetzung ist ja Zustand, so irgendwie, Software hat einen Zustand, wenn man das jetzt wieder irgendwie auf, weiß ich nicht, im Java-Universum sind oder objektorientierte Programmierung als solche, gucken uns eine Klasse an, ich instanziiere eine Klasse, erzeuge ein Objekt davon, die Klasse hat fünf Attribute, da stehen fünf Werte drin, dann sind diese fünf Werte in dem Objekt der Zustand von diesem Objekt. Und das habe ich bei jedem Programm, auch bei dem Taschenrechner-Programm, was du gerade sagtest, könnte man als State sowas wie Speicher zum Beispiel sehen, ich habe irgendwie jetzt ein Ergebnis, das lege ich in meinem Speicher ab, dann erzeuge ich ein anderes Ergebnis, lege ich einen anderen Speicher ab und greife auch beide Speicher wieder zu, um diese Ergebnisse irgendwie vielleicht zu multiplizieren oder sowas. Das heißt, so ein Taschenrechner hat theoretisch ja auch schon irgendwo ein State, ne? Bei Microservices ist das State-Handling wichtig, denn ich muss mir klar machen, dass ich meine Microservices eigentlich im besten aller Fälle immer stateless halte. Das heißt, so ein Microservice hält, oder sagen wir mal anders.

Geek

00:33:16

Also ich kriege alles geschickt, was ich brauche, um den Job zu erledigen.

Florian

00:33:19

Ja, oder aber ich halte es irgendwo vor, wo es egal ist, ob jetzt der Microservice abstürzt oder nicht. Also an der Stelle vielleicht auch nochmal eben kurz, weil es wird oft auch in diesen Microservice-Diskussionen miteinander vermischt. Microservice würde ich jetzt mal eher mit einer Klasse gleichsetzen. Ich habe irgendwo meinen Programmcode, den kann ich ausführen. Und worüber wir eigentlich dann reden, wenn es um State geht, ist eben die Instanz. Also im Klassenfall wäre es das Objekt und bei Microservice wäre es einfach eine Microservice-Instanz. Das heißt, wenn ich jetzt eine Microservice-Instanz habe, entweder macht man es so, wie du es gerade gesagt hast, Die kriegt alles geschickt, was sie braucht, führt dann ihre Funktionalität aus, liefert das Ergebnis zurück, muss es auch nirgendwo zwischenspeichern und der Empfänger ist mit dem Ergebnis glücklich. Das heißt, die Microservice-Instanz hält keinen Zustand vor. Sie berechnet, macht Berechnungen auf Basis von Eingabewerten und schickt einen Ausgabewert raus, ohne irgendwelche Zwischenergebnisse irgendwo speichern zu müssen oder zumindest sich nicht darauf verlassen zu müssen, dass diese Dinge beim nächsten Aufruf auch wieder da sind, derselben Instanz.

Geek

00:34:13

Klingt sehr robust, aber klingt auch sehr nach Overhead, weil wenn ich jetzt so eine orchestrierte Variante habe oder eine choreografierte. Mit sieben Schritten und ich muss bei jedem Schritt alles mit übergeben, habe ich relativ viel Overhead, um die einzelnen Dienste dann aufzurufen. Gerade wenn es jetzt vielleicht noch Dokumente gibt, die ich da weiterverarbeite. Hier, ich schicke dir noch eine PDF-Datei mit, 4 Megabyte. Das ist das Antragsformular, was er ausgefüllt hat. Hier, nimm das mal. Das ist natürlich relativ viel dann. Der Teil ist super robust unabhängig, weil jeder Anfrager hat alle Daten. Das heißt, ich habe wenig Dependencies. Und super testbar, schön isoliert für sich, aber ist halt auch teuer irgendwie.

Florian

00:34:51

Genau, ist teuer, also führt unter Umständen zu Overengineering, weil du auf einmal da auch wieder, das ist ja auch ein Teil von Komplexitäten, du hast auf einmal Dinge in deinem Quellcode drin, wo du dich erstmal fragst, warum steht das überhaupt hier? Weil wenn ich mir die Funktionalität als solche angucke, macht es gar keinen Sinn, dass ich so viele Daten durch die Gegend parse. Mache ich aber, weil sonst habe ich ein Problem, ich habe die Daten nicht zur Verfügung. Das ist eine Möglichkeit zu sagen, ja, wir übertragen alle Daten mit, erhöht natürlich auch wieder Netzwerkaufwand. Das heißt, es wird dann unter Umständen noch langsamer, als es vielleicht sowieso schon ist. Andere Möglichkeit sind, es gibt verschiedene Pattern, die in der Regel darauf basieren, dass dem Microservice und jetzt wirklich dem Microservice, nicht der Instanz, eine Datenbank dabei gestellt wird, in die dieser Microservice Zwischenergebnisse ablegen kann. Es gibt zum Beispiel Transactional Inbound Pattern oder Inbox Pattern oder Outbox Pattern, wo du im Endeffekt sagst, ich organisiere die Eingaben für meine Microservice-Instanzen wie so eine Art Queue. Das ist dann einfach eine Datenbank, an die darauf optimiert ist, das zu tun. Und dann können die Microservice-Instanzen eben die Ergebnisse oder die Anfragen aus dieser Datenbank abholen, bearbeiten sie und legen sie in eine Ausgangsdatenbank. Und dann werden diese mit der Zeit dann eben wieder rausgeschickt. So, das ist dann ein Microservice, der hat dann vielleicht, wenn man es jetzt überspitzt sagt, zwei Datenbanken, die noch anhängen und vielleicht sogar noch zwei kleine Hilfsprogramme, die die Queue befüllen und die die Queue auch wieder auslesen. Oder es macht ein Message Broker. Aber man merkt schon daran, du hast auf einmal deutlich mehr Komponenten in deiner Architektur, von der eigentlich nur eine einzige fachlich motiviert ist, das ist der Microservice. Und die anderen sind technisch motiviert, um zum Beispiel State zu verhindern. Das heißt, man kann das alles tun, aber man braucht eben gute Gründe, dass man sich diese Art der Komplexität in die Architektur reinholt. Und das muss einem vorher bewusst sein.

Geek

00:36:38

Für die Taschenrechner-App reicht es vermutlich nicht. Ja. Für ein Team von drei Entwicklern vielleicht auch nicht, wo man sagt, das geht alles in einer Codebasis, das muss ein bisschen größer werden. Sind Message Broker, Queues und dergleichen, sind das Konstrukte, die im Zuge von Microservices aufgekommen sind oder gab es die auch vorher schon? Weil ich überlege die ganze Zeit, wofür man die sonst braucht. Ansonsten würde man eine klassische Datenbank sehr wahrscheinlich nehmen und dann braucht man solche Dinge womöglich gar nicht.

Florian

00:37:03

Also Message Broker und sowas, das gab es ja alles vorher schon, die haben ja durchaus auch ihre Berechtigung, wenn ich eben, das meinte ich gerade mit Synchron versus Asynchron und du hattest gerade von den RESTful oder von den REST-Schnittstellen gesprochen, HTTP-Schnittstellen sind es ja vielfach, dann habe ich da in der Regel eine synchrone Kommunikation, also schicke Anfrage rein, bearbeite Anfrage, schicke Anfrage raus und der Client arbeitet erst weiter, wenn er die Antwort bekommen hat. Oder aber mache ich es asynchron und dann brauche ich in der Regel oder habe ich sowas wie einen Message Broker, also wo ich im Endeffekt als Microservice sage, ich stelle eine Anfrage, die schicke ich auf den Message Broker, der leitet sie weiter an eine Instanz des Microservices, der diese Anfrage bearbeiten kann, verarbeitet die Anfrage, schickt das Ergebnis wieder auf den Message Broker und der leitet es wieder zurück an meinen Microservice. Message Broker gab es vorher schon, ganz einfach, weil asynchrone Kommunikation damit umgesetzt werden kann, eine Möglichkeit das zu tun, hat absolut seine Berechtigung, weil es eben alle Vorteile von asynchroner Kommunikation mit sich bringt, natürlich auch alle Nachteile. Bei Microservices, das sehen wir ja auch bei einigen Kunden im Moment, die sagen, wir wollen jetzt auf Microservices migrieren und wollen sofort eine eventgetriebene Architektur. Event-Modell. Also Asynchronen, Message Broker, ob man es jetzt Event oder Nachricht nennt, kann man sich auch darüber streiten, aber wir wollen eine Event-getriebene Architektur, weil wir die volle Asynchronität haben wollen, die volle Skalierbarkeit haben wollen, weil dadurch hole ich mir noch mehr Skalierbarkeit, noch mehr Unabhängigkeit, noch mehr lose Kopplung mit rein. Nein, wollen wir alles haben, weil wenn, dann wollen wir es sofort richtig machen, in Anführungszeichen. Und das ist natürlich nochmal, nochmal ein Komplexitätsschub obendrauf oder nochmal eine Komplexitätsschippe obendrauf gelegt, weil ich dann auf einmal von meinen schönen, synchronen HTTP-Calls weg bin und habe da noch Events irgendwie mit drin. Das macht die Sache nicht einfacher. Also ich brauche wirklich gute Gründe, dass ich genau das tue. Und das ist eben Skalierbarkeit, also eine hohe Performance. Ich brauche eine bessere Testbarkeit, ich brauche eine bessere Wartbarkeit, all diese Dinge. Ja, da muss ich schon sehr gute Gründe haben, damit ich mir dann diese ganze andere Komplexität mit reinhole. Es hört ja da auch nicht auf, du brauchst dann auch sowas wie eine Container-Orchestration-Plattform, weil ohne das macht es keinen Sinn. Also irgendjemand muss ja auch gucken, dass die Instanzen der Microservices vorgehalten werden, am besten in Abhängigkeit von den Anfragen. Sowas wie Elastizität ist dann ein Buzzword in diesem Bereich. Also all diese Dinge. Und will ich das? Brauche ich das? Und wie gesagt, in vielen Fällen ist die Antwort auch einfach nein. Brauche ich nicht. Oder ich sollte vielleicht erstmal gucken, dass ich meinen Monolithen, den ich da stehen habe, vielleicht mal auf Vordermann bringe. Vielleicht ist der auch, basiert der auf, weiß ich nicht, einer Technologie, einem Technologie-Stack, der vielleicht einfach nicht so effizient ist wie ein anderer. Oder er ist veraltet und ich möchte, sollte vielleicht mal irgendwie da migrieren und dann erstmal gucken, ob es dann immer noch so schlimm ist, wie es eben ist.

Geek

00:39:43

Lass uns durch die Zeit wandern und mal schauen, zu welcher Lebenszyklusphase eigentlich welche Architektur sinnvoll ist oder besser geeignet, sagen wir es mal so. Sinnvoll ist sie vielleicht immer. Ich stelle mir vor, ich habe erstmal jetzt eine Idee. Ich habe noch keine Software. Ich bin auf einer grünen Wiese, habe eine Idee, ein Business-Problem, was ich lösen möchte. Und ich möchte relativ schnell verifizieren, ob das das auch tatsächlich löst und ob man das bauen kann. Monolith oder Microservice?

Florian

00:40:12

Es gibt auch zwei Lager. Es gibt einmal die Leute, die sagen Monolith first, also du sollst immer einen Monolithen erst bauen. Es gibt aber auch die anderen Leute, die sagen, wenn du sowieso eine Microservice-Architektur anschreibst, baue sofort die Microservices, weil sonst hast du einen doppelten Aufwand. Ich finde, die Frage kann man auch wieder nicht pauschal beantworten, hängt zum Beispiel auch mit dem Team zusammen. Ist es vielleicht ein Team, das ist so erfahren im Microservice-Bereich und so eingespielt, dann lass die Microservices bauen, weil sie wissen ja, was sie tun. In der Regel ist es aber schon so oder sinnvoller, einen Monolithen zu bauen, weil ich mir mir diese ganze Komplexität, die ich gerade so am Anfang bei einem Greenfield-Projekt, kann ich es ja vielleicht noch gar nicht abschätzen. Also habe ich da überhaupt, brauche ich diese Art der Skalierbarkeit? Wenn ich weiß, ich werde, weiß ich nicht, 10 Millionen Benutzer haben und die Business-Domäne so kompliziert, das macht alles keinen Sinn, wir müssen Microservices machen, okay, geschenkt. Aber wenn man jetzt irgendwie, weiß ich nicht, man baut einen Proof of Concept und der soll zeigen, dass man irgendwie es drauf hat, die Fachlichkeit umzusetzen, die diese Domäne eben mitbringt. Und du hast jetzt nicht Leute, die machen jetzt seit, weiß ich nicht, fünf oder zehn Jahren erfolgreich Microservices, dass die einen Monolithen bauen. Bist du auf der sicheren Seite, weil du dir eben diese ganze Komplexität, Nebenläufigkeit, also die Komplexität von verteilten Systemen nicht mit reinholst.

Geek

00:41:19

Mit meinem gefährlichen Halbwissen über DevOps weiß ich ja, du könntest ja theoretisch dir ein schönes Docker-Compose malen und da steht dann drin, ich kriege mir meinen Message-Broker hier hin, ich hole mir hier verschiedene Instanzen da hoch, ein bisschen Kubernetes orchestrieren, auch das ist 2024 nicht mehr so das große Ding. Also hat man auch schon mal geschafft, dass man das irgendwie orchestriert bekommt. Elastizität, also das Anpassen an, ich checke, wie viele Anfragen kommen und dann fahre ich mehr von den Services hoch oder eben nicht. Das kriegt man ja alles schon hin und von dem Hintergrund, dass man das schon mal gemacht hat, würdest du trotzdem sagen, man nimmt eher einen Monolithen, weil man möchte ja verproben, dass das Inhaltliche funktioniert und du hast halt weniger bewegliche Teile, an denen du dann irgendwie scheitern kannst, wo es Probleme gibt, wo du dich darum kümmern musst, sodass du also einen stärkeren Fokus hast.

Florian

00:42:02

Wäre meine Empfehlung an der Stelle, wobei ich einen Docker-Compose und Kubernetes ja auch mit einem Monolithen machen kann. Also da spricht ja jetzt erstmal nichts gegen, es trotzdem einzusetzen. Es kommt so ein bisschen halt auch auf, das meine ich gerade mit Team-Erfahrung an. Also wenn du jetzt Leute hast, die haben genau diese Microservice-Denke, da weiß jeder, was er tut. Die sind vielleicht auch eingespielt, das ist ja auch ein wichtiger Faktor. Dann lass sie eben ein Microservice bauen oder Microservice- Architektur bauen, aber, Für alle anderen Fälle, wenn es jetzt wirklich nur darum geht, erstmal eine Idee zu verproben, bauen einen Monolithen. Also du kannst, du hast gerade Shopify als Beispiel genannt. Wenn die mit ihrem Monolithen super fahren, dann ist das doch ein gutes Beispiel dafür, dass ein Monolith jetzt auch nicht die schlechteste Idee aller Zeiten ist. Selbst wenn du sagst, du willst jetzt irgendwie in die Cloud rein oder sowas. Shopify wird wahrscheinlich auch irgendeiner Art und Weise in irgendeiner Cloud sein. Dann scheint ein Monolith ja da an der Stelle zu funktionieren. Und warum dann nicht einen Monolithen bauen?

Geek

00:42:53

Streng genommen, sie nennen es einen Modolithen, den sie da haben.

Florian

00:42:56

Ah, interessant. Okay, ja.

Geek

00:42:58

Und die hatten eine lustige Darstellung, wo sie so ein Koordinatsystem hatten. Unten ist irgendwie wenig Struktur, oben ist viel Struktur. Links ist Monolith, rechts ist Microservice. Und unten war bei beidem Big Ball of Mud. Also das war halt, wenn es unstrukturiert ist, ist es halt unstrukturiert, ob du Microservices nimmst oder einen Monolithen hast. Und dann haben sie es hochgehoben und gesagt, ein strukturierter Monolith ist ein Modulit. So nennen sie sich den. Und wenn du bei den Microservices oder bei dem dezentralen, hieß es glaube ich da eher in der X-Achse, wenn du da weiter nach rechts gehst und dezentral bist und nicht bei Big Ball of Mud, sondern strukturiert bist, dann bist du bei Microservices.

Florian

00:43:35

Ja, ist auch das, was wir gerade sagten. Also Microservices zwingen dich halt dazu, stärker in den Bereich Modularisierung zu denken, wieder hohe Kohäsion, lose Kopplung, First Principles und sowas. Also du kannst das aber genauso gut mit einem Monolithen eben auch tun. Wenn er sauber, vernünftig strukturiert ist, wie du das gerade gesagt hast, dann habe ich die Schmerzen im Bereich Wartbarkeit wahrscheinlich eher nicht weil eine sauber modularisierte Software ist in der Regel gut wartbar, Performance ist oder Skalierung ist was anderes da muss ich mir bewusst sein, wenn ich das irgendwann nicht mehr hinbekomme einen Monolithen kann ich auch skalieren davon mal abgesehen, aber wenn das vielleicht irgendwann nicht mehr funktioniert und ich kann eingrenzen und kann sagen okay, das liegt daran, weil es eben ein Monolith ist, dann macht es vielleicht Sinn, in Richtung Microservices mal zu denken und zu schauen. Und da stellst du dann auch die Frage, muss ich denn wirklich meine komplette Software migrieren? Oder reicht es vielleicht auch nur, wenn Teile davon als Microservices ausgelagert werden? Das ist ja möglich. Beispiel auch wieder, wenn man an Netflix denkt. Ich meine, die sind komplett auf Microservices. Aber wenn ich jetzt irgendwie eine Plattform wieder habe, da ist eine Benutzerverwaltung drin und Streaming. Und die Domäne, in der ich mich bewege, ist Videostreaming. Dann wird wahrscheinlich eine sehr häufig aufgerufene Funktionalität das Videostreaming sein. Das heißt, es macht dann schon Sinn, das vielleicht rauszulösen und separat skalierbar zu machen. Weil Millionen Leute Filme streamen parallel. Aber vielleicht machen nur 5000 davon, ändern ihr Passwort in der Benutzerverwaltung parallel. Das heißt, dann an der Stelle kann ich vielleicht auch sagen, okay, ich belaste das jetzt in meinem Monolithen, wenn es denn ein Monolith ist. Aber es ist natürlich auch wieder genau so eine Argumentation für Microservices, dass ich gezielt skalieren kann. Ich kann sagen, dieser eine Microservice, der wird so oft aufgerufen, da muss ich eine Million Instanzen von vorhalten und von dem anderen muss ich vielleicht nur 5000 vorhalten. Der wird nicht so oft aufgerufen. Das heißt, ich kann da nochmal wirklich separat skalieren. Und das ist eben auch immer ein Vorteil von Microservices. Aber die Frage ist immer, brauche ich das wirklich? Ist es wirklich so notwendig in der Form?

Geek

00:45:29

Wenn wir weitergehen in der Zeit, wir haben jetzt gesagt, mein grandioses Projekt ist erfolgreich gewesen. Der Monolith, der gebaut wurde, dank deiner Empfehlung, hat sich bewährt und jetzt möchte ich gerne skalieren. Da gibt es für mich zwei Ebenen, auf denen ich skalieren kann. Das eine ist die organisatorische. Im Sinne von jetzt habe ich aber richtigen Geldcheck bekommen von meinem Chef, der sagt jetzt hoch raus, legen Sie mal ordentlich Geld rein und dann kann ich fünf Teams haben. Das heißt, dafür würde ich auch erst mal schauen, wie schneide ich das, dass diese Teams unabhängig voneinander arbeiten können. Aber das Spannendere für mich ist eigentlich das operative Thema mit an welcher Stelle krankt meine App? Also wo brauche ich denn viel? Wir sprachen gerade schon drüber, wenn man wieder so ein Gewinnspiel nimmt, so ein Fragespiel, Ratespiel. Die Fähigkeit, Fragen einzustellen, brauche ich relativ selten, weil ich mache ein Quiz. Aber das Abfragen oder das Raten, ist dann natürlich ein viel höher skalierendes Ding. Und jetzt die gesamte Software zu nehmen und zu sagen, packe ich einfach mal ganz drauf, der eine Code-Teil läuft halt gerade nicht, ist das äquivalent mit dem zu sagen, ich separiere einfach diesen Code-Teil raus? Also, verstehst du, worauf ich hinaus möchte? Weil ich kann ja den ganzen Code drin haben, ich kann ihn nur nicht benutzen, einfach in den Monolithen oder, und dann quasi den Monolithen siebenmal nebeneinander stellen.

Florian

00:46:46

Ja, genau, also, das ist ja, das führt ja dann wieder zu, ne, also es gibt ja auch verschiedene Arten der Skalierung, die ich fahren kann. Mache ich horizontale oder vertikale Skalierung? Vertikale Skalierung bedeutet in der Regel, ich bohre meinen Server auf, also stecke mehr Ressourcen quasi in bestehende.

Geek

00:47:00

Mehr Prozessor.

Florian

00:47:01

Mehr Prozessor irgendwie rein. Oder mache ich eine horizontale Skalierung und sage, ich stelle einfach mehrere Rechner oder meinetwegen mehrere Monolithen oder mehrere Microservices nebeneinander, also mehrere Instanzen. Bei Microservices wäre das dann der Fall. Microservice in der Regel horizontal skalierbar, weil es sind unterschiedliche Applikationen, die starte ich eben mehrfach vereinfacht gesagt. Dann habe ich sie die horizontal skaliert, fertig. Also das ist schon implizit in diesem Architekturansatz mit drin.

Geek

00:47:25

Aber ich kann sie auch andersrum skalieren. Also hätte ich jetzt einen Microservice, der relativ langsam ist, weil er zu wenig RAM hat, geht ja auch. Und ich würde ihm einfach mehr RAM geben, würde sagen, diese Instanz braucht grundsätzlich immer 128 Gig, damit die laufen kann.

Florian

00:47:38

Ja, tendenziell schon, aber in der Regel willst du ja deine Services so schneiden, dass du jeden Service separat skalieren kannst. Und wenn du diese Instanzen deiner Microservices hast, du willst auch die Flexibilität haben, die Dinger laufen ja in der Regel in der Cloud. Meistens in der Cloud, die Flexibilität haben zu sagen, okay, ich ziehe jetzt oder ich bündel jetzt die Instanzen auf diesem einen Node und vielleicht die Instanzen auf diesem einen Node und dann cluster ich das alles mal irgendwie schön. Man kann das trotzdem machen, da hast du vollkommen recht, aber in der Regel würde man dann eher sagen, bevor man jetzt losgeht und fängt an, Vertikal zu skalieren, schaue ich mir diesen betreffenden Microservice an und gucke, warum ist der denn überhaupt so ineffizient? Muss ich den vielleicht nochmal zerstückeln in mehrere? Ist das vielleicht so ein eigener Monolith? Gibt es ja auch irgendwie, dass dann Leute nach Microservices migriert sind. Ich habe da mal Ich habe auch mal eine Anekdote an einem Workshop gehört, da wurde ein System, das bestand, ich glaube, umfangbar drei Millionen Lines of Code. Vorhin habe ich nur gesagt, Lines of Code spielen keine Rolle, aber da wurden drei Microservices rausgemacht. Also es ist dann die Frage, sind das dann wirklich noch Microservices oder sind das dann schon, weiß ich nicht, Macroservices? Ich weiß nicht, ob man das beschreiben will, weiß ich nicht. Also in der Regel willst du schon in Richtung horizontale Skalierbarkeit, auch aufgrund der Flexibilität und eben Elastizität und sowas. Also ich kann jetzt nicht sagen, weiß ich nicht, Netflix, verdammt, wir haben jetzt hier irgendwie die eine Million und einste Instanz, Da muss der Techniker in den Keller und muss da RAM-Module noch reinstecken, damit die dann funktioniert und auch der eine Million einste Kunde irgendwie Video streamen kann. Also das willst du ja in der Regel nicht. Sondern bei Microservices hast du die horizontale Skalierung eigentlich schon mit dem Bauch, wenn du jetzt nicht irgendwie komplett ineffizient schneidest. Genau. Und bei Monolithen kommt es halt darauf an, kommt der Monolith, wie ist der Monolith aufgebaut? Kommt der mit horizontaler Skalierung? Klar. Klar, also oft hat man früher so Beispiele, J-Boss oder Wildfly oder sowas sind ja immer so Beispiele für klassische monolithische Anwendungen, weil diese beiden Systeme, diese beiden Applikationsserver stellen mir eine Ausführungsumgebung bereit. Ich habe alle Abhängigkeiten, die ich brauche, sind schon da. Ich muss nur noch den Java-Quellcode schreiben für meine Fachlichkeit und bin fertig. Trotzdem kommt es auf die Anwendung an, wie gut kommt die denn damit klar, wenn ich jetzt auf einmal zwei Instanzen nebeneinander stehen habe, die vielleicht auch noch gesynct werden müssen. Habe ich diese Funktionalität schon mit dabei? Dann schaltet man in der Regel einen Loadbalancer davor. Das heißt, das Problem ist schon mal gelöst. Es kommen irgendwie viele Anfragen rein, die können verteilt werden, aber kommen meine Systeme damit klar, wenn Anfragen auf einmal auf verschiedene Systeme verteilt werden.

Geek

00:49:56

Genau, dann brauchst du so eine Art Session Stickiness und selbst dann bricht dir eine Node weg und dann musst du halt überprüfen.

Florian

00:50:01

Irgendwie sowas, genau.

Geek

00:50:02

Aus Nutzerperspektive hast du ja einen State, weil in meinem Antragsvorgang läuft es immer weiter. Oder mit meinem 10-schrittigen Gewinnspiel, wer wird Millionär im Web, hätte ich gerne nach Frage 8 auch Frage 9 noch beantwortet und er soll wissen, dass ich sie alle richtig beantwortet habe.

Florian

00:50:16

Das kann dir bei Microservice-Architektur natürlich auch passieren, aber da bist du ja gezwungen, das mitzudenken. Also die ist ja von vornherein klar oder sollte zumindest von vornherein klar sein, es sind verschiedene Applikationen, die reden über Netzwerk miteinander, die können auch komplett verteilt irgendwo laufen auf der ganzen Welt. Also muss ich mir von vornherein Gedanken über genau so etwas machen wie Session Management. Auch ein Riesenthema im Microservice-Bereich. Wie regelt man sowas? Und das hast du bei einem Monolithen vielleicht am Anfang nicht mitbedacht, Weil du sagst, ich habe jetzt hier meine 5000 Benutzer, läuft.

Geek

00:50:47

Ist ja immer hier.

Florian

00:50:48

Ja, genau. Und jetzt ist meine Company auf einmal explodiert. Die Nutzerzahlen sind gestiegen. Das ist super geil. Aber vielleicht kommt der Monolith jetzt nicht mehr damit klar. Wir brauchen eine zweite Instanz, die daneben läuft. Und auf einmal stellt man fest, ja, sowas wie Session Stickiness haben wir aber nicht mitbedacht. Dann muss man es nachträglich irgendwie einbauen. Und das bereitet in der Regel dann natürlich auch Kopfzerbrechen. Das ist dann wieder so an der Stelle der Nachteil. Das ist natürlich richtig, genau. Aber wie viel willst du vorher antizipieren? Das ist auch immer so die Frage. Du willst ja KISS-Prinzip erstmal möglichst einfach halten.

Geek

00:51:17

Hast du irgendeine Idee, wie man von außen mitbekommen kann, ob man es mit einem Monolithen oder mit Microservices zu tun hat?

Florian

00:51:25

Das ist eine sehr gute Frage. Im besten Fall kriege ich das als Benutzer nicht mit. Also mir ist es egal, ob Spotify ein Monolith oder eine Microservice-Architektur ist, das Ding tut, was es soll. In der Art und Weise, wie ich es eben erwarte. Das heißt, im besten Fall sollte ich es nicht mitbekommen. Im schlimmsten Fall könnte ich es dadurch mitbekommen, dass auf einmal gewisse Funktionalitäten wegbrechen und vielleicht auch nie wiederkehren. Weil vielleicht es wurde eine neue Version eines Microservices ausgeliefert, die hat irgendwie einen Bug und jetzt lassen sich Instanzen nicht mehr starten. Auf einmal kann ich vielleicht im schlimmsten Fall über Tage hinweg so eine Benutzerverwaltung nicht mehr aufrufen. Bei einem Monolithen ist es so, in der Regel redet man über einen Deployment-Monolithen, Sprich, ich muss die komplette Anwendung zusammen deployen.

Geek

00:52:10

Ganz oder gar nicht.

Florian

00:52:11

Ganz oder gar nicht, genau. Und je nachdem, wie das Ding dann modularisiert ist, wenn ich so Fehlerkaskaden vielleicht drin habe, kann es mir auch passieren, dass vielleicht dann die ganze Anwendung weg ist, wenn auf einmal irgendwo ein Riesen-Bug drin ist. Aber hoffentlich habe ich so gute Tests da drin und ist mein Testumfang so hoch, dass ich solche Fehler frühzeitig erkennen kann. Das kann man bei Microservices, was wir auch noch gar nicht besprochen haben, ist eben dieser Team-Aspekt. Bei einem Monolithen habe ich vielleicht ein großes Team, das irgendwie daran arbeitet, habe sehr viel Erfahrungswissen da drin, Kommunikationsstrukturen mögen vielleicht ineffizient sein, aber ich habe immer Zugriff auf das gesamte Wissen im besten Fall und das ist hoffentlich irgendwo vernünftig abgelegt und dokumentiert. Bei Microservices, wenn ich komplett unabhängige Teams habe, dann arbeitet das eine Team, was so Fehlerkaskaden Vermeidung oder auch Testabdeckung oder sowas, arbeitet vielleicht besser als ein anderes Team. Dann hoffe ich doch, dass das andere Team vielleicht an Funktionen arbeitet, die nicht so wichtig sind und die stabiler laufen oder vielleicht weniger stabil laufen müssen als andere Dinge. Das sind auch so Dinge. Und Organisationsstruktur, was du gerade sagtest. Da muss ich eigentlich, wenn ich Microservices machen will, komplett umdenken. Das muss mir auch klar sein. Also das ist dann aber wieder eher eine Entscheiderebene. Also Microservice-Architektur macht eigentlich keinen Sinn, wenn ich Teamstrukturen habe, die homogen sind. Sowas wie, ich habe eine Business-Analysten-Abteilung, ich habe eine Entwickler-Abteilung und ich habe dann noch die Admin-Abteilung oder die Betriebsabteilung. Das willst du dann da an der Stelle eigentlich nicht mehr haben, sondern dann willst du eben auch heterogene Teams, die so einem DevOps-Gedanken folgen können. Das spielt eben auch mit rein. Aber ja, im besten Fall, um wieder zu der Ausgangsfrage zurückzukommen, merke ich es hoffentlich nicht, mit was für einem System ich spreche, weil ich als Benutzer erwarte eine Funktionalität und wie das dahinter umgesetzt wird, muss mir eigentlich egal sein können, wenn das Produkt erfolgreich sein soll.

Geek

00:53:59

Wo du bei den Teamstrukturen warst, so ein bisschen Conway steckt da ja auch drin. Conways Law, wo man sagt, die Art und Weise, wie du eine Organisation aufbaust, also eine Aufbau- und Ablauforganisation, spiegelt sich auch in den IT-Systemen dann ultimativ wieder. Sodass man sagt, wenn da Abteilungen zum Beispiel nicht gerne miteinander sprechen, sprechen deren Softwares vermutlich auch nicht so gerne miteinander. Und ultimativ, wenn du eben sagst, du machst Microservices, du möchtest natürlich, dass diese einzelnen vollwertigen Apps miteinander reden, dann musst du natürlich auch eine Struktur haben, die eben genau das auf organisatorischem Level erlaubt und eine Kultur, die das in irgendeiner Form unterstützt.

Florian

00:54:34

Genau, also ohne diese Kultur, und das machen sich viele Unternehmen auch nicht bewusst, dass Microservices eben nicht nur Software-Architektur sind oder irgendwas mit Technologie zu tun haben, sondern es ganz stark darauf ankommt, wie meine Organisationsstruktur ist.

Geek

00:54:49

Kann ich das nicht einfach über einen API-Gateway lösen? Also könnte ich nicht einfach meine Teams alle in den Keller sperren, jeder in den eigenen Keller, und dann sagen wir, ich mache einen API-Gateway, dann könnt ihr doch lesen, wie die alle funktionieren, dann brauche ich kein Conway's Law mehr. Ich kann mir nicht vorstellen, wie das funktioniert, aber vielleicht...

Florian

00:55:03

Also ein API-Gateway ist, glaube ich, grundsätzlich in vielen Bereichen eine sinnvolle Idee, weil es mir irgendwie Schnittstellenmanagement erlaubt. Nur wenn meine Organisation von vornherein, also es kommt so ein bisschen darauf an, wie viel Autonomie will ich meinen Teams eigentlich geben? Weil ein Vorteil, der bei Microservices auch oft mitspringt, ist Technologie-Heterogenität. Also das heißt, du kannst, weil es unterschiedliche Applikationen sind, deine Services, kannst du sie eben mit der Technologie umsetzen, die für den jeweiligen Anwendungsfall am besten geeignet ist. Weiß ich nicht, sowas wie Datenbankauswahl. Du musst irgendwie eine Zeitreihenanalyse machen. Dann nimmst du halt für diese Funktionalität, für diesen Microservice eine Datenbank, die dich genau darin unterstützt. Und für alle anderen Microservices hast du vielleicht eine stinknormale, relationale Datenbank, weil die da eben am besten funktioniert. Oder auch Programmiersprache meinetwegen. Wird auch oft gesagt, Java ist ja so unfassbar langsam, weil Garbage Collection und all diese Dinge. Gut, dann implementierst du vielleicht halt einen Großteil deiner Software in Java, weil es okay. Und vielleicht einen extrem performancekritischen Bestandteil, den implementierst du dann vielleicht in einer Programmiersprache, die eben deutlich effizienter ist. Ich war mal bei Ericsson in Göteborg, die bauen testweise, haben die nie eingeführt, aber die bauen zum Beispiel einen Prototypen für die Telekommunikations-Backend-Infrastruktur, die sie betreiben in C. Das sind C-Microservices, die da laufen. Da hast du dann aber auch Leute, die entwickeln am Linux-Körnel mit. Also die bringen diesen Hintergrund eben an der Stelle mit. Also das ist dann, wie autonom sind meine Teams? Und normalerweise sagt man, man lässt gewisse Freiheiten, aber du sagst jetzt nicht sowas wie, jedes Team kann hier frei kommen, frei und wie es möchte sich für irgendeine Technologie entscheiden, vollkommen egal, Hauptsache es funktioniert. Das würde vielleicht in einer Welt klappen, in der du super Schnittstellen, super abgestimmte Schnittstellen hast, jeder weiß, welche Ergebnisse er zu liefern hat, auf welche Anfragen, ist vollkommen egal, wie es dahinter arbeitet, alles ist super, alles ist toll und nur über diese Schnittstellen wird miteinander kommuniziert. Die Schnittstellen sind stabil, vollkommen egal, wie die Software läuft dahinter oder wie sie umgesetzt ist, alles ist super. Du hast dann noch vielleicht ein API-Gateway hoffentlich dabei, das auch noch super geil alles dokumentiert, wo ich eine super Übersicht habe, aber in so einer Welt leben wir ja nicht. Also in der Regel werden Schnittstellen, also wenn man sich das so anguckt, gefühlsmäßig aus dem Bauch raus irgendwie definiert, so wie es einem gerade einfällt und die müssen dann aber dann die nächsten fünf Jahre vielleicht leben und dann habe ich ein Problem damit, wenn ich sie irgendwie evolvieren will. Und all diese Dinge, also in einer optimalen Welt könnte man das alles so tun, aber eine API-Gateway wird das Problem an der Stelle nicht lösen, wenn eben die Kommunikationsstrukturen zwischen deinen Teams nicht auch schon genau dieser Maßgabe folgen. Also das ist ja das, was du gerade sagtest mit Conways Law. Kopie der Kommunikationsstrukturen zwischen meinen Teams in die Architektur oder die Softwarearchitektur bildet genau diese Kommunikationsstrukturen, diese Kommunikationshierarchien ab. Und das willst du eigentlich bei Microservices haben, dass die Teams eigentlich nur noch dann miteinander sprechen, wenn ihre Microservices miteinander betroffen sind. Aber ein API-Gateway wird das Problem an der Stelle nicht lösen, wenn die Schnittstellen überhaupt gar nicht klar sind und sowieso jedes Team mit jedem anderen Team redet, wie es gerade Bock hat. Also das ist Technologie geschmissen auf ein Organisationsproblem. Das wird wahrscheinlich nie funktionieren.

Geek

00:58:10

Es kann sein, dass das aus der Komplexität herauskommt oder aus so einem bisschen Siluisierungsgedanken. Ich habe auch ein bisschen darüber nachgedacht, woran könnte man merken, ob Leute Microservices machen oder ob sie Monolithen machen. Ist es die Veränderungsgeschwindigkeit, ist es Skalierung? Also nicht in dem Moment, wo ich einmal einen Button klicke, sondern generell. Und mir kommt immer wieder mein Lieblings-Hass-Beispiel der deutschen Digitalisierung in den Kopf. Ich bin Teil von diesem Deutsche Bahn Komfort, so heißt es. Ich habe einen Account. Und ich habe mir irgendwann mal ein Zugticket kaufen wollen. Du bist dann in diesem Portal und in dem Portal tippst du quasi ein, welche Zugverbindung du gerne hättest. Dann stellst du fest, wenn du es kaufen möchtest, hab vergessen mich anzumelden. Dann stellst du fest, während du dich versuchst anzumelden, oh, ich habe mein Passwort vergessen. Machst ein Passwortreset in dem ganzen Ding. Dann ist natürlich alles verschwunden, was du vorher dir an Sitzplatzreservierungen und allem zusammengesucht hast und dieser Prozess ist nicht von vorne bis hinten durchdacht worden und das ist so ein Phänomen, das sehe ich ganz oft bei gerade komplexer Software, bei Leuten oder Unternehmen, die Dinge anbieten, die nicht eben in einem Schritt taschenrechnerartig erledigbar sind. Und dann hast du natürlich schnell das Problem dieser Silos, die nicht über ihre Microservice-Grenze hinausdenken und das auch vielleicht einmal so System-under-Test einmal komplett durchgehen mit allen Fällen, sondern die sagen, ja, wenn ich folgende Daten kriege, dann funktioniert das auch. Aber jetzt werden auf einmal Leute wichtig, die so einen Integrationssystem-Test komplett vornehmen und die sagen, jetzt gucke ich mir das mal von vorne bis hinten an, ich tue mal so, als wäre ich der Anwender. Und dieses Bahnbeispiel ist ja noch das Einfachste. Also du sagst halt wirklich, ich suche mir einen Zug aus, reserviere mir einen Platz und dann vergesse ich halt mein Passwort, versuche mich anzumelden und dergleichen. Und das kann ja noch viel, viel komplizierter sein, wenn du noch mehr Schritte hast, wenn du Daten eingegeben hast, wenn ich bei irgendeinem Elster meine Steuererklärung machen möchte oder dergleichen, wo dann noch Daten fehlen, die man dann noch irgendwo suchen muss. Und das sind, glaube ich, Dinge, die auf der organisatorischen Ebene und auf der Nutzererfahrungsebene deutlich schwieriger werden. Und wenn wir darüber sprechen, zu sagen, mach mal eine gute Digitalisierungserfahrung, dann ist zwar schön und gut, dass wir jetzt so ein Separation of Concerns hinbekommen haben und gesagt haben, das kann auch alles schnell laufen, aber ich darf halt auf gar keinen Fall aus den Augen verlieren, wie spielt das denn jetzt zusammen, wie ist denn die Nutzererfahrung generell und ich muss bestenfalls mit Metriken oder wenn ich sogar Leuten über die Schulter gucken kann, prüfen, was machen die eigentlich damit und läuft das und wo bricht der Prozess sozusagen, wo haben die Leute Schmerzen und das mögen nicht die Standardfälle sein, weil die Standardfälle, die Heavy-Basis, die laufen in der Regel ziemlich gut durch.

Florian

01:00:43

Richtig. Also jetzt mal, ich weiß jetzt nicht, ob die Deutsche Bahn oder dieser Teil der Deutschen Bahn, ob das Microservices sind oder nicht, das weiß ich jetzt nicht.

Geek

01:00:51

In der Adresszeile steht immer Exe.

Florian

01:00:53

Ja, diese Query-Exe oder so, ja, stimmt, ja. Also es ist vielleicht ein Executable, vielleicht ist es ein Monolith, das weiß ich nicht. Aber du hast recht, wenn du sagst, dass, wenn wir jetzt Microservices einsetzen, so Dinge wie Testing wird natürlich auch nochmal komplizierter. Monolithen, also Integration-Testing an sich ist sowieso nicht einfach. Happy-Cases-Testen ist immer super, aber genau das sollte man ja nicht tun. Also jetzt unabhängig, was für eine Architektur ich habe, sondern sollte man auch tun. Aber du solltest natürlich auch so Dinge testen wie, ich breche jetzt den Prozess mal zwischendurch scheinbar ab, indem ich mein Passwort zurücksetze und dann sind auf einmal alle meine Daten weg. Solche Dinge sollte man natürlich auch berücksichtigen. Ist aber auch eher eine Frage im allgemeinen Testing-Bereich und weniger von der Architektur abhängig. Aber trotzdem werden so Integration-Tests bei Microservice-Architekturen schwieriger, weil ich auf einmal mehrere Applikationen hochfahren muss. Ich muss sicherstellen, dass die alle irgendwie in demselben Environment oder selben State laufen, die Datenbanken vielleicht oder diese Outboxes, Inboxes entsprechend gefüllt sind. Muss Anfragen schicken und das muss ich alles zusätzlich sicherstellen. Und dann hast du natürlich immer noch keine Aussage darüber, wie verhält sich das denn jetzt auf einmal, mal, wenn ich das jetzt nicht auf meiner lokalen Entwicklerkiste oder meinetwegen in unserem Staging-Node laufen haben, sondern in der echten Welt, wenn da wirklich jetzt mal 5.000, 10.000, 1.000.000 Benutzer drauf zugreifen. Das weißt du ja dann immer noch nicht. Und deswegen gehen Unternehmen wie jetzt zum Beispiel Netflix, die gehen dann eben her und testen teilweise Dinge in Produktion. Also da werden Sachen zur Laufzeit abgeschossen und es wird geguckt, wie sich das System verhält. So, das...

Geek

01:02:24

Genau, da bist du im Chaos-Engineering, wo du sagst... Das spielt Wir machen uns sehr bewusst, dass wir Dinge kaputt machen, weil unser Anspruch ist, da sind wir wieder bei den Architekturprinzipien, unser Anspruch ist, dass wir eine robuste Plattform haben, die verträgt ist, wenn man mal gegen tritt. Richtig. Und deswegen treten wir in Produktion dagegen, weil wir sind sehr, sehr sicher, dass wir eine robuste Plattform auch tatsächlich haben. Genau. Und das ist auch eine große Mentalitätsfrage, die jetzt auch mit den Services nichts zu tun hat, aber wenn du halt viermal im Jahr dein Deployment machst oder 40 mal am Tag. Richtig. Wie viel Risiko hast du dann pro Deployment, wenn du immer eine große Gesamtmenge an Risiko hast? Bei den 40 Mal am Tag vielleicht immer relativ wenig und wenn du dann relativ schnell eben Rückmeldesysteme hast, die dir sagen, okay, da ist gerade was schief gelaufen, dann kann man das machen oder Feature Flags und dergleichen und du hast ja auch die Problematik mit, jetzt habe ich 17 Services, die orchestriert werden, die auch Breaking Changes mit sich bringen oder aber auch nochmal abwärtskompatibel sein müssen. Die haben Versionen, die müssen also nicht nur eine Authentifizierung machen, sondern die müssen auch von dem Service nebenan gefragt werden. In welchem Format möchtest du eigentlich mit mir sprechen? Also ist es das Alte, was vielleicht gerade noch online ist, weil Daten noch nicht komplett migriert sind auf neue Formate, die ein Service braucht? Ja. Oder ist es das Neue? Oder ist alles Lesen immer im alten Format und das wird ins Neue geschrieben? Oder du hast erstmal redundante Daten? Also hast du halt viele Abhängigkeiten, die dir zwar die Möglichkeit, eben darüber gesprochen, von Skalierung und Unabhängigkeit und dergleichen geben, aber du hast so viel mehr bewegliche Teile, auf die du aufpassen musst. Richtig. Und sobald du ein Teil anfasst, es änderst und neu einbringst, musst du halt Dependency Management machen und bei mehr als zwei Microservices, sollten das keine Anfänger machen.

Florian

01:04:02

Ganz genau, richtig. Also vielleicht zwei Aspekte zu dem, was du gerade erzählt hast. Einmal Stichwort hohe Release Zyklen, die kann ich mit Microservices erreichen, weil ich habe kleine Funktionalitäten, die kann ich regelmäßig ausliefern. In der Regel lassen sich die Services schnell starten. Ich habe schnell neuen Code in der Produktion, deswegen spielt es auch ganz super gut mit diesem Agilitätsgedanken mit rein. Das ist besser als jetzt bei einem Monolithen, wo ich vielleicht wie du gerade gesagt hast, viermal im Jahr ist natürlich schon ein sehr krasses Beispiel, aber der vielleicht extrem komplex zu deployen ist und wo es vielleicht auch am Wochenende dauert, bis ich dann deployed habe, wo ich auch noch Dinge migrieren muss, weil ich alles da natürlich migrieren muss, wenn ich Breaking Changes habe und diese Dinge. Genau, da können Microservices auch deutlich besser sein und die andere Geschichte mit welchen anderen Aspekt hattest du noch gerade?

Geek

01:04:52

Lass mich mal Pensionierung.

Florian

01:04:53

Abhängigkeiten, Betrieb, genau, da wollte ich drauf hinaus, richtig, du hast viel mehr bewegliche Teile, sagtest du, genau, die hast du auch und die müssen natürlich auch betrieben und administriert werden und wir haben damals, als ich noch an der Uni war, haben wir mal eine Studie gemacht und haben mal mit Unternehmen gesprochen und haben die auch mal explizit gefragt, wo wir wussten, dass die Microservices machen, wir sind in so eurer Erfahrung und witzigerweise kam da raus, das riesengroße Problem, was die alle hatten, war jetzt nicht so irgendwie die Microservices zu zerschneiden, oder Fachlichkeit zu zerschneiden, weil wenn du dich irgendwo vertan hattest, dann konntest du halt sagen, okay, müssen wir nochmal ein bisschen anders schneiden und nochmal umgestalten, das ist möglich. Sondern die hatten ein Riesenproblem mit dem Betrieb. Also da war es dann nicht so, wir haben jetzt den DevOps-Gedanken und dann haben wir hier irgendwie 100 Teams und in jedem Team ist ein Dev und ein Ops drin und dann ist das alles cool, sondern da gab es die Dev-Teams, so, die ihre Microservices gebaut haben und es gab ein zentralisiertes Ops-Team, weil die gesagt haben, ey, das, was wir hier machen, Kubernetes und all diese Dinge, das vernünftig, gescheit zu administrieren und zu betreiben, ist so kompliziert, zumindest für diese Unternehmen, weil die auch in dem Bereich die Kompetenzen einfach nicht hatten. Das können wir gar nicht auslagern. Vor allem, wie viele Ops willst du dann an der Stelle einstellen? Deswegen hat man dann gesagt, okay, wir haben ein zentralisiertes Ops-Team, die machen den ganzen Betrieb, alles, was irgendwie damit zu tun hat, diese beweglichen Teile, von denen du gerade gesprochen hast, und die Devs kümmern sich darum, Fachlichkeit in Microservices zu übersetzen. Das haben wir bei, ich glaube, allen Unternehmen, mit denen wir gesprochen haben, gesehen. Wir haben es alle genauso gemacht und für mich auch komplett nachvollziehbar, weil es eben wichtig ist in dem Bereich und nicht einfach ist und eine zusätzliche Komplexität, die ich mir auch reinhole. Das muss mir auch bewusst sein. Nein. Das kann man natürlich sagen, so, ja, Cloud-Provider, der nimmt mir alles ab. Aber es gibt ja auch Unternehmen, die machen ganz bewusst On-Prem. Dann machst du das natürlich selber und dann nimmt dir der Cloud-Provider an der Stelle mal gar nichts ab. So, also das ist auch eine Komplexität, die man sich mit reinholt. Das muss einem bewusst sein.

Geek

01:06:45

Wir haben jetzt sehr viel über individuell erstellter Software gesprochen. Jetzt lass uns mal ein bisschen, lass uns das Ganze mal auf Cloud-Native ziehen. Ja. Weil in Cloud-Native gibt ja einige Leute, die sagen, ich gehe jetzt in die Cloud und meinen damit eigentlich Eigentlich nur, dass der Server nicht mehr im Keller steht, sondern die benutzen jetzt den Server von Bill Gates und darauf läuft es jetzt. Aber was das eigentliche bedeutet bei Cloud Native, wäre ja zu sagen, du hast da Services, da ist ein S3-Bucket, wo du Daten abspeicherst oder du hast vielleicht, da gibt es verschiedenste Services. Ich habe mal so eine Emotion-Sensing-Funktionalität gesehen. Du konntest ein Bild hinschicken von jemandem und dann hat in den Azure-Services, gibt es dir zurück, ist der gerade fröhlich, glücklich oder traurig und wie viele Jahre ist der alt und ist männlich oder weiblich. Das ist halt ein Service, der einfach auch schon da ist. Und die Frage wäre ja jetzt zu sagen, wenn du jetzt Microservices baust, könntest du doch theoretisch einfach auch sagen, so ein bisschen was baue ich mir, wo ich der Meinung bin, das gibt es noch nicht, aber ich baue einfach die anderen Dinge ein, also von S3 Bucket angefangen bis hin zu Emotion Sensing usw. Also ich sage, die nehme ich mir einfach aus dem Fundus von AWS, GCP oder bei Azure und damit kann ich dann eben meine Entwicklung beschleunigen, weil ich einfach dieses fertige Microservice-Stückchen sozusagen zu sagen, schon einbaue in meine Wertschöpfungskette.

Florian

01:07:59

Absolut. Also das macht sowieso in dem Bereich Sinn, wenn ich eh Cloud-Native unterwegs bin, dann auch möglichst viel von dem Cloud-Provider meines Vertrauens zu nutzen, was es sowieso schon gibt. Absolut. Also das macht total Sinn. Könnte ich bei einem Monolithen natürlich auch. Also ich könnte ja auch da sagen, ich baue mir jetzt irgendwie eine Schnittstelle zu irgendeinem speziellen Dienst in meiner Cloud. Aber das macht tendenziell auf jeden Fall Sinn. Sollte man auf jeden Fall tun, wenn man denn sowieso Cloud-Native unterwegs sein will. Bei Microservices sagt man sehr oft, dass die auch schon implizit, so wie ich gerade sagte mit der horizontalen Skalierung, dass die implizit Cloud-Native sind. Das stimmt meiner Meinung nach bis zu einem gewissen Teil, weil du eben bei Microservices in der Regel virtualisierst. Also das heißt, du packst es sowieso in den Container rein, weil alles andere macht irgendwie wenig Sinn. Zumindest wenn du auch so dinge wie in kubernetes nutzen willst autoscaling all diese dinge dann virtualisiert er sowieso oder so du kannst die instanzen schnell hochziehen all diese dinge. Und deswegen sagt man sehr oft, dass Microservices an sich schon Cloud-Native sind, weil dann nimmst du halt deinen Docker-Container und schmeißt den irgendwie in den Cloud-Provider und alles ist gut. Ist natürlich dann ein Nachteil, wenn ich sage, ja, ich nutze jetzt einen S3-Bucket statt irgendeiner anderen Datenbank, die ich vorher mit Docker-Compose deployed habe, dann muss ich natürlich auch Schnittstellen zu diesem S3-Bucket irgendwie schaffen. Also das heißt, da ist die Welt jetzt auch nicht so rosig, wie man das gerne hätte, aber diesem Service-Gedanken folgend, nachdem wie Cloud-Provider-Modelle heutzutage aussehen, kann man da an der Stelle schon sagen, dass ein Microservice tendenziell näher an der Cloud ist als ein Monolith, aber ein Monolith kann ich genauso gut auch in der Cloud betreiben. Also es schließt es jetzt nicht aus. Vielleicht ist die Transformation ein bisschen schwieriger dahin. Aber vielleicht habe ich auch mehr Kosten am Ende, weil ich die gesamte Software da drin laufen lassen muss und nicht nur die Teile hochskaliere und bezahle oder in höherem Maße bezahle, die wirklich relevant sind und andere eher nicht, die nicht so oft genutzt werden. Aber grundsätzlich sind Microservices schon näher an der Cloud dran, aber ich kann auch andere Dinge in der Cloud laufen lassen.

Geek

01:09:56

Dann kommen wir zum Fazit. Das Fazit Du hast ja über das ganze Thema promoviert. Was war das Fazit deiner Promotion über Microservices? Was kam am Ende dabei raus?

Florian

01:10:08

Ich habe das ja mit einem Modellierungsaspekt noch, also modellgetriebene Softwareentwicklung kennt vielleicht der ein oder andere, der so um die Jahrtausendwende war. Das ist ein riesen Hype-Thema. In der Wissenschaft ist es heute an vielen Stellen immer noch ein großes Thema. Da kam im Endeffekt raus, dass Modellierung von Microservice-Architekturen eine sinnvolle Sache sein kann, weil ich eben Dinge abstrahiere. Die Architektur ist komplex, wenn ich sie in Modelle reingieße und sie erstmal auf einer höheren Abstraktionsebene als jetzt Quellcode darstelle und vielleicht auch Abstraktionsebene darüber. Das ist eine gute Idee. Du kannst relativ viel von dem Quellcode, das war auch so ein Punkt, ich habe mich auch mit Code-Generierung beschäftigt, relativ viel von dem Quellcode bis auf die Fachlichkeitsimplementierung auch sehr gut generieren, automatisiert erzeugen lassen, was damit zu tun hat, dass sowas wie ein Spring Boot zum Beispiel, ein Framework ist, das du super für Microservice-Entwicklung verwenden kannst. In anderen Bereichen wird es dann vielleicht eher schwieriger, wo du so eine Framework-Unterstützung an der Stelle nicht hast. Und Microservices haben auf jeden Fall ihre Daseinsberechtigung für viele Unternehmen da draußen, aber für einen Großteil der Unternehmen eben auch nicht. Und ich muss wirklich kritisch hinterfragen, brauche ich diesen Architekturansatz, brauche ich diesen Architekturstil, ja oder nein? Und da muss ich mich auch ehrlich machen. Also da kann ich jetzt nicht sagen, das ist jetzt ein Hype-Thema, das machen jetzt gerade alle. Netflix hat das auch gemacht, Deswegen muss ich das jetzt mit meinem 200-Mann-Mittelständler jetzt vielleicht auch machen, weil die haben das jetzt auch gemacht. Das ist der falsche Ansatz.

Geek

01:11:39

Was sind so die Top 2, 3 Dinge, wo du sagst, daran würde ich erkennen, also das sind große Indikatoren für, sollte man Microservices machen?

Florian

01:11:45

Wenn meine Software wirklich extrem schlecht skaliert, ich hohe Skalierung brauche, ich viele Anfragen, viele Benutzer habe und ich definitiv festmachen kann, dass der Architekturstil, dass mein Monolith daran schuld ist, dass ich nicht mehr skalieren kann, dann sollte ich in Richtung Microservices denken. Denken, wenn die Wartbarkeit meiner Software extrem schlecht ist, kann ich auch in Microservices denken, wobei dann würde ich auch eher erstmal in Richtung Modulit denken. Oder aber wenn ich eben sage, meine Kommunikationsstruktur, meine Organisation ist sowieso schon Microservice-ready sozusagen, was wir gerade mit dem Conway's Law hatten. Also wenn ich eh kleine Teams habe, klare Kommunikationsschnittstellen, all diese Dinge, könnte man auch in Richtung Microservice-Architekturen denken. Aber Skalierbarkeit ist in der Regel der größte Schmerz, der dazu führt, dass man Microservice-Architekturen einsetzen möchte. Aber da sollte ich vorher messen. Also da sollte ich vorher wirklich monitoren, gucken, woran liegt es jetzt, dass meine Software vielleicht nicht mehr so performance-effizient ist, wie ich es gerne hätte. Und selbst wenn ich dann die Entscheidung treffe, ich möchte von Monolithen in Richtung Microservices gehen, gibt es auch verschiedene Ansätze, wie man das tut. Ein sehr bekanntes Pattern in dem Bereich Strangler-Pattern, das heißt, du machst keine Big-Bang-Migration, das heißt, du löst nicht deinen Monolithen komplett von jetzt auf gleich in Microservices auf, sondern du machst es Stück für Stück, nimmst eine Funktionalität raus, kapselst sie in eine Microservice, baust eine Schnittstelle zwischen Monolith und Microservice. Betreibst das Ganze dann mal, schaust es dir an, wie gut kommt man damit klar, funktioniert es und nimmst dir dann die nächste Funktionalität vor, vor die nächste, die nächste, die nächste, bis du irgendwann dann alles mal deinen Monolithen sozusagen zersägt hast an der Stelle. Was man da auch bewusst machen muss, Thema haben wir auch nicht drüber gesprochen, aber Domain Driven Design ist ja auch immer sowas, was da auftaucht in dem, Bereich, also Dinge schneiden, vor allem fachspezifisch schneiden und was ein Trade-Off ist bei Microservice-Architekturen ist, du verzichtest an vielen Stellen auf Wiederverwendbarkeit. Das heißt, es kann durchaus passieren, dass du duplizierten Code hast oder duplizierte Klassen hast in verschiedenen Microservices, die vielleicht anders ausgestaltet sind Aber letztendlich dasselbe Konzept abbilden. Das nimmt man aber dann in Kauf, weil du sagst, dadurch wird meine Kopplung, die Abhängigkeit zwischen den Microservices eben geringer. Das muss einem auch klar sein. Also Microservices optimieren eigentlich nicht in Richtung Wiederverwendbarkeit. Das haben will, dann baue ich mir eine SOA, haben wir auch nicht drüber gesprochen, so Enterprise Service Bus, die zwar auch um die Jahrtausendwende rum populär ist. Wohl eher als heute. Aber ist auch ein Trade-Off, den ich da an der Stelle in Kauf nehmen muss. Also Fazit wirklich, Skalierung, Wartbarkeit und vielleicht habe ich schon irgendwie eine Organisationskultur, die eh dahin passt, dann kann ich mir da Gedanken drüber machen. Aber auch nur, wenn ich wirklich weiß, dass der Monolith nicht schuld daran ist. Oder schuld daran ist.

Geek

01:14:24

Das war ein Geek kommt selten allein. Vielen Dank fürs Zuhören und großen Dank an dich, Florian.

Florian

01:14:31

Vielen Dank, Stephan. Hat Spaß gemacht, hier zu sein.

Geek

01:14:33

Wenn unsere Hörer jetzt noch mehr von dir wissen wollen, wo finden sie dich im Netz?

Florian

01:14:36

Gerne auf LinkedIn. Auf LinkedIn anschreiben und dann kann man da gerne nochmal diskutieren. Und ein Hinweis vielleicht noch an der Stelle, wer sich jetzt für Microservices wirklich dediziert interessiert, es gibt so eine Initiative, wo ich auch beteiligt bin, das Microservices Community. Das ist so eine Non-Profit-Organisation, europaweit anfänglich stark wissenschaftsgetrieben, mittlerweile sehr guter Mix aus Fachlichen, also Menschen aus der Fachlichkeit, Menschen aus der Wissenschaft. Einmal im Jahr findet so eine International Microservice-Konferenz statt, auch aus Praktikern und Theoretikern, vielen Vorträgen und so. Gerne mal vorbeischauen im Internet, www.microservices.community. Und da findet man mich auch, kann mich auch gerne drüber anschreiben.

Geek

01:15:13

Wenn ihr noch Feedback zu dieser Folge habt, dann könnt ihr es gerne unter www.eingeekkommseltenallein.de eintippen. Macht es gut. Bis zur nächsten Folge. Wir hören uns.

Florian

01:15:23

Tschüss.

Feedback geben

Dir hat die Folge gefallen? Du hast Fragen? Du möchtest etwas klarstellen oder gar selbst über ein Thema sprechen? Lass dein Feedback hier - ich melde mich auf jeden Fall bei dir!

If you are a human, ignore this field

Mit einem Klick auf "Nachricht absenden" erklärst Du Dich damit einverstanden, dass wir Deine Daten zum Zwecke der Beantwortung Deiner Anfrage verarbeiten dürfen. Die Verarbeitung und der Versand Deiner Anfrage an uns erfolgt über den Server unseres Podcast-Hosters LetsCast.fm. Eine Weitergabe an Dritte findet nicht statt. Hier kannst Du die Datenschutzerklärung & Widerrufshinweise einsehen.

★★★★★

Gefällt Dir die Show?
Bewerte sie jetzt auf Apple Podcasts

2024 - Stephan Hochhaus

Hosted by LetsCast.fm
Deinen eigenen Podcast erstellen