Geek: Gemeinsam mit Florian Rademacher spreche ich über Microservices in der Software-Architektur.
Geek: Ihr hört Ein Geek kommt selten allein, den Podcast rund um Digitalisierung.
Geek: Hallo und herzlich willkommen zu Ein Geek kommt selten allein,
Geek: dem Podcast für mehr Konkretheit in der Digitalisierung.
Geek: Mein Name ist Stephan
Geek: und gemeinsam mit meinen Gästen mache ich eine Bestandsaufnahme,
Geek: wohin uns die letzten 40 Jahre Digitalisierung in Deutschland gebracht haben
Geek: und wie es von hier aus weitergehen kann.
Florian: In dieser Folge spricht der Geek mit Florian Rademacher.
Florian: Hallo Stephan, hallo an die Zuhörer da draußen. Ich habe zum 1.
Florian: November bei der Codecentric als Berater angefangen, war davor lange in der
Florian: Wissenschaft unterwegs und habe im
Florian: Bereich Microservice-Architektur und Architekturmodellierung promoviert.
Florian: Und hoffe, dass ich dadurch qualifiziert bin, ein bisschen was über dieses Thema zu sagen.
Florian: Insbesondere Microservices, die ja heute nach wie vor in aller Munde sind in
Florian: der Software-Architektur-Community und auch darüber hinaus.
Florian: Wo sich aber mittlerweile so ein bisschen Ernüchterung einstellt an diversen
Florian: Stellen, über die wir gleich auch gerne mal einmal diskutieren können.
Florian: Was so die Vor- und Nachteile dieses Architekturstils denn eigentlich sind.
Geek: Das Thema. Du hast es ja schon gesagt, alle Nase lang kommt mal irgendein Begriff
Geek: in die Software-Welt. Der ist der Heilsbringer, der ist das Lösungswort,
Geek: womit man alle Probleme der Digitalisierung loswerden kann.
Geek: 2011 war es, glaube ich, Marc Andresen hat gesagt, Software frisst die Welt.
Geek: Deswegen, wenn wir über Digitalisierung sprechen, müssen wir auch über Softwareentwicklung
Geek: sprechen, müssen wir über die Software
Geek: sprechen, die diese Welt und die Digitalisierung am Laufen halten soll.
Geek: Somit sind wir bei der Frage, wie kann man eigentlich gute Software machen?
Geek: Wie hat sich Software bauen und Softwarearchitektur in den letzten Jahren verändert?
Geek: Und da das Thema so massig groß ist und 40 Jahre Softwarearchitektur in 40 Minuten
Geek: würden bedeuten, dass jedem der Kopf schwirrt, reden wir heute mal eigentlich
Geek: nur über dieses Thema Microservices.
Geek: Wo kommen die Microservices her? Was machen wir damit?
Geek: Wie ist Software eigentlich besser geworden durch Microservices?
Geek: Oder warum wird es eben nicht besser durch Microservices? ist.
Geek: Vielleicht kannst du einmal kurz herleiten, aus welchem Hintergrund heraus quasi
Geek: Microservices erwachsen sind. Also was gab's vor Microservices?
Geek: Wie sah Software aus in den dunklen alten Tagen?
Florian: Also im Endeffekt kommt dieser Microservice-Gedanke, die sind auch so,
Florian: witzigerweise auch um 2011, 2012 rum wurde dieser Begriff geprägt.
Florian: So 2014, 15 kam das dann immer mehr in den Mainstream rein.
Florian: Vor allem auch, weil große Player, große Companies da draußen,
Florian: Netflix, Amazon, Spotify, das sind immer so die Platzhirsche, die man da nennt.
Florian: Die sehr viel Werbung für Microservices gemacht haben.
Florian: Dadurch wurde das Ganze eben extrem populär.
Florian: Und grundsätzlich ist der Gedanke bei Microservices, dass du sagst,
Florian: du hast ein komplexes Software-System und dieses Software-System skaliert entweder
Florian: nicht mehr vernünftig, zum Beispiel mit einer hohen Benutzerzahl,
Florian: oder aber ist extrem schwer zu warten, oder aber eben beides.
Florian: Und da sollten Microservices dann eben helfen, wo ich mir dann konkreter Gedanken
Florian: darüber mache, wie strukturiere ich eigentlich meine Software-Architektur und
Florian: eben nicht nur die Architektur, sondern vor allem auch meine Entwicklungsorganisationen,
Florian: meine Entwicklungsteams.
Florian: Das ist so ein bisschen, wo der Gedanke herkommt. Wir werden gleich wahrscheinlich
Florian: noch darüber sprechen, was ein Microservice konkret tatsächlich ist.
Florian: Vorher sah die Welt so aus, dass tatsächlich viele Menschen da draußen,
Florian: die sich mit Softwarearchitektur auskennen, eigentlich schon so ein Microservice-Gedanken
Florian: ein bisschen verfolgt hatten, geht vor allem um.
Florian: Starke oder hohe Kohäsion, lose Kopplung von Komponenten, können wir gleich
Florian: auch noch ein bisschen ins Detail ansteigen,
Florian: eigentlich alle schon irgendwie in dieselbe Richtung gedacht haben,
Florian: es fehlte aber irgendwie so ein gemeinsamer Oberbegriff und dann hat man sich
Florian: mal auf so einem Architektur-Workshop getroffen und da haben diese Leute dann
Florian: festgestellt, das waren dann so Leute wie Martin Fowler, James Lewis,
Florian: die dann da waren, die auch genau diesen Microservice-Begriff eben geprägt haben,
Florian: festgestellt, ach, wir machen ja eigentlich alle so ein bisschen schon irgendwie
Florian: in diese Richtung, dasselbe und jetzt müssen wir mal ein gemeinsames Oberthema
Florian: dazu finden und hat dann gesagt, okay, das nennen wir jetzt Microservice.
Florian: Ob der Begriff jetzt gut oder schlecht gewählt ist, darüber kann man sich auch streiten.
Florian: Der Schmerz, weswegen man Microservices oder man diesen Gedankengang dann an
Florian: der Stelle gegangen ist, ist so ein bisschen einmal aus so einer Monolithenwelt raus.
Florian: Große, komplexe Software-Systeme, die ein riesengroßer, schwerer Block sind,
Florian: sind schwerer zu skalieren.
Geek: Aber lass uns das ein Stückchen tiefer legen. Was macht Software überhaupt komplex?
Geek: Also Taschenrechner versus Facebook oder so.
Geek: Weil es gibt ja Software, die ist komplex und es gibt Software,
Geek: die ist vielleicht ein bisschen einfacher, geradliniger.
Geek: Aber was sind die Faktoren, die dafür sorgen, dass Software komplex wird?
Florian: Schwierig zu beantworten oder sagen wir mal nicht schwierig zu beantworten,
Florian: aber alle Faktoren in dem Moment zu identifizieren, die da reinspielen.
Florian: Also es ist sicherlich so, dass natürlich die Komplexität der Fachdomäne oder
Florian: die Größe der Fachdomäne oder auch der Fachlichkeit, die ich abbilden will,
Florian: eine Software komplexer macht.
Florian: Also sagen wir mal, so ein Netflix mit seiner Fachlichkeit, mit dem,
Florian: was es so tut, ist sicherlich deutlich komplizierter als vielleicht ein Taschenrechnerprogramm,
Florian: das jetzt jemand in der Ausbildung oder einem Bachelorstudent oder sowas da
Florian: irgendwie mal implementiert.
Florian: Das ist einmal der Umfang, der Funktionsumfang, die Fachlichkeit,
Florian: die Komplexität der Fachlichkeit selber, aber eben auch solche Dinge wie meine
Florian: Entwicklungsorganisation.
Florian: Wie bin ich eigentlich als Unternehmen
Florian: strukturiert? Wie gut sind meine Kommunikationsflüsse im Unternehmen?
Florian: Wie effizient kann ich überhaupt arbeiten? Bin ich vielleicht stärker von Politik getrieben?
Florian: Also eher vielleicht Dinge, die jetzt aus einer Entwickler- oder Architektenbrille
Florian: eher irrational sind oder irrational erscheinen mögen.
Florian: Also das sind alles so Dinge, die Softwareentwicklung an sich komplex machen
Florian: können und Software kann natürlich auch dadurch komplex werden,
Florian: dass Technologien zum Beispiel extrem schwierig oder schwieriger sind als andere Technologien.
Florian: Weiß ich nicht, eine Container-Orchestration-Plattform vernünftig aufzusetzen
Florian: ist vielleicht auch schwieriger als einen Maven vernünftig zu betreiben bei
Florian: mir lokal. Also das sind auch Dinge, die da reinspielen.
Florian: Aber die Komplexität ergibt sich zumindest im Bereich Microservices eher daraus,
Florian: dass ich sage, ich habe große komplexe Domänen und ich muss meine Software vernünftig
Florian: aufteilen, sodass sie skalierbar ist auf der einen Seite und auch wartbar bleibt
Florian: oder wartbarer wird auf der anderen Seite.
Geek: Ich bin ja jetzt so alt, dass früher meine Software immer auf Disketten kam
Geek: und dann irgendwann auf CDs und erst ganz viel später gab es das irgendwie über das Internet.
Geek: Und alle Software, die über CDs kommt und die ich mir installiert habe,
Geek: also alles, was Fat Client ist, also mein Word vor der 365-Ära,
Geek: wo es im Internet war und dergleichen, all diese Dinge, stelle ich mir vor,
Geek: sind eigentlich klassische Monolithen.
Geek: Also das ist halt ein fettes Ding, das ich installiere und alles,
Geek: was im Netz ist, das kann entweder fett sein oder oder Microservices haben oder
Geek: bin ich da auf der falschen Fährte?
Geek: Also ist quasi alles, was ich als Fettclient auf meinem Rechner habe,
Geek: Tendenziell eher mal kein Microservice.
Florian: Also beim Monolithen oder diese Unterscheidung Microservices-Monolithen ist
Florian: so, dass du sagst, wenn ich Software habe, deren Komponenten nicht alleine lauffähig
Florian: sind und die auch nicht verteilt sind,
Florian: also die ich jetzt nicht auf mehrere Rechenknoten zum Beispiel verteilen kann,
Florian: dann betrachtet man diese Software als monolithisch.
Florian: Manche sagen auch, dass dann zum Beispiel die Prozesse, die von dieser Software
Florian: gestartet oder ausgeführt werden, dass die im selben Adressraum laufen.
Florian: Das ist aber schon sehr technisch. Du sagst eigentlich, wenn ich eine Software
Florian: habe, Komponenten sind nicht verteilt und sind nicht unabhängig voneinander ausführbar.
Florian: Ich brauche immer eine Ausführungsumgebung, wo das Ganze drin läuft,
Florian: dann ist es ein Monolith.
Florian: Und Microservices ist ein zusammenhängendes Software-System,
Florian: das logisch zusammenhängt, dessen Komponenten ich aber unabhängig voneinander
Florian: ausführen kann, die ich verteilen kann auf verschiedenen Rechenknoten.
Florian: Das würde man dann eher als Microservice-Architektur bezeichnen.
Geek: Mal so eine richtig dumme Frage. Als ich dann weitergegangen bin,
Geek: nach den CDs und so weiter, und die erste Webseite kam, da kam der LAMP-Stack.
Geek: Das heißt, es gibt das Linux-Ding, da gibt es eine Apache, eine MySQL-Datenbank,
Geek: ein bisschen PHP, und da drinnen gibt es ein WordPress oder dergleichen.
Geek: Ist alles von denen dann auch ein Microservice? Also ist dann meine Datenbank
Geek: sozusagen ein Microservice, mein Apache ist ein Microservice?
Florian: Es gibt Menschen, die würden jetzt darauf antworten, ja. Ich sehe das ein bisschen anders.
Florian: Ich sehe das so, ein Microservice ist eigentlich in der Mehrzahl etwas,
Florian: das eine fachliche Funktionalität abdeckt. Fachlich im Sinne von,
Florian: wir befinden uns in irgendeiner Fachdomäne.
Florian: Und in dieser Fachdomäne erfüllt dieser Microservice eine bestimmte dedizierte Aufgabe.
Florian: Nehmen wir sowas wie, ein Beispiel ist immer irgendwie Benutzerverwaltung.
Florian: Nun kann so eine Benutzerverwaltung natürlich auch unfassbar komplex sein.
Florian: Aber wenn wir jetzt mal irgendwie so uns sagen, du hast jetzt eine Komponente,
Florian: die ist dafür verantwortlich, einen Benutzer anzulegen, Benutzer zu ändern, Benutzer zu löschen.
Florian: Dann kannst du diese Funktionalität in einen Microservice packen und das funktioniert auch wunderbar.
Florian: Und du hast dann vielleicht aber auf der anderen Seite, wenn wir mal jetzt bei
Florian: dem Netflix-Beispiel nochmal bleiben, hast du dann vielleicht einen Microservice,
Florian: der ist für das Streaming verantwortlich.
Florian: Das heißt, du hast dann zwei Microservices schon mal. Der eine ist für die Nutzerverwaltung,
Florian: der andere ist für Streaming verantwortlich.
Florian: Beides sinnvolle Funktionen innerhalb dieser Fachdomäne Video-Streaming.
Florian: Und das würde man dann eher als Microservice bezeichnen. Dass wir im Hintergrund
Florian: noch Datenbanken und solche, sagen wir mal, eher technischen Komponenten haben,
Florian: das ist klar, das gehört dazu.
Florian: Die werden aber in der Regel nicht als Microservices betrachtet.
Florian: Kleine Anekdote vielleicht am Rand, weil ich gerade sagte, Es gibt Leute,
Florian: die sagen, das sind Microservices.
Florian: Ich habe mal mit jemandem gesprochen, der hat gesagt, wenn ich es in einen Docker-Container
Florian: packe und im Docker-Container starten kann, ist es ein Microservice.
Florian: Das betrachte ich anders, sehen auch einige andere Leute anders,
Florian: hat den Hintergrund, dass Container und Microservices, können wir vielleicht
Florian: auch nochmal ein bisschen tiefer darüber sprechen, sich gegenseitig befruchtet haben.
Florian: Also ohne Container ist so eine Microservice-Architektur eigentlich nur sehr
Florian: schwer denkbar, weil Container dir Virtualisierung mitbringen,
Florian: weil sie dir Skalierbarkeit mitbringen, hast du ein Kubernetes oder irgendwie
Florian: sowas, Autoscaling, all diese Dinge wird durch Container extrem vereinfacht
Florian: und dadurch wird die Microservice-Entwicklung auch extrem vereinfacht,
Florian: weil du besser oder einfacher oder automatisierter skalieren kannst. Genau.
Geek: Versuchen wir mal das jetzt so ein bisschen zu, also ich merke,
Geek: du hast eine Definition, es gibt verschiedene Definitionen, wie können wir für
Geek: uns jetzt definieren, das ist ein Microservice. Wenn ich meiner Mama versuche
Geek: zu erklären, dies ist ein Microservice, was ist das?
Florian: Ein Microservice ist eine Softwarekomponente, die entweder eine abgegrenzte
Florian: fachliche Funktionalität oder eine Infrastrukturfunktionalität abbildet.
Florian: Fachlich, was ich gerade sagte, eine Benutzerverwaltung oder Videostreaming.
Florian: Die aber auf der anderen Seite unabhängig von anderen Komponenten ausführbar ist.
Florian: Bedeutet, ich kann einen Microservice starten selber auf meinem Rechner und
Florian: auf einem anderen Rechner kann ich einen anderen Microservice starten.
Florian: Und das ist auch ein wichtiger Punkt und deswegen bringen Microservices auch
Florian: viel in Richtung Organisation mit und Organisationsumstrukturierung.
Florian: Ein Microservice wird in der Regel immer von genau einem Team betreut.
Florian: Das heißt, ein Team von Entwicklern, vielleicht auch von Operators,
Florian: da gibt es auch verschiedene Ansätze zu Team-Topologies und diese Dinge,
Florian: ist immer für ein Microservice verantwortlich.
Florian: Kann natürlich für mehrere Microservices verantwortlich sein,
Florian: aber ein Microservice wird immer von genau einem Team betreut.
Florian: Das ist so eine der klassischen Definitionen. Also abgegrenzte Funktionalität
Florian: und du hast dieses eine Team, was dafür verantwortlich ist,
Florian: kann Microservices unabhängig von anderen starten und Microservices sind für
Florian: alles verantwortlich oder für alles selbst verantwortlich, was so Dinge betrifft
Florian: wie, wie baue ich jetzt eine Interaktion mit einem anderen Microservice auf
Florian: oder mit einem anderen System auf.
Florian: Das heißt, du hast nicht mehr so diese Dinge mit, wir sind in einem Monolithen,
Florian: die Dinger, also Microservices die Komponenten in einem Monolithen kommunizieren
Florian: irgendwie miteinander über.
Florian: Interprozesskommunikation, irgendwie im Rahmen des Rechners oder sowas,
Florian: sondern bei Microservices habe ich in der Reihe Netzwerkkalls und diese Netzwerkkalls
Florian: müssen meine Microservices auch selbstständig abbilden.
Florian: Das heißt, ich habe sehr viel Verantwortung in den Services selber drin liegen
Florian: und dadurch eine sehr starke Provision der Services, aber auch eine sehr lose Kopplung. Das ist so.
Florian: Die Definition und die Vorteile des Ganzen, genau.
Geek: Ich habe immer so ein Bild im Kopf, wenn ich über Microservices nachdenke.
Geek: Ich weiß nicht, ob du Rick and Morty kennst.
Florian: Ja.
Geek: Es gibt da eine Folge, da sitzen sie alle beim Frühstückstisch und da gibt es
Geek: diesen kleinen Roboter. Und er fragt immer, what's my purpose? You pass butter.
Florian: Ja.
Geek: Ist das quasi akkurat? Also für diejenigen, die es nicht kennen,
Geek: ihr solltet Rick and Morty gucken.
Geek: Aber das ist halt dieser eine Roboter, dieser hochentwickelte Roboter,
Geek: dessen einziger Purpose ist es eben, die Butter weiterzugeben.
Geek: Ist das sozusagen die Idee des Microservices.
Geek: Es macht ja eine Business-Funktion, es hat einen Value, oder?
Florian: Richtig, genau.
Geek: Und ansonsten macht er nichts.
Florian: Genau, also er macht diese eine Funktionalität, die er eben umsetzt.
Florian: Auch darüber kann man sprechen, wie groß ist diese Funktionalität, welchen Umfang hat sie?
Florian: Darüber kann man alles diskutieren, aber ein Microservice setzt genau eine Funktionalität
Florian: im Rahmen in der Regel eine Business-Funktionalität und in den meisten Fällen
Florian: eine Business-Funktionalität optimal um.
Florian: Was man sehr oft da findet, ist eben dieser Zusammenhang zu diesem Unix-Gedanken,
Florian: Also da draußen die Leute, die irgendwie Linux benutzen und auch Mac-User sind
Florian: damit wahrscheinlich stark vertraut und Menschen, die heute Windows mit dem
Florian: WSL benutzen, wahrscheinlich auch.
Florian: Also ich habe verschiedene Dienstprogramme und jedes Jahr Dienstprogramme macht
Florian: eine Sache dafür aber richtig gut und ich kann diese Dienstprogramme hintereinander schalten.
Florian: Und das ist eigentlich eine Analogie, die bei Microservices eigentlich auch genauso zutrifft.
Geek: Okay, das heißt, im Grunde genommen gibt es das schon lange.
Geek: Also diese CD-Sache, die ich eben gesagt habe mit Monolithen auf meinem Rechner,
Geek: stimmt nicht so ganz, sondern es stimmt so in Teilen.
Geek: Es gibt schon modulare Ansätze und eigentlich nimmt man verschiedene kleine
Geek: Teile, die machen alle ein Stückchen der Wertschöpfungskette und die kombiniert
Geek: man einfach clever und einer der Gründe, über den wir jetzt ja schon gesprochen
Geek: haben, ist sehr stark das Organisatorische, also wie kann ich es schaffen?
Geek: Ich stelle mir immer die Frage, ich habe letztens gelesen, Spotify lässt wieder
Geek: 900 Engineers gehen, die haben irgendwie 1600 Engineers.
Geek: Und jetzt ohne Scheiß, Spotify lässt mich Musik hören und sagt mir,
Geek: diese Musik solltest du auch hören.
Geek: Und ich frage mich, wie man jahrelang daran arbeiten kann und 1.600 Engineers
Geek: bei Laune hält, dass sie auch was tun können.
Geek: Aber tatsächlich unabhängig davon, wo jetzt die Arbeit herkommt,
Geek: dass sie arbeiten können, bedeutet ja, dass sie sich möglichst irgendwie aufteilen können.
Geek: Seien es irgendwelche Themen wie ein Team muss sich eine Pizza teilen können
Geek: und so weiter. Du kannst ja nicht 1.600 Leute an demselben Ding arbeiten lassen.
Geek: Wer kann denn so einen Planungsaufwand leisten? Das kann ja keiner.
Geek: Also musst du es ja irgendwie schneiden. Und Microservices helfen uns zu schneiden.
Geek: Und die Frage ist aber jetzt, wo schneidet man denn eigentlich?
Geek: Also woher weiß ich, wie klein ich das machen muss und gibt es da Best Practices, gibt es da Ideen?
Geek: Also was sind so die Heuristiken, nach denen man vorgeht, um zu sagen,
Geek: okay, das ist jetzt eine Funktion, die lohnt es sich in einem Microservice zu
Geek: machen und darf man vielleicht auch mal zwei in einem Microservice haben?
Florian: Es keine allumfassende Antwort gibt, meiner Meinung nach.
Florian: Also zunächst mal, was du gerade sagtest mit dem Schneiden und Software vernünftig
Florian: aufteilen und auch, dass dein Office, das du vielleicht irgendwie von der CD
Florian: auf deinem Rechner installiert hast und sowas, dass das sauber strukturiert ist. Das stimmt alles.
Florian: Also diese Dinge mit hoher Kohäsion,
Florian: lose Kopplung, vernünftige Schnittstellen. Kannst du nochmal kurz.
Geek: Du hast es schon zum zweiten Mal gesagt, lose Kohäsion und die Kopplung.
Florian: Hohe Kohäsion, lose Kopplung.
Geek: Ja, sorry.
Florian: Genau, ist eigentlich so ein Ding, das ist so seit seit den 70er Jahren schon,
Florian: glaube ich, zum Prinzip erhoben worden, was eben grundlegende Qualitätsattribute
Florian: von einem Software-Modul eben sind.
Florian: Hohe Kohäsion bedeutet, dass ich in meinem Modul oder meiner Funktion.
Florian: Meiner Klasse, meiner Methode, also in jedem Stück oder jedem Ansatz,
Florian: mit dem ich irgendwie meinen Quellcode strukturieren kann, im Endeffekt zusehe,
Florian: dass die Dinge zusammengehörig, zusammengefasst sind, die sich auch im gleichen Maße ändern. mindern.
Florian: Bedeutet sowas wie, wenn ich jetzt ein Modul Benutzerverwaltung habe,
Florian: habe ich da alle Funktionen irgendwie drin, die was mit Benutzerverwaltung zu
Florian: tun haben, weil ich weiß, wenn irgendwas an der Benutzerverwaltung kaputt ist
Florian: oder ich muss irgendwas hinzubasteln oder sowas, muss es irgendwie erweitern,
Florian: dann weiß ich, ist dieses Modul davon betroffen und im besten Fall ist auch
Florian: nur dieses eine Modul davon betroffen.
Florian: Und lose Kopplung bedeutet im Endeffekt, dass ich sage, dass ich die Abhängigkeiten
Florian: zwischen meinen Modulen oder meinen Methoden, meinen Klassen,
Florian: was auch immer, möglichst minimiere, möglichst minimal halte.
Florian: Bedeutet, wenn jetzt irgendwie jemand mit der Benutzerverwaltung interagieren
Florian: muss, dann bietet das Modul der Benutzerverwaltung hoffentlich eine vernünftige
Florian: Schnittstelle an, über die das getan werden kann und auch nur über diese Schnittstelle oder API,
Florian: also nur darüber, über diesen Abstraktionsmechanismus, kann ich mit den Funktionen
Florian: in meinem Benutzerverwaltungsmodul sprechen.
Florian: Alle anderen Konzepte, Funktionen, Klassen, die irgendwas mit Benutzerverwaltung
Florian: zu tun haben, sind in diesem Modul gekapselt und nur über diese Schnittstelle
Florian: nach außen erreichbar und auch nur diejenigen, die ich freigebe.
Florian: Das ist das, was man eigentlich möchte. Also Dinge, die sich in gleichem Maße
Florian: ändern, zusammenfassen, kapseln und dann über vernünftige Schnittstellen nach
Florian: außen geben und die sind auch nur über diese Schnittstellen erreichbar.
Florian: Dann kann ich nämlich kontrollieren, welche Konzepte werden wo in meiner Software benutzt.
Florian: Ich habe eine bessere Testbarkeit, all diese Dinge.
Florian: Und hohe Kohäsion, genau, ist auf der einen Seite eben die Zusammenfassung von
Florian: Dingen, die sich in gleichem Maße ändern.
Florian: Lose Kopplung ist eben möglichst Abhängigkeiten zu minimieren und das sind Prinzipien,
Florian: die kennt man in der Softwareentwicklung, Softwareengineering seit den 70er
Florian: Jahren. Es ist ein alter Hut sozusagen.
Geek: Das wäre auch genau meine Frage. Wenn wir jetzt,
Geek: Objekte, Klassen, Libraries, Module haben. Wo unterscheidet sich das auf der
Geek: anderen Seite von Microservices?
Geek: Der einzige Unterschied, den ich so für mich heute sehe, ist,
Geek: die machen eine Netzwerkkommunikation. Bei den anderen gehen die über Sockets oder sonst was.
Geek: Man weiß nicht, wie die genau kommunizieren, aber werden die schon schaffen.
Geek: Aber im Grunde scheint mir das architekturell ähnlich zu sein.
Geek: Nur, dass du diesen verteilten Aspekt hast. Also Microservices dürfen nochmal
Geek: eine Netzwerkverbindung oder sonst wie Restfull sind die ja meistens,
Geek: dass du irgendwie über Restschnittstellen gehst.
Geek: Und bei dem anderen, da gelten ja dieselben Prinzipien dann,
Geek: dass man sagt, teile deine Software mal sinnvoll auf,
Geek: weil in der Informatik lernen wir, Probleme klein zu machen,
Geek: dann gibt es eine Separation of Concerns und jedes Problem wird in seinem Kontext
Geek: bearbeitet, dann ein bisschen Don't Repeat Yourself,
Geek: dass man den Code nicht immer Copy-Paste in alles reinmacht,
Geek: also irgendwie schlau schneiden, dass man nicht zu viele Abhängigkeiten hat,
Geek: aber doch schon klare Zuständigkeiten in der Software.
Geek: Und da scheint mir Netzwerkverbindung quasi das konstituierende Element für
Geek: Microservices zu sein oder ist das zu kurz gegriffen?
Florian: Ja, es ist ein bisschen zu kurz gegriffen tatsächlich, weil du bei den anderen
Florian: Prinzipien, die ich genannt habe, gerade bei so bei Monolithen und so,
Florian: da kann es ja halt passieren,
Florian: du hast das Ganze in der Regel in einer Codebase und jetzt hast du jemanden
Florian: da, der kennt die Architektur nicht.
Florian: Softwarearchitektur ist ja nur noch was, das durch Code quasi abgebildet wird,
Florian: aber die ich jetzt nicht auf einen Blick sofort erfassen kann.
Florian: Gerade wenn es ein riesengroßes, komplexes System ist, sehe ich nicht,
Florian: wie die intendierte Architektur ist.
Florian: Außer ich habe eine saube, vernünftige Dokumentation. Vielleicht habe ich auch
Florian: im Architekturtest, die es ja mittlerweile auch Ansätze für gibt,
Florian: die im Endeffekt die Struktur überprüfen und die auch sicherstellen,
Florian: dass ich diese Struktur nicht brechen kann.
Florian: Wenn ich jetzt aber eine große Codebase habe, dann, wer verbietet es mir denn,
Florian: wenn ich jetzt all diese Mechanismen nicht in place habe?
Florian: Habe, zum Beispiel jetzt in der Benutzerverwaltung eine Klasse zu verwenden,
Florian: die vielleicht public ist, die aber gar nicht intendiert dafür ist,
Florian: dass ich sie in irgendeinem anderen Modul meiner Software verwende.
Florian: Also weiß ich nicht, sowas wie Rechnungserstellung. Das Rechnungserstellungsmodul
Florian: benutzt jetzt auf einmal irgendein Konzept aus der Benutzerverwaltung,
Florian: auf das es überhaupt gar keinen Zugriff haben sollte, weil es keinen Sinn macht.
Florian: Und bei Microservices ist es ja so, jeder Microservice ist eigentlich eine eigenständige
Florian: Applikation. Die Codebases sind in der Regel getrennt.
Florian: Wenn es nicht der Fall ist, so zwingt dich doch zumindest eine Microservice-Architektur
Florian: genau in dieser Richtung zu denken, nämlich in eigenständigen Applikationen.
Florian: Und dann kann ich nicht sagen, ich greife jetzt aus der einen Applikation auf
Florian: eine Klasse in der anderen Applikation zu, weil es eben getrennte Applikationen sind.
Florian: Das heißt, dieser Trennungsgedanke und dieser lose Kopplungsgedanke übersteigt
Florian: eigentlich das, was du bei einem Monolithen hast.
Florian: Was damit zu tun hat, was du gesagt hast, Netzwerk-Calls auf jeden Fall,
Florian: weil wenn ich Netzwerk-Calls machen will, dann habe ich in der Regel zwei Applikationen,
Florian: die getrennt sind, die auf verschiedenen Maschinen laufen können,
Florian: die miteinander reden müssen.
Florian: Bei Monolithen ist es halt alles irgendwie im Rahmen Interprozess-Kommunikation.
Florian: Da sehe ich das ja gar nicht. Da bin ich gar nicht dazu gezwungen zu denken
Florian: in Applikationen, die verteilt sind.
Florian: Also wirklich in einem echten, richtigen, verteilten System,
Florian: wo meine Komponenten auch verteilt sind. Ja, also das ist der,
Florian: dadurch, wenn du die Vorteile an Microservice-Architektur wirklich heben willst,
Florian: musst du in verschiedenen Applikationen denken, die über Netzwerk-Calls miteinander
Florian: sprechen, das ist richtig.
Florian: Das zwingt dich dann eben dazu, auch eine vernünftige Modularisierung zu machen
Florian: und nicht mehr irgendwie, oder du kommst nicht mehr so schnell in die Verlegenheit
Florian: zu sagen, ich nutze jetzt Bestandteile an Quellcode, die in einem anderen Modul
Florian: liegen oder einem anderen Microservice liegen, weil es technisch gar nicht mehr möglich ist.
Florian: Nichtsdestotrotz, die andere Frage, was du sagtest, und das ergibt sich im Endeffekt
Florian: daraus, wie schneide ich meine Software denn vernünftig in Microservices?
Florian: Und da gibt es keine Best Practices. Also es gibt jetzt nichts,
Florian: wo du sagen kannst, ich habe jetzt folgende Software und ich mache jetzt diese
Florian: fünf Schritte und dann bin ich in einer Microservice-Architektur.
Florian: Sondern es gilt eben das Prinzip, schneide deine Software so,
Florian: dass du in jedem Microservice, dass er eine Funktionalität abbildet.
Florian: Jetzt ist die Frage, was ist eine Funktionalität? Ist das sowas wie Benutzer
Florian: erstellen, ändern, löschen?
Florian: Das ist meine Funktionalität, die hängt an dem Benutzerkonzept.
Florian: Oder aber sage ich, ich mache aus jeder von dieser Funktion einen eigenen Microservice,
Florian: hat man auch schon gesehen, tendenziell wahrscheinlich eher nicht.
Florian: Es gibt aber da in dem Moment keine, dass du sagst, ich habe mal mit jemandem
Florian: gesprochen, der meinte irgendwie, Microservice sollte nicht mehr als 100 Lines of Code haben.
Florian: Das ist vollkommen, also in meinen Augen vollkommen falscher Rat.
Florian: Rad, genau, weil dann habe ich irgendwie weiß ich nicht, eine Applikation,
Florian: die hat 20.000 Lines of Code, ja und dann habe ich da eben meine 200 Microservices,
Florian: damit jeder von denen irgendwie nur 100 Lines of Code hat.
Florian: Das wird schwierig, vor allem wie du schon sagst, Netzwerk-Calls,
Florian: Netzwerk-Calls sind teuer, dauern lange oder länger als jetzt irgendwie eine
Florian: Interprozess-Kommunikation und wenn dann meine Software am Ende einfach deutlich
Florian: langsamer ist als vorher,
Florian: warum sollte sie dann jemand benutzen wollen? Also welche Vorteile habe ich
Florian: mir dadurch erkauft? Keine.
Florian: Zumal die Strukturierung an der Stelle wahrscheinlich auch nicht sinnvoll gewählt
Florian: ist. Jetzt kann man sagen, okay, ich meinte ja gerade sowas wie Wartbarkeit,
Florian: Skalierbarkeit spielt auf jeden Fall mit einer Rolle rein.
Florian: Das sind wichtige Dinge, die ich berücksichtigen muss, nur ich habe am Ende
Florian: immer den Trade-off oder ich muss immer gucken, dass ich dahingehend optimiere,
Florian: dass ich sage, ja, ich habe jetzt diese Skalierbarkeit und Wartbarkeit erreicht,
Florian: aber ich habe immer noch relativ wenige oder nur so viele Microservices,
Florian: wie ich tatsächlich brauche, um eben diese Vorteile zu heben und sie nicht dadurch zu reduzieren.
Florian: Zunichtet zu machen, dass ich sage, ich habe jetzt sehr, sehr viele Netzwerk-Calls
Florian: und das ganze Ding ist langsamer als vorher.
Florian: Also das ist schon, das ist ein Trade-Off, den hast du immer und in meiner Meinung
Florian: nach findest du das auch nur raus, indem du, wenn du jetzt einen Monolithen
Florian: hast, den du umsetzen willst oder meinetwegen baust du auch was Neues from scratch,
Florian: indem du die ganze Zeit immer im Blick hast, das kann mir passieren und auch
Florian: regelmäßig misst, wie gut sind wir jetzt eigentlich im Moment und vielleicht
Florian: muss ich Funktionalitäten auch wieder zusammenlegen. Kann dir auch passieren.
Florian: Aus pragmatischen Gründen, du sagst, konzeptionell sind diese Funktionalitäten
Florian: sauber voneinander getrennt, aber die werden diese beiden Microservices,
Florian: wo diese Funktionalitäten drin liegen, tauschen sich so oft aus,
Florian: dass es eigentlich Sinn macht, die wieder zusammenzulegen, weil sonst ist es unfassbar langsam.
Florian: Also das ist immer so Trade-off-Theorie-Pragmatik.
Geek: So wie bei Datenbanken, wenn du sagst, normalisiere ich alle meine Daten,
Geek: mache ich es nach Lehrbuch oder mache ich es nach reeller Welt,
Geek: wo ich es verwenden möchte, da ist es vielleicht sinnvoll, dann bestimmte Daten
Geek: doch redundant zu halten oder sonst wie anarbeitig zu machen.
Geek: Wo du es jetzt auch gesagt hast, es sind ja verschiedene Applikationen,
Geek: die Microservices und wir hatten über den Overhead auch schon gesprochen und
Geek: eigentlich ist es ja tatsächlich so, dass die jetzt viel mehr Aufwand sind,
Geek: weil jede einzelne Komponente muss ja auch Authentifizierung mitbringen,
Geek: muss ja vieles mitbringen, muss ja auch über Konsistenzen nachdenken.
Geek: Also wenn zwei Instanzen gleichzeitig sind, über Skalierung reden wir gleich
Geek: noch, wenn es mehr Microservices gibt, die für dasselbe zuständig sind,
Geek: weil wir das ja auch noch machen können.
Geek: Also musst du quasi so ein Multithreadedness über Netzwerke hinkriegen.
Geek: Aber bleiben wir erstmal bei den eigentlichen Herausforderungen der Microservices.
Geek: Ist es, ich habe eine Netzwerkkommunikation und ich möchte jetzt irgendwie sicherstellen,
Geek: dass nur authentifizierte Player mitmachen dürfen.
Geek: Ist das nicht allein schon eine ganze Menge Overhead für Pass the Butter als einzelne Funktion?
Florian: Ja, ist es. Deswegen kann man auch nicht jedes System da draußen,
Florian: und das macht nicht Sinn, jedes System da draußen nach Microservices zu migrieren,
Florian: nur weil jetzt irgendwie große Player das gesagt haben.
Florian: Es gibt so ein famous quote, ich weiß jetzt gerade den Namen leider nicht von
Florian: der Person, die das gesagt hat, dass es schön und gut ist, dass dass Microservice-Architekturen
Florian: ja von Netflix, Amazon, Spotify und sowas propagiert werden.
Florian: Aber du bist nicht Netflix, Amazon, Spotify in 99 Prozent der Fälle.
Geek: Und dagegen kann man halten, Shopify, vermutlich das größte Projekt auf Ruby
Geek: on Rails, war zu meinem letzten Kenntnisstand ein kompletter Monolith,
Geek: bewusst gewählter modularer Monolith.
Florian: Vollkommen in Ordnung. Also das ist etwas, bevor ich jetzt die Entscheidung
Florian: treffe, meinen Monolithen irgendwie zu zersägen und nach Microservices zu migrieren,
Florian: etwas, das ich in der Regel vorher tun sollte.
Florian: Ich sollte wirklich gucken, ist der Schmerz, den ich empfinde,
Florian: groß genug, dass es das rechtfertigt? Also habe ich Skalierungsprobleme?
Florian: Habe ich eine riesengroße Nutzerzahl, die sowas rechtfertigt?
Florian: Habe ich extreme Wartbarkeitsprobleme?
Florian: Denn bevor ich jetzt irgendwie sage, ich habe einen gut funktionierenden Monolithen,
Florian: na klar hat der irgendwie seine Kinderkrankheiten, vielleicht sind Dinge nicht
Florian: so geschnitten, wie es sein sollte.
Florian: Man hat an einigen Stellen vielleicht auch irgendwie über die Jahre,
Florian: wenn es historisch gewachsen ist, mal nicht auf die Architektur geachtet.
Florian: Alles fein, kann passieren.
Florian: Aber dann sollte ich erstmal überlegen, kann ich diese Probleme mit einem Refactoring
Florian: des bestehenden Codes unter Beibehaltung der Architektur aus der Welt räumen?
Florian: Oder muss ich wirklich eine Migration Richtung Microservices machen?
Florian: Brauche ich das überhaupt? Und wie gesagt, in der Regel ist die Antwort darauf, nein.
Florian: Muss man ganz klipp und klar sagen. Und das ist, meine ich auch mit Ernüchterung
Florian: vorhin, das ist etwas, was viele mittlerweile erkennen.
Florian: Ich habe jetzt die Tage auch irgendwo einen Artikel gelesen auf einem,
Florian: sage ich mal, einschlägigeren Portal, so im IT-Bereich, wo eben drin stand,
Florian: ja, viele Mittelständler erkennen mittlerweile, ey, das mit der Microservice-Migration
Florian: war keine gute Idee, wir gehen wieder zurück. zurück.
Geek: Die Frage ist, was man sich davon verspricht. Da kommt dann mein Produktlerherz
Geek: mit raus und bei der Architektur ist es ja auch so.
Geek: Ich kann halt nicht auf alles optimieren. Ich habe halt bestimmte Dinge,
Geek: auf die kann ich optimieren und da gilt es natürlich zu sagen,
Geek: was sind eigentlich meine Architekturprämissen?
Geek: Was möchte ich tun? Möchte ich Skalierbarkeit? Möchte ich Geschwindigkeit? Möchte ich Sicherheit?
Geek: Bei einer Bank ist es sicherlich eher nicht so das Thema, es muss möglichst
Geek: schnell sein, sondern wäre ganz gut, wenn das Geld, was auch verschickt wird, jemals ankommt.
Geek: Somit ist bei denen die oberste Prämisse nicht, es muss ganz schnell gehen,
Geek: sondern es muss da sein. Also jemand, der sein Erspartes verliert, wird dauer.
Geek: Bei jemand anders, der vielleicht ein Gewinnspiel online anbietet,
Geek: ist es vielleicht nicht so wichtig, dass jede Anfrage durchkommt,
Geek: weil die wissen gar nicht, dass sie nicht durchgekommen sind, können sie sich sagen.
Geek: Aber es muss halt irgendwie schnell gehen oder es muss skalierbar sein.
Geek: Das System muss nicht zusammenbrechen, wenn alle Leute gleichzeitig um 16.25
Geek: Uhr einmal kurz drauf klicken, Antwort A ist die richtige, in irgendeinem Online-Ding.
Geek: Und so gilt es eben rauszufinden und zu sagen, was sind eigentlich meine Architekturprinzipien,
Geek: nach denen ich jetzt optimieren möchte, was ist mir wichtig in der A-B-Klasse
Geek: und dann vielleicht, was ist auch gar nicht wichtig.
Geek: Und dann kommst du, glaube ich, relativ schnell, wir sprachen schon kurz über
Geek: Datenbanken, kommst du zu verteilten Systemen einfach und dann bist du mitten
Geek: in CAP-Land, wo du halt sagst, das CAP-Theorem,
Geek: was der ein oder andere da draußen vielleicht schon kennt, wo man sagt,
Geek: jedes verteilte System zeichnet sich halt durchaus, es hat drei verschiedene
Geek: Arten von Eigenschaften.
Geek: Das eine ist, was war nochmal, C stand für Kapazität, nicht Kapazität.
Geek: Konsistenz. Konsistenz, genau. C ist Konsistenz, dass die Daten also stimmen
Geek: zwischen den verteilten Nodes.
Geek: Wenn ich zwei Server habe, auf denen mein Girokonto geführt wird.
Florian: Synchronisiert, ja.
Geek: Wäre das cool, wenn auf beiden stehen würde, dass ich 1.000 Euro auf dem Konto habe.
Florian: Ja.
Geek: Das ist Konsistenzthema. Dann war das Availability-Thema. Also das heißt,
Geek: ich kann darauf zugreifen. Ich kann sowohl bei dem einen als auch bei dem anderen
Geek: abfragen, ob ich 1.000 habe.
Geek: Und dann habe ich das dritte, Ausfallsicherheit. Das heißt, wenn der eine ausfällt,
Geek: hat der andere meine Daten.
Geek: Jetzt das Problem bei dem CAP-Theorem, dass man sagt, alles drei wirst du nicht
Geek: kriegen, weil du musst halt dich für zwei entscheiden.
Geek: Du kannst nicht sowohl alle Daten überall haben und es muss sofort verfügbar
Geek: sein und es kann ausfallsicher sein, sondern du musst halt entweder sagen,
Geek: die Daten sind konsistent und verfügbar, dann sind sie aber nicht ausfallsicher,
Geek: weil dann gibt es halt kleine Ausfallzeiten für die Synchronisierung oder du
Geek: hast ausfallsicher und available,
Geek: aber dann sind sie nicht konsistent, weil dann kann es sein,
Geek: dass sie auseinander gehen.
Geek: Und Microservices müssten dann ja eigentlich auch das klassische CAP-Phänomen mitbringen, oder?
Florian: Ja, klar. Also wir reden von verteilten Systemen. Das heißt,
Florian: alle Vor- und Nachteile verteilter Systeme habe ich bei Microservices auch.
Florian: Also das fängt bei sowas an wie CAP-Theorien und Datenkonsistenz.
Florian: Sehr oft tradet man eben das C gegen A und P.
Florian: Das hast du auf jeden Fall. Du hast aber auch solche Dinge wie,
Florian: du musst dir ja das grundlegende Kommunikationsparadigma erstmal angucken.
Florian: Also was heißt das? Bedeutet im Endeffekt, wie oder auf welche Art kommunizieren
Florian: meine Microservices miteinander?
Florian: Und das meine ich jetzt nicht technisch und das meine ich auch nicht im Sinne
Florian: von Synchron-Asynchron, was sicherlich auch nochmal eine wichtige Entscheidung
Florian: ist, die zu treffen, sondern sowas wie mache ich Choreografie oder Orchestrierung?
Florian: Also das heißt, habe ich zum Beispiel einen Microservice, der fünf andere Microservices
Florian: anweist, was sie zu tun haben und auch die Koordination übernimmt,
Florian: das wäre dann der Orchestrator,
Florian: oder habe ich eine Choreografie, das bedeutet, meine Microservices sind eigentlich Aufrufketten.
Florian: Ein Microservice ruft den nächsten auf, der ruft wiederum den nächsten auf und
Florian: so weiter und so fort. Das sind auch Dinge...
Geek: Flache oder starke Hierarchien sozusagen. Also einer hat den Chef da in dem Ring oder...
Florian: Denn wenn ich den Chefansatz fahre, also sprich Orchestrierung mache,
Florian: dann erhöhe ich ja wieder die Abhängigkeiten, weil ich bin auf diesen einen
Florian: Orchestrator immer angewiesen, dem muss es geben.
Florian: Wenn der mal irgendwann nicht funktionieren sollte, dann geht auf einmal nichts
Florian: mehr in Anführungszeichen. Und bei einer Choreografie, da sind es dann Aufrufcalls.
Florian: Dann geht es halt an die nächste Microservice-Instanz. Okay,
Florian: die geht vielleicht kaputt, aber dann kann vielleicht der Vorgänger-Microservice
Florian: nochmal einen anderen Microservice aufrufen oder eine Instanz dieses Microservices wieder aufrufen.
Florian: Also das ist eben auch eine Frage, die da eine Rolle spielt.
Florian: Nebenläufigkeit ist sowieso schon schwierig, wenn ich eine Monolithen irgendwie
Florian: habe. Nebenläufigkeit ist generell schwierig. Threading, klassisches Threading.
Geek: Erklär kurz Nebenläufigkeit.
Florian: Naja, dass eben verschiedene Bestandteile meines Codes quasi parallel ausgeführt werden könnten.
Florian: Weil mein Betriebssystem, der Scheduler, so schlau ist zu sagen.
Florian: Schneide jetzt irgendwie den Programmablauf in Zeitscheiben und es sieht quasi
Florian: so aus, als würden verschiedene Bestandteile meines Codes parallel ablaufen,
Florian: auch wenn sie das jetzt effektiv gar nicht tun, aber es wirkt so.
Florian: Viele Probleme, die du hast, kannst du parallelisieren. Das ist eine ganz schöne
Florian: Sache, dadurch werden die Dinge schneller, weil du deine Prozessorkerne optimaler ausnutzt.
Florian: Und das habe ich jetzt vielleicht bei einem Monolithen auf meinem lokalen Rechner,
Florian: aber wenn ich jetzt irgendwie meine Software habe und das sind Microservices
Florian: und ich habe zehn Microservices, die verteile ich auf zehn Server,
Florian: dann kann es mir natürlich passieren, dass da Dinge, oder dann wird es mir passieren,
Florian: dass da Dinge parallel laufen, dass der eine Microservice vielleicht damit eine
Florian: Aufgabe schneller fertig ist als ein anderer Microservice.
Florian: Das heißt, ich brauche irgendeine Koordinierung, weil die vielleicht sich an
Florian: einem gemeinsamen Punkt die Ergebnisse wieder zusammengefasst werden müssen
Florian: und all solche Dinge. Also das ist etwas, was bei einem verteilten System im
Florian: Bauch sozusagen mit drin ist und was ich auch niemals umgehen kann.
Florian: Und das sind alles Sachen, mit denen ich mich vorher auseinandersetzen muss.
Florian: Also was du gerade sagtest, CAP-Theorem spielt eine Rolle, diese Geschichte
Florian: mit Orchestrierung, Choreografie, dann so Sachen wie mit Nebenläufigkeit sind
Florian: alles Komplexitäten, die ich mir bei einer Microservice-Architektur mit reinhole.
Florian: Und da muss ich eben dann am besten vorher so eine Art Bilanz schon ziehen und
Florian: einen Abgleich machen. Ist es mir das wert?
Florian: Sind die Schmerzen in Skalierbarkeit, in Wartbarkeit so groß,
Florian: dass ich das wirklich haben will und dass ich das wirklich in Kauf nehme?
Florian: Dem muss man sich gewahr werden, auf jeden Fall.
Geek: Lass uns über State sprechen.
Florian: Über State, ah, sehr gerne.
Geek: Wo wir beim Orchestrator schon sind. Wer weiß eigentlich, was da gerade Phase
Geek: ist, wo es gerade langläuft?
Geek: Weil wir haben ja eigentlich einen Prozess, der mehrschrittig ist,
Geek: also entweder in der choreografierten Fassung, der mehrere Stages durchläuft,
Geek: einen Antrag für eine neue Versicherung, wo Prüfungen durchgehen,
Geek: wo vielleicht nochmal Tarife gecheckt werden.
Geek: Also alles, was irgendwie mehrschrittig ist und abläuft, hat ja irgendeine Art
Geek: von State. Also wenn ich es in einem Schritt machen kann, dann bin ich bei dem
Geek: Taschenrechner-Beispiel mit
Geek: wenig Komplexität, dann muss ich mir keine States merken. Was ist State?
Geek: Wie merkt man sich das bei Microservices?
Geek: Wo sind die Herausforderungen?
Florian: Also State grundsätzlich erstmal, Übersetzung ist ja Zustand,
Florian: so irgendwie, Software hat einen Zustand, wenn man das jetzt wieder irgendwie
Florian: auf, weiß ich nicht, im Java-Universum sind oder objektorientierte Programmierung
Florian: als solche, gucken uns eine Klasse an, ich instanziiere eine Klasse,
Florian: erzeuge ein Objekt davon,
Florian: die Klasse hat fünf Attribute, da stehen fünf Werte drin, dann sind diese fünf
Florian: Werte in dem Objekt der Zustand von diesem Objekt.
Florian: Und das habe ich bei jedem Programm, auch bei dem Taschenrechner-Programm,
Florian: was du gerade sagtest, könnte man als State sowas wie Speicher zum Beispiel
Florian: sehen, ich habe irgendwie jetzt ein Ergebnis, das lege ich in meinem Speicher
Florian: ab, dann erzeuge ich ein anderes Ergebnis, lege ich einen anderen Speicher ab
Florian: und greife auch beide Speicher wieder zu, um diese Ergebnisse irgendwie vielleicht
Florian: zu multiplizieren oder sowas.
Florian: Das heißt, so ein Taschenrechner hat theoretisch ja auch schon irgendwo ein State, ne?
Florian: Bei Microservices ist das State-Handling wichtig, denn ich muss mir klar machen,
Florian: dass ich meine Microservices eigentlich im besten aller Fälle immer stateless halte.
Florian: Das heißt, so ein Microservice hält, oder sagen wir mal anders.
Geek: Also ich kriege alles geschickt, was ich brauche, um den Job zu erledigen.
Florian: Ja, oder aber ich halte es irgendwo vor, wo es egal ist, ob jetzt der Microservice
Florian: abstürzt oder nicht. Also an der Stelle vielleicht auch nochmal eben kurz,
Florian: weil es wird oft auch in diesen Microservice-Diskussionen miteinander vermischt.
Florian: Microservice würde ich jetzt mal eher mit einer Klasse gleichsetzen.
Florian: Ich habe irgendwo meinen Programmcode, den kann ich ausführen.
Florian: Und worüber wir eigentlich dann reden, wenn es um State geht,
Florian: ist eben die Instanz. Also im Klassenfall wäre es das Objekt und bei Microservice
Florian: wäre es einfach eine Microservice-Instanz.
Florian: Das heißt, wenn ich jetzt eine Microservice-Instanz habe, entweder macht man
Florian: es so, wie du es gerade gesagt hast, Die kriegt alles geschickt,
Florian: was sie braucht, führt dann ihre Funktionalität aus, liefert das Ergebnis zurück,
Florian: muss es auch nirgendwo zwischenspeichern und der Empfänger ist mit dem Ergebnis glücklich.
Florian: Das heißt, die Microservice-Instanz hält keinen Zustand vor.
Florian: Sie berechnet, macht Berechnungen auf Basis von Eingabewerten und schickt einen
Florian: Ausgabewert raus, ohne irgendwelche Zwischenergebnisse irgendwo speichern zu
Florian: müssen oder zumindest sich nicht darauf verlassen zu müssen,
Florian: dass diese Dinge beim nächsten Aufruf auch wieder da sind, derselben Instanz.
Geek: Klingt sehr robust, aber klingt auch sehr nach Overhead, weil wenn ich jetzt
Geek: so eine orchestrierte Variante habe oder eine choreografierte.
Geek: Mit sieben Schritten und ich muss bei jedem Schritt alles mit übergeben,
Geek: habe ich relativ viel Overhead, um die einzelnen Dienste dann aufzurufen.
Geek: Gerade wenn es jetzt vielleicht noch Dokumente gibt, die ich da weiterverarbeite.
Geek: Hier, ich schicke dir noch eine PDF-Datei mit, 4 Megabyte.
Geek: Das ist das Antragsformular, was er ausgefüllt hat. Hier, nimm das mal.
Geek: Das ist natürlich relativ viel dann.
Geek: Der Teil ist super robust unabhängig, weil jeder Anfrager hat alle Daten.
Geek: Das heißt, ich habe wenig Dependencies.
Geek: Und super testbar, schön isoliert für sich, aber ist halt auch teuer irgendwie.
Florian: Genau, ist teuer, also führt unter Umständen zu Overengineering,
Florian: weil du auf einmal da auch wieder, das ist ja auch ein Teil von Komplexitäten,
Florian: du hast auf einmal Dinge in deinem Quellcode drin, wo du dich erstmal fragst,
Florian: warum steht das überhaupt hier?
Florian: Weil wenn ich mir die Funktionalität als solche angucke, macht es gar keinen
Florian: Sinn, dass ich so viele Daten durch die Gegend parse.
Florian: Mache ich aber, weil sonst habe ich ein Problem, ich habe die Daten nicht zur Verfügung.
Florian: Das ist eine Möglichkeit zu sagen, ja, wir übertragen alle Daten mit,
Florian: erhöht natürlich auch wieder Netzwerkaufwand.
Florian: Das heißt, es wird dann unter Umständen noch langsamer, als es vielleicht sowieso schon ist.
Florian: Andere Möglichkeit sind, es gibt verschiedene Pattern, die in der Regel darauf
Florian: basieren, dass dem Microservice und jetzt wirklich dem Microservice,
Florian: nicht der Instanz, eine Datenbank dabei gestellt wird, in die dieser Microservice
Florian: Zwischenergebnisse ablegen kann.
Florian: Es gibt zum Beispiel Transactional Inbound Pattern oder Inbox Pattern oder Outbox
Florian: Pattern, wo du im Endeffekt sagst, ich organisiere
Florian: die Eingaben für meine Microservice-Instanzen wie so eine Art Queue.
Florian: Das ist dann einfach eine Datenbank, an die darauf optimiert ist, das zu tun.
Florian: Und dann können die Microservice-Instanzen eben die Ergebnisse oder die Anfragen
Florian: aus dieser Datenbank abholen, bearbeiten sie und legen sie in eine Ausgangsdatenbank.
Florian: Und dann werden diese mit der Zeit dann eben wieder rausgeschickt.
Florian: So, das ist dann ein Microservice, der hat dann vielleicht, wenn man es jetzt
Florian: überspitzt sagt, zwei Datenbanken, die noch anhängen und vielleicht sogar noch
Florian: zwei kleine Hilfsprogramme, die die Queue befüllen und die die Queue auch wieder auslesen.
Florian: Oder es macht ein Message Broker. Aber man merkt schon daran,
Florian: du hast auf einmal deutlich mehr Komponenten in deiner Architektur,
Florian: von der eigentlich nur eine einzige fachlich motiviert ist, das ist der Microservice.
Florian: Und die anderen sind technisch motiviert, um zum Beispiel State zu verhindern.
Florian: Das heißt, man kann das alles tun, aber man braucht eben gute Gründe,
Florian: dass man sich diese Art der Komplexität in die Architektur reinholt.
Florian: Und das muss einem vorher bewusst sein.
Geek: Für die Taschenrechner-App reicht es vermutlich nicht. Ja.
Geek: Für ein Team von drei Entwicklern vielleicht auch nicht, wo man sagt,
Geek: das geht alles in einer Codebasis, das muss ein bisschen größer werden.
Geek: Sind Message Broker, Queues und dergleichen, sind das Konstrukte,
Geek: die im Zuge von Microservices aufgekommen sind oder gab es die auch vorher schon?
Geek: Weil ich überlege die ganze Zeit, wofür man die sonst braucht.
Geek: Ansonsten würde man eine klassische Datenbank sehr wahrscheinlich nehmen und
Geek: dann braucht man solche Dinge womöglich gar nicht.
Florian: Also Message Broker und sowas, das gab es ja alles vorher schon,
Florian: die haben ja durchaus auch ihre Berechtigung, wenn ich eben,
Florian: das meinte ich gerade mit Synchron versus Asynchron und du hattest gerade von
Florian: den RESTful oder von den REST-Schnittstellen gesprochen, HTTP-Schnittstellen
Florian: sind es ja vielfach, dann habe ich da in der Regel eine synchrone Kommunikation,
Florian: also schicke Anfrage rein,
Florian: bearbeite Anfrage, schicke Anfrage raus und der Client arbeitet erst weiter,
Florian: wenn er die Antwort bekommen hat.
Florian: Oder aber mache ich es asynchron und dann brauche ich in der Regel oder habe
Florian: ich sowas wie einen Message Broker, also wo ich im Endeffekt als Microservice sage,
Florian: ich stelle eine Anfrage, die schicke ich auf den Message Broker,
Florian: der leitet sie weiter an eine Instanz des Microservices, der diese Anfrage bearbeiten
Florian: kann, verarbeitet die Anfrage, schickt das Ergebnis wieder auf den Message Broker
Florian: und der leitet es wieder zurück an meinen Microservice.
Florian: Message Broker gab es vorher schon, ganz einfach, weil asynchrone Kommunikation
Florian: damit umgesetzt werden kann, eine Möglichkeit das zu tun, hat absolut seine
Florian: Berechtigung, weil es eben alle Vorteile von asynchroner Kommunikation mit sich
Florian: bringt, natürlich auch alle Nachteile.
Florian: Bei Microservices, das sehen wir ja auch bei einigen Kunden im Moment,
Florian: die sagen, wir wollen jetzt auf Microservices migrieren und wollen sofort eine
Florian: eventgetriebene Architektur. Event-Modell.
Florian: Also Asynchronen, Message Broker, ob man es jetzt Event oder Nachricht nennt,
Florian: kann man sich auch darüber streiten, aber wir wollen eine Event-getriebene Architektur,
Florian: weil wir die volle Asynchronität haben wollen, die volle Skalierbarkeit haben
Florian: wollen, weil dadurch hole ich mir noch mehr Skalierbarkeit, noch mehr Unabhängigkeit,
Florian: noch mehr lose Kopplung mit rein.
Florian: Nein, wollen wir alles haben, weil wenn, dann wollen wir es sofort richtig machen, in Anführungszeichen.
Florian: Und das ist natürlich nochmal, nochmal ein Komplexitätsschub obendrauf oder
Florian: nochmal eine Komplexitätsschippe obendrauf gelegt, weil ich dann auf einmal
Florian: von meinen schönen, synchronen HTTP-Calls weg bin und habe da noch Events irgendwie mit drin.
Florian: Das macht die Sache nicht einfacher. Also ich brauche wirklich gute Gründe, dass ich genau das tue.
Florian: Und das ist eben Skalierbarkeit, also eine hohe Performance.
Florian: Ich brauche eine bessere Testbarkeit, ich brauche eine bessere Wartbarkeit, all diese Dinge.
Florian: Ja, da muss ich schon sehr gute Gründe haben, damit ich mir dann diese ganze
Florian: andere Komplexität mit reinhole.
Florian: Es hört ja da auch nicht auf, du brauchst dann auch sowas wie eine Container-Orchestration-Plattform,
Florian: weil ohne das macht es keinen Sinn.
Florian: Also irgendjemand muss ja auch gucken, dass die Instanzen der Microservices
Florian: vorgehalten werden, am besten in Abhängigkeit von den Anfragen.
Florian: Sowas wie Elastizität ist dann ein Buzzword in diesem Bereich.
Florian: Also all diese Dinge. Und will ich das?
Florian: Brauche ich das? Und wie gesagt, in vielen Fällen ist die Antwort auch einfach nein.
Florian: Brauche ich nicht. Oder ich sollte vielleicht erstmal gucken,
Florian: dass ich meinen Monolithen, den ich da stehen habe, vielleicht mal auf Vordermann bringe.
Florian: Vielleicht ist der auch, basiert der auf, weiß ich nicht, einer Technologie,
Florian: einem Technologie-Stack, der vielleicht einfach nicht so effizient ist wie ein anderer.
Florian: Oder er ist veraltet und ich möchte, sollte vielleicht mal irgendwie da migrieren
Florian: und dann erstmal gucken, ob es dann immer noch so schlimm ist, wie es eben ist.
Geek: Lass uns durch die Zeit wandern und mal schauen, zu welcher Lebenszyklusphase
Geek: eigentlich welche Architektur sinnvoll ist oder besser geeignet,
Geek: sagen wir es mal so. Sinnvoll ist sie vielleicht immer.
Geek: Ich stelle mir vor, ich habe erstmal jetzt eine Idee. Ich habe noch keine Software.
Geek: Ich bin auf einer grünen Wiese, habe eine Idee, ein Business-Problem, was ich lösen möchte.
Geek: Und ich möchte relativ schnell verifizieren, ob das das auch tatsächlich löst
Geek: und ob man das bauen kann. Monolith oder Microservice?
Florian: Es gibt auch zwei Lager. Es gibt einmal die Leute, die sagen Monolith first,
Florian: also du sollst immer einen Monolithen erst bauen.
Florian: Es gibt aber auch die anderen Leute, die sagen, wenn du sowieso eine Microservice-Architektur
Florian: anschreibst, baue sofort die Microservices, weil sonst hast du einen doppelten Aufwand.
Florian: Ich finde, die Frage kann man auch wieder nicht pauschal beantworten,
Florian: hängt zum Beispiel auch mit dem Team zusammen.
Florian: Ist es vielleicht ein Team, das ist so erfahren im Microservice-Bereich und
Florian: so eingespielt, dann lass die Microservices bauen, weil sie wissen ja, was sie tun.
Florian: In der Regel ist es aber schon so oder sinnvoller, einen Monolithen zu bauen,
Florian: weil ich mir mir diese ganze Komplexität, die ich gerade so am Anfang bei einem
Florian: Greenfield-Projekt, kann ich es ja vielleicht noch gar nicht abschätzen.
Florian: Also habe ich da überhaupt, brauche ich diese Art der Skalierbarkeit?
Florian: Wenn ich weiß, ich werde, weiß ich nicht, 10 Millionen Benutzer haben und die
Florian: Business-Domäne so kompliziert, das macht alles keinen Sinn,
Florian: wir müssen Microservices machen, okay, geschenkt.
Florian: Aber wenn man jetzt irgendwie, weiß ich nicht, man baut einen Proof of Concept
Florian: und der soll zeigen, dass man irgendwie es drauf hat, die Fachlichkeit umzusetzen,
Florian: die diese Domäne eben mitbringt.
Florian: Und du hast jetzt nicht Leute, die machen jetzt seit, weiß ich nicht,
Florian: fünf oder zehn Jahren erfolgreich Microservices, dass die einen Monolithen bauen.
Florian: Bist du auf der sicheren Seite, weil du dir eben diese ganze Komplexität,
Florian: Nebenläufigkeit, also die Komplexität von verteilten Systemen nicht mit reinholst.
Geek: Mit meinem gefährlichen Halbwissen über DevOps weiß ich ja, du könntest ja theoretisch
Geek: dir ein schönes Docker-Compose malen und da steht dann drin,
Geek: ich kriege mir meinen Message-Broker hier hin, ich hole mir hier verschiedene
Geek: Instanzen da hoch, ein bisschen Kubernetes orchestrieren, auch das ist 2024
Geek: nicht mehr so das große Ding.
Geek: Also hat man auch schon mal geschafft, dass man das irgendwie orchestriert bekommt.
Geek: Elastizität, also das Anpassen an, ich checke, wie viele Anfragen kommen und
Geek: dann fahre ich mehr von den Services hoch oder eben nicht.
Geek: Das kriegt man ja alles schon hin und von dem Hintergrund, dass man das schon
Geek: mal gemacht hat, würdest du trotzdem sagen, man nimmt eher einen Monolithen,
Geek: weil man möchte ja verproben, dass das Inhaltliche funktioniert und du hast
Geek: halt weniger bewegliche Teile, an denen du dann irgendwie scheitern kannst, wo es Probleme gibt,
Geek: wo du dich darum kümmern musst, sodass du also einen stärkeren Fokus hast.
Florian: Wäre meine Empfehlung an der Stelle, wobei ich einen Docker-Compose und Kubernetes
Florian: ja auch mit einem Monolithen machen kann. Also da spricht ja jetzt erstmal nichts
Florian: gegen, es trotzdem einzusetzen.
Florian: Es kommt so ein bisschen halt auch auf, das meine ich gerade mit Team-Erfahrung an.
Florian: Also wenn du jetzt Leute hast, die haben genau diese Microservice-Denke,
Florian: da weiß jeder, was er tut. Die sind vielleicht auch eingespielt,
Florian: das ist ja auch ein wichtiger Faktor.
Florian: Dann lass sie eben ein Microservice bauen oder Microservice- Architektur bauen, aber,
Florian: Für alle anderen Fälle, wenn es jetzt wirklich nur darum geht,
Florian: erstmal eine Idee zu verproben, bauen einen Monolithen. Also du kannst,
Florian: du hast gerade Shopify als Beispiel genannt.
Florian: Wenn die mit ihrem Monolithen super fahren, dann ist das doch ein gutes Beispiel
Florian: dafür, dass ein Monolith jetzt auch nicht die schlechteste Idee aller Zeiten ist.
Florian: Selbst wenn du sagst, du willst jetzt irgendwie in die Cloud rein oder sowas.
Florian: Shopify wird wahrscheinlich auch irgendeiner Art und Weise in irgendeiner Cloud sein.
Florian: Dann scheint ein Monolith ja da an der Stelle zu funktionieren.
Florian: Und warum dann nicht einen Monolithen bauen?
Geek: Streng genommen, sie nennen es einen Modolithen, den sie da haben.
Florian: Ah, interessant. Okay, ja.
Geek: Und die hatten eine lustige Darstellung, wo sie so ein Koordinatsystem hatten.
Geek: Unten ist irgendwie wenig Struktur, oben ist viel Struktur. Links ist Monolith,
Geek: rechts ist Microservice. Und unten war bei beidem Big Ball of Mud.
Geek: Also das war halt, wenn es unstrukturiert ist, ist es halt unstrukturiert,
Geek: ob du Microservices nimmst oder einen Monolithen hast.
Geek: Und dann haben sie es hochgehoben und gesagt, ein strukturierter Monolith ist
Geek: ein Modulit. So nennen sie sich den.
Geek: Und wenn du bei den Microservices oder bei dem dezentralen, hieß es glaube ich
Geek: da eher in der X-Achse, wenn du da weiter nach rechts gehst und dezentral bist
Geek: und nicht bei Big Ball of Mud, sondern strukturiert bist, dann bist du bei Microservices.
Florian: Ja, ist auch das, was wir gerade sagten. Also Microservices zwingen dich halt
Florian: dazu, stärker in den Bereich Modularisierung zu denken, wieder hohe Kohäsion,
Florian: lose Kopplung, First Principles und sowas.
Florian: Also du kannst das aber genauso gut mit einem Monolithen eben auch tun.
Florian: Wenn er sauber, vernünftig strukturiert ist, wie du das gerade gesagt hast,
Florian: dann habe ich die Schmerzen im Bereich Wartbarkeit wahrscheinlich eher nicht
Florian: weil eine sauber modularisierte Software ist in der Regel gut wartbar,
Florian: Performance ist oder Skalierung ist was anderes da muss ich mir bewusst sein,
Florian: wenn ich das irgendwann nicht mehr hinbekomme einen Monolithen kann ich auch
Florian: skalieren davon mal abgesehen, aber wenn das vielleicht irgendwann nicht mehr
Florian: funktioniert und ich kann eingrenzen und kann sagen okay, das liegt daran,
Florian: weil es eben ein Monolith ist,
Florian: dann macht es vielleicht Sinn, in Richtung Microservices mal zu denken und zu schauen.
Florian: Und da stellst du dann auch die Frage, muss ich denn wirklich meine komplette Software migrieren?
Florian: Oder reicht es vielleicht auch nur, wenn Teile davon als Microservices ausgelagert
Florian: werden? Das ist ja möglich.
Florian: Beispiel auch wieder, wenn man an Netflix denkt. Ich meine, die sind komplett auf Microservices.
Florian: Aber wenn ich jetzt irgendwie eine
Florian: Plattform wieder habe, da ist eine Benutzerverwaltung drin und Streaming.
Florian: Und die Domäne, in der ich mich bewege, ist Videostreaming. Dann wird wahrscheinlich
Florian: eine sehr häufig aufgerufene Funktionalität das Videostreaming sein.
Florian: Das heißt, es macht dann schon Sinn, das vielleicht rauszulösen und separat
Florian: skalierbar zu machen. Weil Millionen Leute Filme streamen parallel.
Florian: Aber vielleicht machen nur 5000 davon, ändern ihr Passwort in der Benutzerverwaltung parallel.
Florian: Das heißt, dann an der Stelle kann ich vielleicht auch sagen,
Florian: okay, ich belaste das jetzt in meinem Monolithen, wenn es denn ein Monolith ist.
Florian: Aber es ist natürlich auch wieder genau so eine Argumentation für Microservices,
Florian: dass ich gezielt skalieren kann.
Florian: Ich kann sagen, dieser eine Microservice, der wird so oft aufgerufen,
Florian: da muss ich eine Million Instanzen von vorhalten und von dem anderen muss ich
Florian: vielleicht nur 5000 vorhalten.
Florian: Der wird nicht so oft aufgerufen. Das heißt, ich kann da nochmal wirklich separat
Florian: skalieren. Und das ist eben auch immer ein Vorteil von Microservices.
Florian: Aber die Frage ist immer, brauche ich das wirklich?
Florian: Ist es wirklich so notwendig in der Form?
Geek: Wenn wir weitergehen in der Zeit, wir haben jetzt gesagt, mein grandioses Projekt
Geek: ist erfolgreich gewesen. Der Monolith, der gebaut wurde, dank deiner Empfehlung,
Geek: hat sich bewährt und jetzt möchte ich gerne skalieren.
Geek: Da gibt es für mich zwei Ebenen, auf denen ich skalieren kann.
Geek: Das eine ist die organisatorische.
Geek: Im Sinne von jetzt habe ich aber richtigen Geldcheck bekommen von meinem Chef,
Geek: der sagt jetzt hoch raus, legen Sie mal ordentlich Geld rein und dann kann ich
Geek: fünf Teams haben. Das heißt, dafür würde ich auch erst mal schauen,
Geek: wie schneide ich das, dass diese Teams unabhängig voneinander arbeiten können.
Geek: Aber das Spannendere für mich ist eigentlich das operative Thema mit an welcher
Geek: Stelle krankt meine App?
Geek: Also wo brauche ich denn viel? Wir sprachen gerade schon drüber,
Geek: wenn man wieder so ein Gewinnspiel nimmt, so ein Fragespiel, Ratespiel.
Geek: Die Fähigkeit, Fragen einzustellen, brauche ich relativ selten, weil ich mache ein Quiz.
Geek: Aber das Abfragen oder das Raten,
Geek: ist dann natürlich ein viel höher skalierendes Ding. Und jetzt die gesamte Software
Geek: zu nehmen und zu sagen, packe ich einfach mal ganz drauf, der eine Code-Teil
Geek: läuft halt gerade nicht, ist das äquivalent mit dem zu sagen,
Geek: ich separiere einfach diesen Code-Teil raus?
Geek: Also, verstehst du, worauf ich hinaus möchte? Weil ich kann ja den ganzen Code
Geek: drin haben, ich kann ihn nur nicht benutzen, einfach in den Monolithen oder,
Geek: und dann quasi den Monolithen siebenmal nebeneinander stellen.
Florian: Ja, genau, also, das ist ja, das führt ja dann wieder zu, ne,
Florian: also es gibt ja auch verschiedene Arten der Skalierung, die ich fahren kann.
Florian: Mache ich horizontale oder vertikale Skalierung?
Florian: Vertikale Skalierung bedeutet in der Regel, ich bohre meinen Server auf,
Florian: also stecke mehr Ressourcen quasi in bestehende.
Geek: Mehr Prozessor.
Florian: Mehr Prozessor irgendwie rein. Oder mache ich eine horizontale Skalierung und
Florian: sage, ich stelle einfach mehrere Rechner oder meinetwegen mehrere Monolithen
Florian: oder mehrere Microservices nebeneinander, also mehrere Instanzen.
Florian: Bei Microservices wäre das dann der Fall.
Florian: Microservice in der Regel horizontal skalierbar, weil es sind unterschiedliche
Florian: Applikationen, die starte ich eben mehrfach vereinfacht gesagt.
Florian: Dann habe ich sie die horizontal skaliert, fertig.
Florian: Also das ist schon implizit in diesem Architekturansatz mit drin.
Geek: Aber ich kann sie auch andersrum skalieren. Also hätte ich jetzt einen Microservice,
Geek: der relativ langsam ist, weil er zu wenig RAM hat, geht ja auch.
Geek: Und ich würde ihm einfach mehr RAM geben, würde sagen, diese Instanz braucht
Geek: grundsätzlich immer 128 Gig, damit die laufen kann.
Florian: Ja, tendenziell schon, aber in der Regel willst du ja deine Services so schneiden,
Florian: dass du jeden Service separat skalieren kannst.
Florian: Und wenn du diese Instanzen deiner Microservices hast, du willst auch die Flexibilität
Florian: haben, die Dinger laufen ja in der Regel in der Cloud.
Florian: Meistens in der Cloud, die Flexibilität haben zu sagen, okay,
Florian: ich ziehe jetzt oder ich bündel jetzt die Instanzen auf diesem einen Node und
Florian: vielleicht die Instanzen auf diesem einen Node und dann cluster ich das alles mal irgendwie schön.
Florian: Man kann das trotzdem machen, da hast du vollkommen recht, aber in der Regel
Florian: würde man dann eher sagen, bevor man jetzt losgeht und fängt an,
Florian: Vertikal zu skalieren, schaue ich mir diesen betreffenden Microservice an und
Florian: gucke, warum ist der denn überhaupt so ineffizient?
Florian: Muss ich den vielleicht nochmal zerstückeln in mehrere? Ist das vielleicht so ein eigener Monolith?
Florian: Gibt es ja auch irgendwie, dass dann Leute nach Microservices migriert sind.
Florian: Ich habe da mal Ich habe auch mal eine Anekdote an einem Workshop gehört,
Florian: da wurde ein System, das bestand, ich glaube, umfangbar drei Millionen Lines of Code.
Florian: Vorhin habe ich nur gesagt, Lines of Code spielen keine Rolle,
Florian: aber da wurden drei Microservices rausgemacht.
Florian: Also es ist dann die Frage, sind das dann wirklich noch Microservices oder sind
Florian: das dann schon, weiß ich nicht, Macroservices? Ich weiß nicht,
Florian: ob man das beschreiben will, weiß ich nicht.
Florian: Also in der Regel willst du schon in Richtung horizontale Skalierbarkeit,
Florian: auch aufgrund der Flexibilität und eben Elastizität und sowas.
Florian: Also ich kann jetzt nicht sagen, weiß ich nicht, Netflix, verdammt,
Florian: wir haben jetzt hier irgendwie die eine Million und einste Instanz,
Florian: Da muss der Techniker in den Keller und muss da RAM-Module noch reinstecken,
Florian: damit die dann funktioniert und auch der eine Million einste Kunde irgendwie
Florian: Video streamen kann. Also das willst du ja in der Regel nicht.
Florian: Sondern bei Microservices hast du die horizontale Skalierung eigentlich schon
Florian: mit dem Bauch, wenn du jetzt nicht irgendwie komplett ineffizient schneidest.
Florian: Genau. Und bei Monolithen kommt es halt darauf an, kommt der Monolith,
Florian: wie ist der Monolith aufgebaut? Kommt der mit horizontaler Skalierung?
Florian: Klar. Klar, also oft hat man früher so Beispiele, J-Boss oder Wildfly oder sowas
Florian: sind ja immer so Beispiele für klassische monolithische Anwendungen,
Florian: weil diese beiden Systeme, diese beiden Applikationsserver stellen mir eine
Florian: Ausführungsumgebung bereit.
Florian: Ich habe alle Abhängigkeiten, die ich brauche, sind schon da.
Florian: Ich muss nur noch den Java-Quellcode schreiben für meine Fachlichkeit und bin fertig.
Florian: Trotzdem kommt es auf die Anwendung an, wie gut kommt die denn damit klar,
Florian: wenn ich jetzt auf einmal zwei Instanzen nebeneinander stehen habe,
Florian: die vielleicht auch noch gesynct werden müssen. Habe ich diese Funktionalität schon mit dabei?
Florian: Dann schaltet man in der Regel einen Loadbalancer davor. Das heißt,
Florian: das Problem ist schon mal gelöst.
Florian: Es kommen irgendwie viele Anfragen rein, die können verteilt werden,
Florian: aber kommen meine Systeme damit klar, wenn Anfragen auf einmal auf verschiedene
Florian: Systeme verteilt werden.
Geek: Genau, dann brauchst du so eine Art Session Stickiness und selbst dann bricht
Geek: dir eine Node weg und dann musst du halt überprüfen.
Florian: Irgendwie sowas, genau.
Geek: Aus Nutzerperspektive hast du ja einen State, weil in meinem Antragsvorgang läuft es immer weiter.
Geek: Oder mit meinem 10-schrittigen Gewinnspiel, wer wird Millionär im Web,
Geek: hätte ich gerne nach Frage 8 auch Frage 9 noch beantwortet und er soll wissen,
Geek: dass ich sie alle richtig beantwortet habe.
Florian: Das kann dir bei Microservice-Architektur natürlich auch passieren,
Florian: aber da bist du ja gezwungen, das mitzudenken.
Florian: Also die ist ja von vornherein klar oder sollte zumindest von vornherein klar
Florian: sein, es sind verschiedene Applikationen, die reden über Netzwerk miteinander,
Florian: die können auch komplett verteilt irgendwo laufen auf der ganzen Welt.
Florian: Also muss ich mir von vornherein Gedanken über genau so etwas machen wie Session Management.
Florian: Auch ein Riesenthema im Microservice-Bereich. Wie regelt man sowas?
Florian: Und das hast du bei einem Monolithen vielleicht am Anfang nicht mitbedacht,
Florian: Weil du sagst, ich habe jetzt hier meine 5000 Benutzer, läuft.
Geek: Ist ja immer hier.
Florian: Ja, genau. Und jetzt ist meine Company auf einmal explodiert.
Florian: Die Nutzerzahlen sind gestiegen. Das ist super geil.
Florian: Aber vielleicht kommt der Monolith jetzt nicht mehr damit klar.
Florian: Wir brauchen eine zweite Instanz, die daneben läuft.
Florian: Und auf einmal stellt man fest, ja, sowas wie Session Stickiness haben wir aber nicht mitbedacht.
Florian: Dann muss man es nachträglich irgendwie einbauen. Und das bereitet in der Regel
Florian: dann natürlich auch Kopfzerbrechen.
Florian: Das ist dann wieder so an der Stelle der Nachteil. Das ist natürlich richtig, genau.
Florian: Aber wie viel willst du vorher antizipieren? Das ist auch immer so die Frage.
Florian: Du willst ja KISS-Prinzip erstmal möglichst einfach halten.
Geek: Hast du irgendeine Idee, wie man von außen mitbekommen kann,
Geek: ob man es mit einem Monolithen oder mit Microservices zu tun hat?
Florian: Das ist eine sehr gute Frage. Im besten Fall kriege ich das als Benutzer nicht mit.
Florian: Also mir ist es egal, ob Spotify ein Monolith oder eine Microservice-Architektur
Florian: ist, das Ding tut, was es soll.
Florian: In der Art und Weise, wie ich es eben erwarte. Das heißt, im besten Fall sollte
Florian: ich es nicht mitbekommen.
Florian: Im schlimmsten Fall könnte ich es dadurch mitbekommen, dass auf einmal gewisse
Florian: Funktionalitäten wegbrechen und vielleicht auch nie wiederkehren.
Florian: Weil vielleicht es wurde eine neue Version eines Microservices ausgeliefert,
Florian: die hat irgendwie einen Bug und jetzt lassen sich Instanzen nicht mehr starten.
Florian: Auf einmal kann ich vielleicht im schlimmsten Fall über Tage hinweg so eine
Florian: Benutzerverwaltung nicht mehr aufrufen.
Florian: Bei einem Monolithen ist es so, in der Regel redet man über einen Deployment-Monolithen,
Florian: Sprich, ich muss die komplette Anwendung zusammen deployen.
Geek: Ganz oder gar nicht.
Florian: Ganz oder gar nicht, genau. Und je nachdem, wie das Ding dann modularisiert
Florian: ist, wenn ich so Fehlerkaskaden vielleicht drin habe, kann es mir auch passieren,
Florian: dass vielleicht dann die ganze Anwendung weg ist, wenn auf einmal irgendwo ein Riesen-Bug drin ist.
Florian: Aber hoffentlich habe ich so gute Tests da drin und ist mein Testumfang so hoch,
Florian: dass ich solche Fehler frühzeitig erkennen kann.
Florian: Das kann man bei Microservices, was wir auch noch gar nicht besprochen haben,
Florian: ist eben dieser Team-Aspekt.
Florian: Bei einem Monolithen habe ich vielleicht ein großes Team, das irgendwie daran
Florian: arbeitet, habe sehr viel Erfahrungswissen da drin, Kommunikationsstrukturen
Florian: mögen vielleicht ineffizient sein, aber ich habe immer Zugriff auf das gesamte
Florian: Wissen im besten Fall und das ist hoffentlich irgendwo vernünftig abgelegt und dokumentiert.
Florian: Bei Microservices, wenn ich komplett unabhängige Teams habe,
Florian: dann arbeitet das eine Team, was so Fehlerkaskaden Vermeidung oder auch Testabdeckung
Florian: oder sowas, arbeitet vielleicht besser als ein anderes Team.
Florian: Dann hoffe ich doch, dass das andere Team vielleicht an Funktionen arbeitet,
Florian: die nicht so wichtig sind und die stabiler laufen oder vielleicht weniger stabil
Florian: laufen müssen als andere Dinge.
Florian: Das sind auch so Dinge. Und Organisationsstruktur, was du gerade sagtest.
Florian: Da muss ich eigentlich, wenn ich Microservices machen will, komplett umdenken.
Florian: Das muss mir auch klar sein. Also das ist dann aber wieder eher eine Entscheiderebene.
Florian: Also Microservice-Architektur macht
Florian: eigentlich keinen Sinn, wenn ich Teamstrukturen habe, die homogen sind.
Florian: Sowas wie, ich habe eine Business-Analysten-Abteilung, ich habe eine Entwickler-Abteilung
Florian: und ich habe dann noch die Admin-Abteilung oder die Betriebsabteilung.
Florian: Das willst du dann da an der Stelle eigentlich nicht mehr haben,
Florian: sondern dann willst du eben auch heterogene Teams, die so einem DevOps-Gedanken folgen können.
Florian: Das spielt eben auch mit rein. Aber ja, im besten Fall, um wieder zu der Ausgangsfrage
Florian: zurückzukommen, merke ich es hoffentlich nicht,
Florian: mit was für einem System ich spreche, weil ich als Benutzer erwarte eine Funktionalität
Florian: und wie das dahinter umgesetzt wird, muss mir eigentlich egal sein können,
Florian: wenn das Produkt erfolgreich sein soll.
Geek: Wo du bei den Teamstrukturen warst, so ein bisschen Conway steckt da ja auch drin.
Geek: Conways Law, wo man sagt, die Art und Weise, wie du eine Organisation aufbaust,
Geek: also eine Aufbau- und Ablauforganisation, spiegelt sich auch in den IT-Systemen dann ultimativ wieder.
Geek: Sodass man sagt, wenn da Abteilungen zum Beispiel nicht gerne miteinander sprechen,
Geek: sprechen deren Softwares vermutlich auch nicht so gerne miteinander.
Geek: Und ultimativ, wenn du eben sagst, du machst Microservices, du möchtest natürlich,
Geek: dass diese einzelnen vollwertigen Apps miteinander reden,
Geek: dann musst du natürlich auch eine Struktur haben, die eben genau das auf organisatorischem
Geek: Level erlaubt und eine Kultur, die das in irgendeiner Form unterstützt.
Florian: Genau, also ohne diese Kultur, und das machen sich viele Unternehmen auch nicht bewusst,
Florian: dass Microservices eben nicht nur Software-Architektur sind oder irgendwas mit
Florian: Technologie zu tun haben, sondern es ganz stark darauf ankommt,
Florian: wie meine Organisationsstruktur ist.
Geek: Kann ich das nicht einfach über einen API-Gateway lösen? Also könnte ich nicht
Geek: einfach meine Teams alle in den Keller sperren, jeder in den eigenen Keller,
Geek: und dann sagen wir, ich mache einen API-Gateway, dann könnt ihr doch lesen,
Geek: wie die alle funktionieren, dann brauche ich kein Conway's Law mehr.
Geek: Ich kann mir nicht vorstellen, wie das funktioniert, aber vielleicht...
Florian: Also ein API-Gateway ist, glaube ich, grundsätzlich in vielen Bereichen eine
Florian: sinnvolle Idee, weil es mir irgendwie Schnittstellenmanagement erlaubt.
Florian: Nur wenn meine Organisation von vornherein, also es kommt so ein bisschen darauf
Florian: an, wie viel Autonomie will ich meinen Teams eigentlich geben?
Florian: Weil ein Vorteil, der bei Microservices auch oft mitspringt,
Florian: ist Technologie-Heterogenität. Also das heißt, du kannst, weil es unterschiedliche
Florian: Applikationen sind, deine Services, kannst du sie eben mit der Technologie umsetzen,
Florian: die für den jeweiligen Anwendungsfall am besten geeignet ist.
Florian: Weiß ich nicht, sowas wie Datenbankauswahl.
Florian: Du musst irgendwie eine Zeitreihenanalyse machen. Dann nimmst du halt für diese
Florian: Funktionalität, für diesen Microservice eine Datenbank, die dich genau darin unterstützt.
Florian: Und für alle anderen Microservices hast du vielleicht eine stinknormale,
Florian: relationale Datenbank, weil die da eben am besten funktioniert.
Florian: Oder auch Programmiersprache meinetwegen. Wird auch oft gesagt,
Florian: Java ist ja so unfassbar langsam, weil Garbage Collection und all diese Dinge.
Florian: Gut, dann implementierst du vielleicht halt einen Großteil deiner Software in Java, weil es okay.
Florian: Und vielleicht einen extrem performancekritischen Bestandteil,
Florian: den implementierst du dann vielleicht in einer Programmiersprache,
Florian: die eben deutlich effizienter ist.
Florian: Ich war mal bei Ericsson in Göteborg, die bauen testweise, haben die nie eingeführt,
Florian: aber die bauen zum Beispiel einen Prototypen
Florian: für die Telekommunikations-Backend-Infrastruktur, die sie betreiben in C.
Florian: Das sind C-Microservices, die da laufen.
Florian: Da hast du dann aber auch Leute, die entwickeln am Linux-Körnel mit.
Florian: Also die bringen diesen Hintergrund eben an der Stelle mit. Also das ist dann,
Florian: wie autonom sind meine Teams?
Florian: Und normalerweise sagt man, man lässt gewisse Freiheiten, aber du sagst jetzt
Florian: nicht sowas wie, jedes Team kann hier frei kommen, frei und wie es möchte sich
Florian: für irgendeine Technologie entscheiden, vollkommen egal, Hauptsache es funktioniert.
Florian: Das würde vielleicht in einer Welt klappen, in der du super Schnittstellen,
Florian: super abgestimmte Schnittstellen hast, jeder weiß, welche Ergebnisse er zu liefern
Florian: hat, auf welche Anfragen, ist vollkommen egal, wie es dahinter arbeitet,
Florian: alles ist super, alles ist toll und nur über diese Schnittstellen wird miteinander kommuniziert.
Florian: Die Schnittstellen sind stabil, vollkommen egal, wie die Software läuft dahinter
Florian: oder wie sie umgesetzt ist, alles ist super.
Florian: Du hast dann noch vielleicht ein API-Gateway hoffentlich dabei,
Florian: das auch noch super geil alles dokumentiert, wo ich eine super Übersicht habe,
Florian: aber in so einer Welt leben wir ja nicht.
Florian: Also in der Regel werden Schnittstellen, also wenn man sich das so anguckt,
Florian: gefühlsmäßig aus dem Bauch raus irgendwie definiert, so wie es einem gerade
Florian: einfällt und die müssen dann aber dann die nächsten fünf Jahre vielleicht leben
Florian: und dann habe ich ein Problem damit, wenn ich sie irgendwie evolvieren will.
Florian: Und all diese Dinge, also in einer optimalen Welt könnte man das alles so tun,
Florian: aber eine API-Gateway wird das Problem an der Stelle nicht lösen,
Florian: wenn eben die Kommunikationsstrukturen zwischen deinen Teams nicht auch schon
Florian: genau dieser Maßgabe folgen. Also das ist ja das, was du gerade sagtest mit Conways Law.
Florian: Kopie der Kommunikationsstrukturen zwischen meinen Teams in die Architektur
Florian: oder die Softwarearchitektur bildet genau diese Kommunikationsstrukturen,
Florian: diese Kommunikationshierarchien ab.
Florian: Und das willst du eigentlich bei Microservices haben, dass die Teams eigentlich
Florian: nur noch dann miteinander sprechen, wenn ihre Microservices miteinander betroffen sind.
Florian: Aber ein API-Gateway wird das Problem an der Stelle nicht lösen,
Florian: wenn die Schnittstellen überhaupt gar nicht klar sind und sowieso jedes Team
Florian: mit jedem anderen Team redet, wie es gerade Bock hat.
Florian: Also das ist Technologie geschmissen auf ein Organisationsproblem.
Florian: Das wird wahrscheinlich nie funktionieren.
Geek: Es kann sein, dass das aus der Komplexität herauskommt oder aus so einem bisschen
Geek: Siluisierungsgedanken.
Geek: Ich habe auch ein bisschen darüber nachgedacht, woran könnte man merken,
Geek: ob Leute Microservices machen oder ob sie Monolithen machen.
Geek: Ist es die Veränderungsgeschwindigkeit, ist es Skalierung? Also nicht in dem
Geek: Moment, wo ich einmal einen Button klicke, sondern generell.
Geek: Und mir kommt immer wieder mein Lieblings-Hass-Beispiel der deutschen Digitalisierung in den Kopf.
Geek: Ich bin Teil von diesem Deutsche Bahn Komfort, so heißt es. Ich habe einen Account.
Geek: Und ich habe mir irgendwann mal ein Zugticket kaufen wollen.
Geek: Du bist dann in diesem Portal und in dem Portal tippst du quasi ein,
Geek: welche Zugverbindung du gerne hättest.
Geek: Dann stellst du fest, wenn du es kaufen möchtest, hab vergessen mich anzumelden.
Geek: Dann stellst du fest, während du dich versuchst anzumelden, oh,
Geek: ich habe mein Passwort vergessen.
Geek: Machst ein Passwortreset in dem ganzen Ding. Dann ist natürlich alles verschwunden,
Geek: was du vorher dir an Sitzplatzreservierungen und allem zusammengesucht hast
Geek: und dieser Prozess ist nicht von vorne bis hinten durchdacht worden und das
Geek: ist so ein Phänomen, das sehe ich ganz oft bei gerade komplexer Software,
Geek: bei Leuten oder Unternehmen, die Dinge anbieten, die nicht eben in einem Schritt
Geek: taschenrechnerartig erledigbar sind.
Geek: Und dann hast du natürlich schnell das Problem dieser Silos,
Geek: die nicht über ihre Microservice-Grenze hinausdenken und das auch vielleicht
Geek: einmal so System-under-Test einmal komplett durchgehen mit allen Fällen,
Geek: sondern die sagen, ja, wenn ich folgende Daten kriege, dann funktioniert das auch.
Geek: Aber jetzt werden auf einmal Leute wichtig, die so einen Integrationssystem-Test
Geek: komplett vornehmen und die sagen, jetzt gucke ich mir das mal von vorne bis
Geek: hinten an, ich tue mal so, als wäre ich der Anwender.
Geek: Und dieses Bahnbeispiel ist ja noch das Einfachste. Also du sagst halt wirklich,
Geek: ich suche mir einen Zug aus, reserviere mir einen Platz und dann vergesse ich
Geek: halt mein Passwort, versuche mich anzumelden und dergleichen.
Geek: Und das kann ja noch viel, viel komplizierter sein, wenn du noch mehr Schritte
Geek: hast, wenn du Daten eingegeben hast, wenn ich bei irgendeinem Elster meine Steuererklärung
Geek: machen möchte oder dergleichen, wo dann noch Daten fehlen, die man dann noch irgendwo suchen muss.
Geek: Und das sind, glaube ich, Dinge, die auf der organisatorischen Ebene und auf
Geek: der Nutzererfahrungsebene deutlich schwieriger werden.
Geek: Und wenn wir darüber sprechen, zu sagen, mach mal eine gute Digitalisierungserfahrung,
Geek: dann ist zwar schön und gut, dass wir jetzt so ein Separation of Concerns hinbekommen
Geek: haben und gesagt haben, das kann auch alles schnell laufen, aber ich darf halt
Geek: auf gar keinen Fall aus den Augen verlieren,
Geek: wie spielt das denn jetzt zusammen, wie ist denn die Nutzererfahrung generell
Geek: und ich muss bestenfalls mit Metriken oder wenn ich sogar Leuten über die Schulter gucken kann,
Geek: prüfen, was machen die eigentlich damit und läuft das und wo bricht der Prozess
Geek: sozusagen, wo haben die Leute Schmerzen und das mögen nicht die Standardfälle
Geek: sein, weil die Standardfälle, die Heavy-Basis, die laufen in der Regel ziemlich gut durch.
Florian: Richtig. Also jetzt mal, ich weiß jetzt nicht, ob die Deutsche Bahn oder dieser
Florian: Teil der Deutschen Bahn, ob das Microservices sind oder nicht,
Florian: das weiß ich jetzt nicht.
Geek: In der Adresszeile steht immer Exe.
Florian: Ja, diese Query-Exe oder so, ja, stimmt, ja. Also es ist vielleicht ein Executable,
Florian: vielleicht ist es ein Monolith, das weiß ich nicht.
Florian: Aber du hast recht, wenn du sagst, dass, wenn wir jetzt Microservices einsetzen,
Florian: so Dinge wie Testing wird natürlich auch nochmal komplizierter.
Florian: Monolithen, also Integration-Testing an sich ist sowieso nicht einfach.
Florian: Happy-Cases-Testen ist immer super, aber genau das sollte man ja nicht tun.
Florian: Also jetzt unabhängig, was für eine Architektur ich habe, sondern sollte man auch tun.
Florian: Aber du solltest natürlich auch so Dinge testen wie, ich breche jetzt den Prozess
Florian: mal zwischendurch scheinbar ab, indem ich mein Passwort zurücksetze und dann
Florian: sind auf einmal alle meine Daten weg. Solche Dinge sollte man natürlich auch berücksichtigen.
Florian: Ist aber auch eher eine Frage im allgemeinen Testing-Bereich und weniger von
Florian: der Architektur abhängig.
Florian: Aber trotzdem werden so Integration-Tests bei Microservice-Architekturen schwieriger,
Florian: weil ich auf einmal mehrere Applikationen hochfahren muss.
Florian: Ich muss sicherstellen, dass die alle irgendwie in demselben Environment oder
Florian: selben State laufen, die Datenbanken vielleicht oder diese Outboxes,
Florian: Inboxes entsprechend gefüllt sind.
Florian: Muss Anfragen schicken und das muss ich alles zusätzlich sicherstellen.
Florian: Und dann hast du natürlich immer noch keine Aussage darüber,
Florian: wie verhält sich das denn jetzt auf einmal, mal, wenn ich das jetzt nicht auf
Florian: meiner lokalen Entwicklerkiste oder meinetwegen in unserem Staging-Node laufen haben,
Florian: sondern in der echten Welt, wenn da wirklich jetzt mal 5.000,
Florian: 10.000, 1.000.000 Benutzer drauf zugreifen. Das weißt du ja dann immer noch nicht.
Florian: Und deswegen gehen Unternehmen wie jetzt zum Beispiel Netflix,
Florian: die gehen dann eben her und testen teilweise Dinge in Produktion.
Florian: Also da werden Sachen zur Laufzeit abgeschossen und es wird geguckt,
Florian: wie sich das System verhält. So, das...
Geek: Genau, da bist du im Chaos-Engineering, wo du sagst... Das spielt Wir machen
Geek: uns sehr bewusst, dass wir Dinge kaputt machen, weil unser Anspruch ist,
Geek: da sind wir wieder bei den Architekturprinzipien, unser Anspruch ist,
Geek: dass wir eine robuste Plattform haben, die verträgt ist, wenn man mal gegen tritt. Richtig.
Geek: Und deswegen treten wir in Produktion dagegen, weil wir sind sehr,
Geek: sehr sicher, dass wir eine robuste Plattform auch tatsächlich haben. Genau.
Geek: Und das ist auch eine große Mentalitätsfrage, die jetzt auch mit den Services
Geek: nichts zu tun hat, aber wenn du halt viermal im Jahr dein Deployment machst oder 40 mal am Tag.
Geek: Richtig. Wie viel Risiko hast du dann pro Deployment, wenn du immer eine große
Geek: Gesamtmenge an Risiko hast?
Geek: Bei den 40 Mal am Tag vielleicht immer relativ wenig und wenn du dann relativ
Geek: schnell eben Rückmeldesysteme hast, die dir sagen, okay, da ist gerade was schief
Geek: gelaufen, dann kann man das machen oder Feature Flags und dergleichen und du
Geek: hast ja auch die Problematik mit, jetzt habe ich 17 Services,
Geek: die orchestriert werden,
Geek: die auch Breaking Changes mit sich bringen oder aber auch nochmal abwärtskompatibel sein müssen.
Geek: Die haben Versionen, die müssen also nicht nur eine Authentifizierung machen,
Geek: sondern die müssen auch von dem Service nebenan gefragt werden.
Geek: In welchem Format möchtest du eigentlich mit mir sprechen? Also ist es das Alte,
Geek: was vielleicht gerade noch online ist, weil Daten noch nicht komplett migriert
Geek: sind auf neue Formate, die ein Service braucht?
Geek: Ja. Oder ist es das Neue? Oder ist alles Lesen immer im alten Format und das
Geek: wird ins Neue geschrieben? Oder du hast erstmal redundante Daten?
Geek: Also hast du halt viele Abhängigkeiten, die dir zwar die Möglichkeit,
Geek: eben darüber gesprochen, von Skalierung und Unabhängigkeit und dergleichen geben,
Geek: aber du hast so viel mehr bewegliche Teile, auf die du aufpassen musst. Richtig.
Geek: Und sobald du ein Teil anfasst, es änderst und neu einbringst,
Geek: musst du halt Dependency Management machen und bei mehr als zwei Microservices,
Geek: sollten das keine Anfänger machen.
Florian: Ganz genau, richtig. Also vielleicht zwei Aspekte zu dem, was du gerade erzählt hast.
Florian: Einmal Stichwort hohe Release Zyklen, die kann ich mit Microservices erreichen,
Florian: weil ich habe kleine Funktionalitäten, die kann ich regelmäßig ausliefern.
Florian: In der Regel lassen sich die Services schnell starten. Ich habe schnell neuen
Florian: Code in der Produktion, deswegen spielt es auch ganz super gut mit diesem Agilitätsgedanken mit rein.
Florian: Das ist besser als jetzt bei einem Monolithen, wo ich vielleicht wie du gerade
Florian: gesagt hast, viermal im Jahr ist natürlich schon ein sehr krasses Beispiel,
Florian: aber der vielleicht extrem komplex zu deployen ist und wo es vielleicht auch
Florian: am Wochenende dauert, bis ich dann deployed habe, wo ich auch noch Dinge migrieren
Florian: muss, weil ich alles da natürlich migrieren muss, wenn ich Breaking Changes habe und diese Dinge.
Florian: Genau, da können Microservices auch deutlich besser sein und die andere Geschichte
Florian: mit welchen anderen Aspekt hattest du noch gerade?
Geek: Lass mich mal Pensionierung.
Florian: Abhängigkeiten, Betrieb, genau, da wollte ich drauf hinaus,
Florian: richtig, du hast viel mehr bewegliche Teile, sagtest du, genau,
Florian: die hast du auch und die müssen natürlich auch betrieben und administriert werden
Florian: und wir haben damals, als ich noch an der Uni war,
Florian: haben wir mal eine Studie gemacht und haben mal mit Unternehmen gesprochen und
Florian: haben die auch mal explizit gefragt, wo wir wussten, dass die Microservices machen,
Florian: wir sind in so eurer Erfahrung und witzigerweise kam da raus,
Florian: das riesengroße Problem, was die alle hatten, war jetzt nicht so irgendwie die
Florian: Microservices zu zerschneiden, oder Fachlichkeit zu zerschneiden,
Florian: weil wenn du dich irgendwo vertan hattest, dann konntest du halt sagen,
Florian: okay, müssen wir nochmal ein bisschen anders schneiden und nochmal umgestalten, das ist möglich.
Florian: Sondern die hatten ein Riesenproblem mit dem Betrieb. Also da war es dann nicht
Florian: so, wir haben jetzt den DevOps-Gedanken und dann haben wir hier irgendwie 100
Florian: Teams und in jedem Team ist ein Dev und ein Ops drin und dann ist das alles
Florian: cool, sondern da gab es die Dev-Teams,
Florian: so, die ihre Microservices gebaut haben und es gab ein zentralisiertes Ops-Team,
Florian: weil die gesagt haben, ey, das, was wir hier machen, Kubernetes
Florian: und all diese Dinge, das vernünftig, gescheit zu administrieren und zu betreiben,
Florian: ist so kompliziert, zumindest für diese Unternehmen, weil die auch in dem Bereich
Florian: die Kompetenzen einfach nicht hatten.
Florian: Das können wir gar nicht auslagern. Vor allem, wie viele Ops willst du dann
Florian: an der Stelle einstellen?
Florian: Deswegen hat man dann gesagt, okay, wir haben ein zentralisiertes Ops-Team,
Florian: die machen den ganzen Betrieb, alles, was irgendwie damit zu tun hat,
Florian: diese beweglichen Teile, von denen du gerade gesprochen hast,
Florian: und die Devs kümmern sich darum, Fachlichkeit in Microservices zu übersetzen.
Florian: Das haben wir bei, ich glaube, allen Unternehmen, mit denen wir gesprochen haben, gesehen.
Florian: Wir haben es alle genauso gemacht und für mich auch komplett nachvollziehbar,
Florian: weil es eben wichtig ist in dem Bereich und nicht einfach ist und eine zusätzliche
Florian: Komplexität, die ich mir auch reinhole. Das muss mir auch bewusst sein. Nein.
Florian: Das kann man natürlich sagen, so, ja, Cloud-Provider, der nimmt mir alles ab.
Florian: Aber es gibt ja auch Unternehmen, die machen ganz bewusst On-Prem.
Florian: Dann machst du das natürlich selber und dann nimmt dir der Cloud-Provider an
Florian: der Stelle mal gar nichts ab.
Florian: So, also das ist auch eine Komplexität, die man sich mit reinholt.
Florian: Das muss einem bewusst sein.
Geek: Wir haben jetzt sehr viel über individuell erstellter Software gesprochen.
Geek: Jetzt lass uns mal ein bisschen, lass uns das Ganze mal auf Cloud-Native ziehen.
Geek: Ja. Weil in Cloud-Native gibt ja einige Leute, die sagen, ich gehe jetzt in
Geek: die Cloud und meinen damit eigentlich Eigentlich nur, dass der Server nicht
Geek: mehr im Keller steht, sondern die benutzen jetzt den Server von Bill Gates und darauf läuft es jetzt.
Geek: Aber was das eigentliche bedeutet bei Cloud Native, wäre ja zu sagen,
Geek: du hast da Services, da ist ein S3-Bucket, wo du Daten abspeicherst oder du
Geek: hast vielleicht, da gibt es verschiedenste Services.
Geek: Ich habe mal so eine Emotion-Sensing-Funktionalität gesehen.
Geek: Du konntest ein Bild hinschicken von jemandem und dann hat in den Azure-Services,
Geek: gibt es dir zurück, ist der gerade fröhlich, glücklich oder traurig und wie
Geek: viele Jahre ist der alt und ist männlich oder weiblich.
Geek: Das ist halt ein Service, der einfach auch schon da ist.
Geek: Und die Frage wäre ja jetzt zu sagen, wenn du jetzt Microservices baust,
Geek: könntest du doch theoretisch einfach auch sagen, so ein bisschen was baue ich
Geek: mir, wo ich der Meinung bin, das gibt es noch nicht, aber ich baue einfach die
Geek: anderen Dinge ein, also von S3 Bucket angefangen bis hin zu Emotion Sensing usw.
Geek: Also ich sage, die nehme ich mir einfach aus dem Fundus von AWS,
Geek: GCP oder bei Azure und damit kann ich dann eben meine Entwicklung beschleunigen,
Geek: weil ich einfach dieses fertige Microservice-Stückchen sozusagen zu sagen,
Geek: schon einbaue in meine Wertschöpfungskette.
Florian: Absolut. Also das macht sowieso in dem Bereich Sinn, wenn ich eh Cloud-Native
Florian: unterwegs bin, dann auch möglichst viel von dem Cloud-Provider meines Vertrauens
Florian: zu nutzen, was es sowieso schon gibt. Absolut. Also das macht total Sinn.
Florian: Könnte ich bei einem Monolithen natürlich auch. Also ich könnte ja auch da sagen,
Florian: ich baue mir jetzt irgendwie eine Schnittstelle zu irgendeinem speziellen Dienst in meiner Cloud.
Florian: Aber das macht tendenziell auf jeden Fall Sinn. Sollte man auf jeden Fall tun,
Florian: wenn man denn sowieso Cloud-Native unterwegs sein will.
Florian: Bei Microservices sagt man sehr oft, dass die auch schon implizit,
Florian: so wie ich gerade sagte mit der horizontalen Skalierung, dass die implizit Cloud-Native sind.
Florian: Das stimmt meiner Meinung nach bis zu einem gewissen Teil, weil du eben bei
Florian: Microservices in der Regel virtualisierst.
Florian: Also das heißt, du packst es sowieso in den Container rein, weil alles andere
Florian: macht irgendwie wenig Sinn.
Florian: Zumindest wenn du auch so dinge wie in kubernetes nutzen willst autoscaling
Florian: all diese dinge dann virtualisiert er sowieso oder so du kannst die instanzen
Florian: schnell hochziehen all diese dinge.
Florian: Und deswegen sagt man sehr oft, dass Microservices an sich schon Cloud-Native
Florian: sind, weil dann nimmst du halt deinen Docker-Container und schmeißt den irgendwie
Florian: in den Cloud-Provider und alles ist gut.
Florian: Ist natürlich dann ein Nachteil, wenn ich sage, ja, ich nutze jetzt einen S3-Bucket
Florian: statt irgendeiner anderen Datenbank, die ich vorher mit Docker-Compose deployed
Florian: habe, dann muss ich natürlich auch Schnittstellen zu diesem S3-Bucket irgendwie schaffen.
Florian: Also das heißt, da ist die Welt jetzt auch nicht so rosig, wie man das gerne
Florian: hätte, aber diesem Service-Gedanken folgend, nachdem wie Cloud-Provider-Modelle
Florian: heutzutage aussehen, kann man da an der Stelle schon sagen, dass ein Microservice
Florian: tendenziell näher an der Cloud ist als ein Monolith,
Florian: aber ein Monolith kann ich genauso gut auch in der Cloud betreiben.
Florian: Also es schließt es jetzt nicht aus.
Florian: Vielleicht ist die Transformation ein bisschen schwieriger dahin.
Florian: Aber vielleicht habe ich auch mehr Kosten am Ende, weil ich die gesamte Software
Florian: da drin laufen lassen muss und nicht nur die Teile hochskaliere und bezahle
Florian: oder in höherem Maße bezahle, die wirklich relevant sind und andere eher nicht,
Florian: die nicht so oft genutzt werden.
Florian: Aber grundsätzlich sind Microservices schon näher an der Cloud dran,
Florian: aber ich kann auch andere Dinge in der Cloud laufen lassen.
Geek: Dann kommen wir zum Fazit.
Geek: Das Fazit Du hast ja über das ganze Thema promoviert. Was war das Fazit deiner
Geek: Promotion über Microservices? Was kam am Ende dabei raus?
Florian: Ich habe das ja mit einem Modellierungsaspekt noch, also modellgetriebene Softwareentwicklung
Florian: kennt vielleicht der ein oder andere, der so um die Jahrtausendwende war.
Florian: Das ist ein riesen Hype-Thema. In der Wissenschaft ist es heute an vielen Stellen
Florian: immer noch ein großes Thema.
Florian: Da kam im Endeffekt raus, dass Modellierung von Microservice-Architekturen eine
Florian: sinnvolle Sache sein kann, weil ich eben Dinge abstrahiere.
Florian: Die Architektur ist komplex, wenn ich sie in Modelle reingieße und sie erstmal
Florian: auf einer höheren Abstraktionsebene als jetzt Quellcode darstelle und vielleicht
Florian: auch Abstraktionsebene darüber. Das ist eine gute Idee.
Florian: Du kannst relativ viel von dem Quellcode, das war auch so ein Punkt,
Florian: ich habe mich auch mit Code-Generierung beschäftigt, relativ viel von dem Quellcode
Florian: bis auf die Fachlichkeitsimplementierung auch sehr gut generieren,
Florian: automatisiert erzeugen lassen, was damit zu tun hat, dass sowas wie ein Spring Boot zum Beispiel,
Florian: ein Framework ist, das du super für Microservice-Entwicklung verwenden kannst.
Florian: In anderen Bereichen wird es dann vielleicht eher schwieriger,
Florian: wo du so eine Framework-Unterstützung an der Stelle nicht hast.
Florian: Und Microservices haben auf jeden Fall ihre Daseinsberechtigung für viele Unternehmen
Florian: da draußen, aber für einen Großteil der Unternehmen eben auch nicht.
Florian: Und ich muss wirklich kritisch hinterfragen, brauche ich diesen Architekturansatz,
Florian: brauche ich diesen Architekturstil, ja oder nein? Und da muss ich mich auch ehrlich machen.
Florian: Also da kann ich jetzt nicht sagen, das ist jetzt ein Hype-Thema,
Florian: das machen jetzt gerade alle.
Florian: Netflix hat das auch gemacht, Deswegen muss ich das jetzt mit meinem 200-Mann-Mittelständler
Florian: jetzt vielleicht auch machen, weil die haben das jetzt auch gemacht.
Florian: Das ist der falsche Ansatz.
Geek: Was sind so die Top 2, 3 Dinge, wo du sagst, daran würde ich erkennen,
Geek: also das sind große Indikatoren für, sollte man Microservices machen?
Florian: Wenn meine Software wirklich extrem schlecht skaliert,
Florian: ich hohe Skalierung brauche, ich viele Anfragen, viele Benutzer habe und ich
Florian: definitiv festmachen kann, dass der Architekturstil, dass mein Monolith daran schuld ist,
Florian: dass ich nicht mehr skalieren kann, dann sollte ich in Richtung Microservices denken.
Florian: Denken, wenn die Wartbarkeit meiner Software extrem schlecht ist,
Florian: kann ich auch in Microservices denken, wobei dann würde ich auch eher erstmal
Florian: in Richtung Modulit denken.
Florian: Oder aber wenn ich eben sage, meine Kommunikationsstruktur, meine Organisation
Florian: ist sowieso schon Microservice-ready sozusagen, was wir gerade mit dem Conway's Law hatten.
Florian: Also wenn ich eh kleine Teams habe, klare Kommunikationsschnittstellen,
Florian: all diese Dinge, könnte man auch in Richtung Microservice-Architekturen denken.
Florian: Aber Skalierbarkeit ist in der Regel der größte Schmerz, der dazu führt,
Florian: dass man Microservice-Architekturen einsetzen möchte. Aber da sollte ich vorher messen.
Florian: Also da sollte ich vorher wirklich monitoren, gucken, woran liegt es jetzt,
Florian: dass meine Software vielleicht nicht mehr so performance-effizient ist, wie ich es gerne hätte.
Florian: Und selbst wenn ich dann die Entscheidung treffe, ich möchte von Monolithen
Florian: in Richtung Microservices gehen, gibt es auch verschiedene Ansätze, wie man das tut.
Florian: Ein sehr bekanntes Pattern in dem Bereich Strangler-Pattern,
Florian: das heißt, du machst keine Big-Bang-Migration,
Florian: das heißt, du löst nicht deinen Monolithen komplett von jetzt auf gleich in
Florian: Microservices auf, sondern du machst es Stück für Stück, nimmst eine Funktionalität
Florian: raus, kapselst sie in eine Microservice, baust eine Schnittstelle zwischen Monolith und Microservice.
Florian: Betreibst das Ganze dann mal, schaust es dir an, wie gut kommt man damit klar,
Florian: funktioniert es und nimmst dir dann die nächste Funktionalität vor,
Florian: vor die nächste, die nächste, die nächste, bis du irgendwann dann alles mal
Florian: deinen Monolithen sozusagen zersägt hast an der Stelle.
Florian: Was man da auch bewusst machen muss, Thema haben wir auch nicht drüber gesprochen,
Florian: aber Domain Driven Design ist ja auch immer sowas, was da auftaucht in dem,
Florian: Bereich, also Dinge schneiden, vor allem fachspezifisch schneiden und was ein
Florian: Trade-Off ist bei Microservice-Architekturen ist, du verzichtest an vielen Stellen
Florian: auf Wiederverwendbarkeit.
Florian: Das heißt, es kann durchaus passieren, dass du duplizierten Code hast oder duplizierte
Florian: Klassen hast in verschiedenen Microservices, die vielleicht anders ausgestaltet
Florian: sind Aber letztendlich dasselbe Konzept abbilden.
Florian: Das nimmt man aber dann in Kauf, weil du sagst, dadurch wird meine Kopplung,
Florian: die Abhängigkeit zwischen den Microservices eben geringer. Das muss einem auch klar sein.
Florian: Also Microservices optimieren eigentlich nicht in Richtung Wiederverwendbarkeit.
Florian: Das haben will, dann baue ich mir eine SOA, haben wir auch nicht drüber gesprochen,
Florian: so Enterprise Service Bus, die zwar auch um die Jahrtausendwende rum populär ist.
Florian: Wohl eher als heute. Aber ist auch ein Trade-Off, den ich da an der Stelle in Kauf nehmen muss.
Florian: Also Fazit wirklich, Skalierung, Wartbarkeit und vielleicht habe ich schon irgendwie
Florian: eine Organisationskultur, die eh dahin passt, dann kann ich mir da Gedanken drüber machen.
Florian: Aber auch nur, wenn ich wirklich weiß, dass der Monolith nicht schuld daran
Florian: ist. Oder schuld daran ist.
Geek: Das war ein Geek kommt selten allein. Vielen Dank fürs Zuhören und großen Dank an dich, Florian.
Florian: Vielen Dank, Stephan. Hat Spaß gemacht, hier zu sein.
Geek: Wenn unsere Hörer jetzt noch mehr von dir wissen wollen, wo finden sie dich im Netz?
Florian: Gerne auf LinkedIn. Auf LinkedIn anschreiben und dann kann man da gerne nochmal diskutieren.
Florian: Und ein Hinweis vielleicht noch an der Stelle, wer sich jetzt für Microservices
Florian: wirklich dediziert interessiert, es gibt so eine Initiative,
Florian: wo ich auch beteiligt bin, das Microservices Community.
Florian: Das ist so eine Non-Profit-Organisation, europaweit anfänglich stark wissenschaftsgetrieben,
Florian: mittlerweile sehr guter Mix aus Fachlichen, also Menschen aus der Fachlichkeit,
Florian: Menschen aus der Wissenschaft.
Florian: Einmal im Jahr findet so eine International Microservice-Konferenz statt,
Florian: auch aus Praktikern und Theoretikern, vielen Vorträgen und so.
Florian: Gerne mal vorbeischauen im Internet, www.microservices.community.
Florian: Und da findet man mich auch, kann mich auch gerne drüber anschreiben.
Geek: Wenn ihr noch Feedback zu dieser Folge habt, dann
Geek: könnt ihr es gerne unter www.eingeekkommseltenallein.de eintippen.
Geek: Macht es gut. Bis zur nächsten Folge. Wir hören uns.
Florian: Tschüss.