Skillbyte Podcast #35: Moderne Microservice Architekturen – Die Zukunft der Softwareentwicklung als Servicenetz

Willkommen zum Skillbyte-Podcast! Skillbyte ist Ihr Partner für digitale Exzellenz.
In diesem Podcast geht es um das Thema: Moderne Microservice Architekturen – Die Zukunft der Softwareentwicklung als Servicenetz
// Inhalt //
01:30 – Definition: Microservice Architekturen (Masiar)
04:07 – Exkurs: Enterprise Service Bus
05:03 – Definition: Microservice Architekturen (Maurice)
10:39 – Die Historie hinter dem Microservice Trend
13:29 – Flexibilität vs Komplexität
16:57 – Betrachtungen der Paradigmen Monolith vs Microservice
20:47 – Vorteile von Microservices
20:51 – Modularität
21:33 – flexible Integration
23:33 – Skalierbarkeit (Cloud native Paradigma)
25:30 – Verteilte Entwicklung / Best of Breed Ansatz
25:49 – mehr (API Schnittstellen-) Dokumentation
26:46 – Robustere Systeme
29:55 – Nachteile von Microservices
29:57 – Netzwerkkommunikationsoverhead entfällt beim Monolithen
31:15 – Höhere Komplexität
32:25 – HTTP-Protokoll (overhead, stateless)
33:43 – Microservice Beispiele aus der skillbyte Praxis
Abonnieren Sie diesen Podcast und besuchen Sie uns auf https://www.skillbyte.de
Feedback und Fragen gerne an podcast@skillbyte.de
AUTOMATISCH ERZEUGTES TRANSKRIPT
U es ist Magic. Es ist echt genau den Nagel auf den Kopf getroffen. Es ist kompliziert, wenn noch viel, viel interessantere Sachen möglich. Also nicht nur Fehler, sondern du kannst viele Dinge auch beeinflussen. Du kannst ein Quality of Service einführen, du kannst Security Auditing einführen. Es werden plötzlich viele Sachen möglich und zwar Deklaration. Da muss sich ein Entwickler nicht drum kümmern, sondern Administrator sagt wie dieser Network Verkehr, was damit passieren soll. Und das gilt dann für alle Microservices.
Es ist schon toll, wenn das einmal eingerichtet ist. Ja, kompliziert, aber es bietet extrem viel Einsicht in die Applikation.
Herzlich Willkommen zum Skillbyte Podcast Nr. 35 Moderne Microservices Architekturen Die Zukunft der Softwareentwicklung als Service Netz abonniert unseren Podcast für mehr spannende Themen rund um das Technologie Umfeld wenn er IT Entscheider oder IT-Fachkräfte seid, sendet uns gerne Hörer Fragen an Podcasts Skillbyte und lasst uns eine positive Bewertung freuen. Ist auch immer sehr, wenn ihr uns an Freunde und Kollegen weiterempfehlen. Ich bin heute hier mit dem Skillbyte Evergreen Masiar Masiar. Freut mich, dass du wieder dabei bist.
Hallo, grüß dich!
Ja, wir sprechen über Microservices Architekturen. Ein Thema, was ja bestimmt schon 10 Jahre lang durch die IT geistert und in den letzten 3 bis 5 Jahren richtig Fahrt aufgenommen hat. Eben durch die Container isierung. Sollen wir vielleicht erst mal sagen, was Microsoft, was Architektur ist bzw. was wir darunter verstehen?
Ja, gerne. Ich kann mal das sagen, was ich darunter verstehe. Also das ganze ist ja entstanden irgendwo in dieser Wolke Service orientierte Architekturen. Meistens hat dort ein Enterprise Service Bus eine Rolle gespielt und dieser Service Bus ist im Prinzip eine Messaging Infrastruktur, wo sich viele Applikationen connecten konnten, Daten abladen oder Daten abrufen konnten. Und dieser Service hat so ein paar zentrale Dienste zur Verfügung gestellt, wie zum Beispiel Quality of Service oder Logging, Auditing, Security und solche Dinge.
Und das Ganze basierte auf so biegsame Services, dass das mässige Protokoll war XML, was dort ausgetauscht wurde mit der Spezifikation, also, wie Sie aus dem Protokoll header, wie Sie der Body aus. Es gab noch ein paar Aufsätze Richtung Security und so weiter. Das Ganze war sehr over Blood. Das heißt, ähnlich wie damals auf Java Enterprise Architektur vorgestellt wurde mit EGB sehr kompliziert, sehr schwer zu konfigurieren, zu meistern, zu entwickeln. So war das auch bei diesen Services orientierten Architekturen und ähnlich wie damals in GB so ein bisschen mehr oder weniger abgelöst worden ist durch Spring, was jetzt de facto STANDARD ist, ist das gleiche auch ein bisschen diesen Enterprise Service Bus und orientierten Architekturen im alten Sinne geblüht, nämlich dass das abgelöst wurde durch etwas leichtgewichtigen ihre Protokolle und Dienste, nämlich den Microservices, wobei der Name Microservices eigentlich eher woanders drauf hin zielt, das im Prinzip nicht keine monolithische Architektur eine Applikation hat, dass das eine riesige Applikation, die egal was sich daran verändert habe, an kleinen Features immer als Ganzes liest werden sollte.
Und das ist eine sehr große, komplexes Gebilde. Deswegen haben viele Firmen auch sehr lange Release Zyklen, das heißt von bis zu einem Jahr. Das wird einmal pro Jahr released, weil es so viel getestet werden muss. Gecheckt werden muss, das jetzt meine Änderungen nichts dort kaputt macht, weil es unternehmens kritische Anwendungen sind. Und irgendwann hat man gesagt So, das ist eigentlich Mist was da passiert. Wir müssen diesen Monolithen in kleinere Einheiten zerlegen, in kleinere Services, die unabhängig sind, voneinander aber irgendwie miteinander kommunizieren müssen.
Und dann das ganze nicht per XML schwergewichtige jetziges Protokoll, sondern über Rest Architektur, das heißt eine API Backend, was Jason Format meistens zurückliefert. Und das ist das Protokoll der Kommunikation zwischen diesen ganzen Microservices. Also das ist, wie ich es definieren würde.
Ich denke, es ist wichtig noch mal kurz zu sagen, weil nicht alle Zuhörer vielleicht wissen, was ein Enterprise Service Bus ist. Das ist im Grunde eine Software Schnittstelle, die der Integration von vorhandenen Software Komponenten dient. Also man kann sich vorstellen, beispielsweise wenn man ein Medienhaus ist. Früher gab es das System, mit dem die Zeitung erstellt wurde oder mit dem die Artikel für die Zeitung geschrieben wurde. Später kam die Online-Welt hinzu und jetzt möchte man diese beiden Systeme miteinander verbinden, also Inhalte für die Zeitung vielleicht auch online stellen oder Online-Inhalte auch in die Zeitung bringen.
Also es kommt die Webseite zu, da kommt immer das iPad dazu, dann kommen weitere Apps hinzu, dann kommen Partner hinzu und alle müssen im Grunde auf diese Artikel Informationen zugreifen können. Und da kommt dann dieser Bus ins Spiel, dass man im Prinzip so eine Instanz hat, wo verschiedene Systeme, Artikel oder Themen abonnieren können und auch wieder abonnieren können und die eben sicher dann ausgeliefert werden. Ich glaube das ist noch wichtig. Zum Verständnis ich sehe eine Microservices Architektur im Grunde wie du als eine Variante einer Service orientierten Architektur.
Also ich habe mehrere Komponenten, die miteinander sprechen über ein Netzwerk. Eine Anwendung besteht aus mehreren lose gekoppelten Diensten, die zusammenarbeiten. Also wir waren jetzt gerade eben schon beim Medienunternehmen. Wenn ich jetzt eine Medien Webseite habe, dann habe ich vielleicht Dienste, die Wetterdaten zuliefern, Dienste die Ergebnisse zu liefern, Dienste die Aktienkurse zu liefern und ein Dienst, der meine Bezahlung abwickelt und so weiter. Das sind ja alles eigenständige Komponenten, die zusammen diese Nachrichtenseite ergeben. Oder die Inhalte, die.
Nachrichtenseite So, und die müssen irgendwie miteinander sprechen und so ein Dienst für Wetterdaten kann natürlich nicht nur für eine Nachrichtenseite benutzt werden, sondern auch für eine App oder für eine wissenschaftliche Analyse. Das ist mit lose gekoppelt gemeint. Sein Dienst stellt einfach Daten bereit, die in diversen Kontexten eingesetzt werden können. Und aus diesem Netzwerk, dieser Dienste jeder Dienst wäre dann sozusagen ein Microservices entsteht dann diese Microservices Architektur. Innerhalb der Dienste wird http gesprochen als Kommunikations Protokoll. Das hat sich einfach als STANDARD etabliert.
Oft ist es sinnvoll, nicht immer ist es sinnvoll, wenn State zum Beispiel eine Rolle spielt. Stößt das an Grenzen, weil man immer wieder Tokens hin und her übertragen muss, die Legitimation dann sozusagen ermöglichen? Ich glaube wichtig ist auch noch zu sagen Microservices sind kein fest geschriebener STANDARD. Es gibt nicht einen ISO STANDARD, wo man sagt Ja, wenn du dem Text, dann bist du ein Microservices oder hast du eine Microservices Architektur? Aber es ist mehr so ein Regelsatz, der sich über die Zeit etabliert hat.
Also Dienste, die über Netzwerk kommunizieren, meistens mit http und die eine hohe Kohäsion aufweisen. Also ein Dienst, der genau eine Sache macht, aber die dafür richtig E-Mail versandt Wetterdaten so was in der Richtung auch wichtig zu sagen ist. Du hast es schon angesprochen. Diese Systeme, die man integriert, die können natürlich unterschiedliche Technologien verwenden, auf unterschiedlichen Plattformen aufgesetzt werden, aus ganz unterschiedlichen Zeit Dekaden stammen. Und dennoch können die eben über HTTP miteinander sprechen, trotz dass sie aus unterschiedlichen Dekaden stammen.
Sie haben genau das halt auch ein bisschen was mit der Organisation von Teams zu tun. Die Idee war das Entkoppeln von Verantwortlichkeiten im System, das heißt ganzen Dienst schneiden, was sich um Kunden Stammdaten kümmert. Du kannst im Dienst anlegen, was sich um Order Daten kümmert und die Idee war, große Teams, die an so einem Monolithen gearbeitet haben, aufzuspalten in kleinere, agile Teams, die nur für dieses Projekt verantwortlich waren. Und diese können sich die Technologie, mit der sie das implementieren, quasi rein theoretisch frei aussuchen.
Ob das mit Java was weiß ich was gemacht ist, ist das völlig egal, weil das Kommunikation und Protokoll die HTTP ist ein Riesenvorteil. Genau.
Also nicht http das vielleicht auch, aber dass unterschiedliche Teams unterschiedliche Dienste entwickeln können in diesem Netzwerk.
Wir sind halt schneller und agiler und man die Entwicklung einfach parallelisiert. Du kannst halt diesen Best of Breed Ansatz dann benutzen. Also für eine Suchmaschine eignet sich vielleicht ein anderes Framework und eine andere Technologie als für eine Webseite und wiederum eine andere Technologie für ein Data Warehouse genannt zum Beispiel.
Genau. Also die ist werden unabhängig voneinander entwickelt und und da bist du jetzt vom Fach meistens mittels CCD, also automatisierter Build Prozesse dann ausgerollt im immer häufiger Container Umgebungen.
Genau um also auch hier ist wieder die Idee, dass wenn Services voneinander los gekoppelt sind, dann beeinflussen sie sich gegenseitig auch nicht. Wenn du so ein anderes Beispiel im Gegenbeispiel Wenn du früher irgendwas geändert hast an diesem Monolithen, musstest du die komplette Software testen, weil du im Prinzip eine neues Stück mit eingebaut hast und du konntest halt nicht absehen. Was betrifft das und muss es viele Tests haben musst du heute natürlich auch noch, aber du musst es die Software als Ganzes testen, wenn du das in Services ausgelagert hast.
Und solange man den Service Contract festschreibt und sich nichts ändert, also zum Beispiel Methoden, Signaturen, dann ist es einem Kundenservice egal, was dort auf der Vorderseite passiert. Hauptsache die Daten kann er in dem Format schicken und in dem Format erhalten, wie es vereinbart worden ist durch Interfaces oder Schnittstellen Spezifikation. Das macht die Sache natürlich viel agiler, weil du schneller und unabhängiger planen kannst, also Software quasi in Produktion bringen kannst. Du kannst dann plötzlich solche Çiçek Ketten von vorne bis hinten durchlaufen lassen, mehrmals am Tag und ein perfekter machen.
Diesen Microservices ist natürlich die Container und Klasse Technologie, die Kubernetes oder Open Shift, weil sie diese Agilität dann noch mal befeuert oder meines Erachtens sogar richtig gut ermöglicht haben. Was für mich den Microservices und Content Traumpaar absolut, weil durch die mehrfache Ausführung des Services und der Routing dieser Rest Calls oder der HTTP Calls zwischen den Diensten bekommst du natürlich auch eine Skalierung hin. Wenn du jetzt hunderte E-Mails schickst am Tag, kommst du vielleicht mit einem E-Mail Server hin. Wenn du mehr E-Mails schicken musst, weil dein Business wächst, dann brauchst du mehr E-Mails, Server oder mehr E-Mail Microservices, die das tun.
Ob das dann auf unterschiedlichen Servern ausgeführt wird, sei noch mal dahingestellt und kannst halt einfach mehrere gleiche Services hochfahren. In dieser Umgebung skalierbar.
Genau, genau. Und das ist natürlich ein Hammer. In der Flexibilität der Anwendungsentwicklung oder der Anwendungs Ausführung sollte ich hier. Entwicklungsgeschichtlich hast du ja schon gesagt, früher gab es diesen gigantischen Monolithen in der Java Welt, war das ein war oder ein Jahr viele 100 Megabyte groß. Man hat das einmal im Jahr released, da steckt natürlich auch ein Jahr Entwicklungsarbeit da drin. Das heißt das Risiko war immens. Plus dieser Klumpen hat alle Funktionen, die die Applikation beinhaltet hat, enthalten und einzelne Komponenten waren da nicht Testwahl.
Ganz klar, das will man heute nicht mehr. Ich glaube auch das ist dem geschuldet, weil die Technologie so weit ist mit Cluster, Technologien, Container, Technologien und b einfach auch viel mehr Software entwickelt wird und man verstanden hat. Software ändert sich schnell. Ich glaube in den Anfangsjahren der Softwareentwicklung oder sagen wir mal 70er 80er Jahre war es oft so, dass ein System neu entwickelt wurde, wo der Business Value ganz klar war. Man hat irgendwelche manuellen Prozesse abgelöst, die man kannte und hat gesagt Ja, wenn das automatisiert ist, dann spar mal Geld oder sind schneller.
Und heute wird die Software so als lebendes System verstanden, wie so ein Organismus, der sich in verschiedenen Bereichen weiterentwickelt. Und man weiß noch gar nicht so das Endziel, sondern durch diese agile Softwareentwicklung läuft man sozusagen alle zwei Wochen oder jeden Sprint dem Ziel ein bisschen näher, was sich dabei laufend ändert.
Das ist auch dem Geschäftsmodell geschuldet. Der Markt ändert sich sehr schnell und ist einfach ein Unternehmen in die Lage, schnell auch auf diese Marktveränderungen zu reagieren, indem er seine Software anpasst. Er kann plötzlich Tests ausführen und Kunden Feedback einholen. Das Helm mit dem Monolithen undenkbar.
Und viele Monolithen, das müssen wir auch noch sagen, laufen ja noch. Also wahrscheinlich die meiste Software, die nicht Endkunden bedient, ist noch irgendwo monolithisch angelegt und auch noch viele Endkunden. Software bei einem Monolithen. Der wird irgendwann so groß, dass die Testmarkt quasi überhaupt nicht mehr gegeben ist und man in diesem viel Glück Modus operiert. Also wirklich, man ändert etwas und hofft, dass das funktioniert. Aber das ist natürlich auch in manchen Geschäftsbereichen geht das. Aber irgendwo ist natürlich auch das Risiko so hoch.
Entwicklungsgeschichtlich ist es auch so, dass diese Monolithen eben sehr viel Spaghetti Code enthalten haben. Also da wird noch mal, bevor was in die Datenbank gespeichert wird, die Zeitzone überprüft und korrigiert. Währungs und Rechnungen werden durchgeführt, also die Kohäsion, das Zusammenfügen von Funktionen, die im Grunde eine größere Funktion gewährleisten sollen, wie eine Währungsumstellung, war sehr schlecht, weil die Funktion überall verteilt waren. Das ist bei den Microservices jetzt auch anders, wenn man die Zuständigkeiten besser dem jeweiligen Dienst zuschreiben kann.
Wobei man dazu sagen muss, dass es dann halt auch Aufgabe einer eine Software Architektur, die ich sage mal so einen Monolithen oder eine große komplexe Software auch in vernünftige Schnitte einteilen kann. Und auch zu entscheiden, wie tief gehe ich in der Granularität, weil es birgt auch natürlich Nachteile. Darf man auch nicht verschweigen. Wenn du viele einzelne Services hast, die miteinander kommunizieren, über unterschiedliche steuerbar und Grenzen hinweg, dann wird natürlich die Fehlersuche auch relativ komplex. Das heißt, wo guckst du denn jetzt nach?
Du weißt nicht, welcher Service wird welchen Fehler? Warum also das Tracken einer solchen? Man muss sich vorstellen, ein Request kommt rein, wird dann durch zig Microservices geschleust und wenn dort Fehler passieren oder noch nicht mal Fehler. Wenn ich im Nachhinein Kunde ruft, dann im Call Center und fragt, warum ich meine Order nicht durchgegangen. So, wo fängt sie an zu suchen? Das heißt ein richtiges Fehler. Tracking ist auch eine Herausforderung. Dann in solchen Microservices Infrastrukturen, wofür es über Lösungen geht.
Nur man muss diese Dinge auch bedenken und auch implementieren.
Ja, die System Komplexität steigt natürlich an. Das ist ganz wichtiger Punkt. Da wollte ich gleich bei den Vor und Nachteilen und den Nutzern Szenarien drauf eingehen. Aber du hast natürlich recht, die Funktion. Also nehmen wir mal einen Monolithen und ein Microservices Mesh, also ein Netz aus Services, die die gleichen Funktionalitäten bieten. Die Funktion muss ja irgendwo vorhanden sein, die ist vielleicht im Microservices Netz besser sichtbar, aber man hat natürlich viel mehr Kommunikations Schnittstellen in diesem Netz, die auch eine Bruchstelle darstellen können.
Die System Komplexität kriegt man dadurch nicht runter. Sie wird vielleicht einfach nur sichtbarer. Ich glaube das kann man schon festhalten. Auf der anderen Seite und da können wir als Entwickler ein Lied von singen, wenn du so einen Monolithen selber weiterentwickeln musst oder die Software eines Monolithen. Du hast einen extrem langsamen Programmstart. Auf deinem Entwicklungs Notebook ist es noch viel grausamer. Bis dieser Monolith hochgefahren ist, können mehrere Minuten vergehen. Du hast nur eine Programmier Umgebung und ein Ökosystem für alle Komponenten des Systems.
Also deshalb ist Java glaube ich auch so stark in dem Bereich, weil es eben sehr sehr viel angeboten wird in diesem Ökosystem, womit man sehr viel Funktionalität abdecken kann. Man kann aber natürlich nicht unbedingt diesen Best of Breed Ansatz nehmen, dass man für jedes Teil Problem suche Darstellung der Webseite interaktive Anzeige Elemente. Dass man da unterschiedliche Technologien nutzen kann oder es wird auf jeden Fall komplexer und bei Microservices ist es sozusagen mit eingebaut, dass man sich für jeden Service überlegen kann.
HTTP sprechen alle Technologien. Was passt denn super zu meinem Problem, was ich hier lösen möchte?
Auf der anderen Seite kann man natürlich argumentieren als Entwickler. Okay, wenn ich jetzt in einer Microservices Infrastruktur hab und möchte lokal arbeiten und die Backen und so was, muss ich alles lokal hochfahren. Welche Umgebung Parameter brauchen die alle? Das heißt, es ist sehr viel mehr zu organisieren und zu bedenken und du brauchst für die verschiedenen Systeme eventuell. Jeder hat irgendwie sein eigenes Dating Umgebung oder Integrations Umgebung. Dadurch, dass halt viel mehr Kommunikation im Spiel ist und natürlich auch relativ viel Aufwand.
Wenn du lokal entwickeln willst, dann musst du dir schon überlegen, ob ich pack mal die Microservices, die für mich relevant sind, mit denen ich kommunizieren muss. Die packe ich bei locker Campos irgendwie lokal zum starten dahin, oder? Da muss man sich auch was überlegen, wie man das halt löst.
Auf jeden Fall. Und wenn du 6 7 Docker Container lokal laufen hast, um dem Teilbereich des Services Meshes abzubilden, in dem du jetzt etwas debuggen möchtest oder in dem du etwas entwickeln möchtest, also auch die Kommunikations Stränge mitentwickeln möchtest. Das kann auch ganz schön den Lüfter zum Rauschen bringen. Auf jeden Fall. Jetzt haben wir schon einige Vor und Nachteile angesprochen. Ich würde da gerne noch mal durchgehen. Ich muss sagen, vielleicht so als persönlichen Schwank. Ich mag beides.
Also ich kann gut einen Monolithen weiterentwickeln, eben mit den jeweiligen Vor und Nachteilen. Ich kann aber auch gut mich in Microservices Landschaften bewegen. Es ist einfach ein unterschiedliches Spiel. Wie ist das bei dir?
Ich komme auch mit beidem zurecht. Ich sage mal, ich hatte mit dem Monolithen angefangen und ich habe diese Entwicklung dann auch miterlebt von SOA, also Service orientierte Architekturen hin zu Microservices. Ich muss sagen, beides hat seine Vor und Nachteile. Man kann nicht eine Technologie verteufeln und sagen Oh jetzt Microservices, schöne neue Welt und alles andere ist Schrott. Das einzige, was ich bei Microsoft wirklich extrem gut finde, ist diese Agilität. Dass du viel schneller sein kannst, dass du viel schneller planen kannst, Software in die Produktion bringen kannst, dass es halt mit dem Monolithen schwerer auch nur begrenzt.
Das Risiko so ein bisschen. Wenn du die eine Komponente nur tauscht, wenn du weißt, du hast das API stabil gehalten, dann ist das Risiko ja noch mal geringer da. Also nachteilig finde ich zum Beispiel bei der Microservices Architektur jedes Entwicklungsteam oder auch oft jeder Entwickler. Die kochen ihr eigenes Süppchen und dann kommt wieder dieser Wildwuchs rein. Der eine findet das Framework toll, der andere findet das Framework toll. Das ist ja auch gut, da Vielfalt mal zu testen.
Ich weiß nicht, ob das so bei Enterprise Anwendungen immer zweckdienlich ist, weil man sehr, sehr viel breiten Wissen dann braucht, um sich innerhalb diesem Service Netzwerk zu bewegen. Und am Ende stellt man ja eine große Anwendung bereit. Und es ist gar nicht für den Endkunden oder für das Management so ersichtlich, warum jetzt diese Komplexität entsteht. Auf der anderen Seite habe ich auch schon in Monolithen wahnsinnig krampfhafte Entwicklungen gesehen, weil einfach versucht wurde, mit der Monolith Technologie etwas umzusetzen, wofür das nie gedacht wurde.
Aber das wird halt dann angefordert und dann wird diese Technologie so hingebogen, bis die gewünschte Funktionalität herausspringt, wo man denkt okay, hätte man das in Service ausgelagert, da gibt es eine fertige Suchmaschine oder da gibt es ein fertiges Komponente dann nur per Konfiguration hätte das erfolgen können, so musst du sehr viel selber geschrieben werden und es ist auch noch von zweifelhafter Qualität. Lass es mich mal so formulieren Ja, das muss ich auch sagen. Microservices bedeutet kein ungleich viel Wiese für Entwickler, die jedes Framework einführen können und machen können was sie wollen.
Ich meine, ich habe es oft genug gesehen, solche Microservices, die sowas von überladen, von teilweise gleichen Frameworks, die dann gleiche gemacht haben, überlagert waren und es hat noch keiner mehr durchblickt. Wenn es dann auch eine Fluktuation gibt und Entwickler verlassen das Team und andere kommen dazu, es findet sich keiner mehr zurecht. Microsoft ist keine Spielwiese für Entwickler, kann ich nur betonen.
Man braucht auch einen Architekten, weil sonst kommt irgendjemand und sagt Na, das hat er in der Sprache gemacht. Das finde ich aber doof und ich möchte das jetzt ausprobieren und dann wird das neu gemacht, obwohl das gar nicht notwendig wäre. Was ich als Riesenvorteil beim Microservices Netzen sehe, ist die Abschaffung von Komponenten. Also wenn man sagt okay, den Teil brauchen wir nicht mehr, dann kann man diesen Service abschaffen und dann ist er da raus. Und beim Monolithen, da traut sich keiner so richtig ran.
Weißte, der Code bleibt da drin, keiner weiß. Wird das noch benutzt, wird das nicht mehr benutzt. Ich fasse es mal nicht an und geht da drüber weg. So, und dieses Ding zieht immer mehr Speck auf die Hüften und keiner weiß mehr, was noch verwendet wird und was nicht mehr verwendet wird. Das finde ich bei einem Service viel einfacher, weil da könnte man im Prinzip nur protokollieren, wie viel Traffic hat dieser und jener Service und sobald er nicht mehr angesprochen wird, wird er einfach abgeschaltet.
Und beim Monolithen lebt so was ewig und Abschaltung von Komponenten. Meiner Ansicht nach eines der Schlüsselthemen, die man behandeln muss, wenn man ein System Komplexität handhabbar haben möchte oder nicht ausufern lassen möchte. Genau. Also Vorteile haben wir schon viele jetzt angesprochene Monolithen. Wir brechen die großen Monolithen in Einzelkomponenten runter, die miteinander kommunizieren. Das macht den Wright einfacher von eben diesen einzelnen Komponenten und auch das technologische Fortschreiten macht es einfacher. Man könnte ja eine Komponente, die ich sage mal in den 90er-Jahren nur such Komponente, die mit C implementiert wurde, die lange treu gedient hat, die jetzt aber modernisiert werden soll.
Aus irgendeinem Grund. Die könnte man dann ja in einem zeitgemäßen, meinetwegen auch in C, aber mit einem zeitgemäßen Framework dann eben neu schreiben. Das wäre bei Monolithen nicht so einfach möglich. Dadurch kann man diese einzelnen Komponenten, diese Punkte auf der Landkarte eben upgraden. Was ich auch als super Vorteil der Microsoft Architektur ansehe, ist die fließende Integration von Legacy Systemen, dass eben das Beispiel mit dem Enterprise Service Bus gebracht. Man kann natürlich Legacy Systeme Monolithen behalten, diese um die HTTP Konnektivität ergänzen und dann neue Services daneben aufbauen, sodass auch der Monolith nach und nach oder die neuen Komponenten, die normalerweise in den Monolithen eingeflossen wären, würden dann nach und nach an einzelne Services ausgegliedert wird.
Genau das ist die Frage Wie geht man denn jetzt mit so einer Monolithen um? Wenn man schon bestehende Software hat und möchte, dass in Microservices zerlegen möglichst viele verschiedene Strategien. Aber die beste ist tatsächlich, sich die Software mal anzugucken, mit kleineren, einfacheren Funktionalitäten anzufangen, um einfach ein Gefühl dafür zu kriegen. Wie das funktioniert, ist die Latenz, wenn ich plötzlich die Software nicht mehr in einem Prozess habe, sondern Prozess übergreifend und Rechner übergreifend kommunizieren muss. Das sind Erfahrungswerte, die ich auch erst mal sammeln muss.
Also ich habe einen Kunden Projekt, das ist genau so ein Fall Monolith entwickelt worden. Vor 20 Jahren hat es begonnen und es wird eine Frontend Technologie eingesetzt, die damals total hipp war Adobe Flash und die stirbt dieses Jahr bzw. läuft aus dem Support aus und jetzt würde das ganze Frontend diese Anwendung nicht mehr funktionieren bzw. wenn das Flash Plaketten im Weg ist, besitzt diese Anwendung keine Anzeige mehr. So und da gibt es verschiedene Upgrade Pfade wie man sagt. Okay, die Kernel Logik funktioniert soweit eigentlich.
Da haben wir auch 20 Jahre super mitgearbeitet, aber wir müssen eine andere Anzeige Technologie verwenden. Flash war 2000 super. Mittlerweile ist es nicht mehr. Ist schon eine ganze Zeit nicht mehr so, wir müssen zumindest die Anzeige Komponente neu entwickeln lassen und das kann dann so gemacht werden, dass man die Anzeige, die ja noch in dem Monolithen drin ist, die Anzeigepflicht wird irgendwann nicht mehr verwendet werden oder jetzt bald nicht mehr verwendet werden und die Systeme oder die Daten werden dann in andere Systeme abgezogen.
Das Thema Skalierbarkeit hat man schon angesprochen. Man kann. Wenn ein Microservices existiert, kann man in ein 3 5 28. mal starten und so lasst Spitzen abfangen oder auch Ausfallsicherheit gewährleisten. Wenn immer 3 Dienste laufen oder 2 Dienste laufen, ist man sicher vor Ausfällen geschützt.
Ja, wobei theoretisch auf jeden Fall völlig richtig. Nur muss man bei der Entwicklung natürlich ein paar Dinge beachten. Gerade wenn du Richtung Container und Cloud entwickelst, dann gibt es das Konzept eines sogenannten Cloud-native. Das bedeutet Wie entwickelst du Software? Und zwar für die Cloud? Also nicht ich entwickle Software, damit sie erst mal lokal läuft und ich guck mal, wie sie in die Cloud kommt. Nein, Cloud first. Das heißt, du musst gewisse Dinge beachten, wie zum Beispiel Ein Container in der Cloud ist in einer sehr volatilen Umgebung, was bedeutet, Instanzen können von jetzt auf gleich sterben.
Und Kubernetes zum Beispiel sorgt dafür, dass der Container woanders hochgefahren wird und wieder gestartet ist. Damit das aber funktioniert, darf bei der Applikation halt kein State mitführen. Es gibt ein paar Prinzipien, die sind in so einem so eine Art Manifest festgehalten die 12 App, also 12 Faktoren App. Und da haben wir auch eine Podcast Episode, die man sich anhören sollte. Und die sorgt dafür, dass die Best Practices für Software, die in dieser Umwelt funktionieren soll.
Es ist also schon ein Paradigmenwechsel auch für Entwickler und es ist strategisch. Muss ein Unternehmen dafür sorgen, dass die Entwickler sich auch theoretisch diesen Themen annehmen und verstehen, was da passiert.
Man bekommt das nicht geschenkt, dass man sagt Okay, früher haben wir Monolithen entwickelt, aber machen wir jetzt mal Microsoft Architektur, sondern man muss sich schon damit beschäftigen. Und meiner Ansicht nach, je mehr du dich damit beschäftigst und desto eher du deine Anwendung dann cloud-native implementiert oder dich an diese zwölf Faktoren hältst, desto mehr profitierst du auch von den Benefits, die die Microservices bieten. Ein weiterer Vorteil da sind wir schon drauf eingegangen ist die verteilte Entwicklung und der Best of Breed Ansatz.
So unterschiedliche Teams können unterschiedliche Teile entwickeln, meiner Ansicht nach. Mit der größte Vorteil, weil man einfach nicht nur die Ausführung skaliert der Software, sondern auch die Entwicklung skalieren kann. Implizit ist mir auch aufgefallen, dass bei Microservices mehr Dokumentation abfällt, einfach weil jeder Microservices eine Schnittstelle bereitstellt oder auch Aufrufe von anderen Schnittstellen durchführt. Muss es irgendwo dokumentiert sein? Ja, welche Optionen gibt es denn? Welche Funktion bietet dann Microsoft an? Was kann ich denn bei dir abrufen?
Und fehlt da noch was? Müssen wir noch eine Schnittstelle erweitern? Und wie sieht das denn aus? Also diese Dokumentation, die sich aus der Notwendigkeit ergibt, die Schnittstelle zu beschreiben, einfach damit man in dieses Service Mesh integriert werden kann, halte ich auch für einen großen Vorteil. Da gibt es auch richtig coole Technologien. In meinem aktuellen Projekt wird Open API eingesetzt. Da kann man eine Jamil Datei. In einer Jamel Datei beschreibt man eine Rest API und kann dann mit einem Generator Script automatisch das Backend generieren für die API und auch automatisch die Frontend Entities dafür supercool.
Man muss nur die Jamil Datei anpassen, macht den Reiz und hat alle Änderungen sowohl im Backend auch im Frontend nachgezogen. Und einen weiteren Vorteil von Microservices Architekturen sehe ich darin, dass man generell ein robustes System enthält, weil man jetzt eben mehrere Dienste hat, die alle einzeln ausfallen können. Zugegebenermaßen. Aber bei einem Monolithen ist es ja doch so, dass der der große Database Error die ganze Anwendung blockiert.
Ja, wobei du dann natürlich auch wiederum überlegen musst, wenn so ein Dienst wie eine Datenbank Abfrage fehlschlägt, dann hast du in der Kette verschiedene Microservices Aufrufe, die am Ende Daten brauchen und der stockt jetzt. Was passiert denn mit den vorgelagerten Diensten? Wer schmeißt welchen Fehler und was kommuniziere ich entweder nach vorne? Das heißt, dieses Fehler Tracking wird unsichtbarer oder verworrener zu finden, aber dafür gibt es Lösungen. Du erwähnst das Wort Service Mesh. Da gibt es zum Beispiel ein Produkt für Kubernetes europäisches Umfeld.
Das nennt sich ISTIN oder Lika. Die oder kommen gibt es verschiedene Produkte und die bieten solche Lösungen für Sichtbarkeit. Tracking. Das heißt, ich kann sehen, welcher Microservices ruft, welchen auch. Wie lange hat er gebraucht, wenn Request und Response. Das heißt, ich kann diese Dinge nach vorne holen und sichtbar machen, wo es gerade hapert und kann darauf reagieren.
Aber man muss. Es ist aufwändiger, es ist aufwendiger, wird komplizierter.
Aber ich könnte mir vorstellen, wenn die Tools nicht, aber wenn die einmal auch eine gewisse Reife erreicht haben, dann sieht man bestimmt auch die einzelnen Nachrichten, wie die sich durch dieses Mesh bewegen und wo es zu einem Fehler kommt und wie dann die Fehler Routen angezeigt werden können oder so, dass man wo es ist Magic. Es ist echt genau den Nagel auf den Kopf getroffen. Es ist kompliziert.
Also ich sehe so ein visuelles Bild vor mir, wo ich sehe oh, da gibt es ein Problem.
Und dann ja, es wäre noch viel viel interessantere Sachen möglich. Also nicht nur Fehler, sondern du kannst viele Dinge auch beeinflussen. Also kannst du Quality of Service einführen. Du kannst Security Auditing einführen, es werden plötzlich viele Sachen möglich und zwar Deklaration. Da muss ich den Entwickler nicht drum kümmern, sondern Administrator sagt wie dieser Netzwerk Verkehr, was damit passieren soll. Und das gilt dann für alle Microservices. Es ist schon toll, wenn das einmal eingerichtet ist.
Ja, kompliziert, aber es bietet extrem viel Einsicht in die Applikation.
Man hat sie richtig im Griff oder hat die einzelnen Microservices richtig im Griff und sieht die Kommunikation zwischen ihnen.
Auch wenn du gerade so komplexe Systeme hast und hast nicht geschäftliche Applikation und möchtest zum Beispiel testen, was passiert denn, wenn Dienst A, B, C ausfällt in D und der Reihenfolge, dann gibt es das Konzept des Chaos Engineering. Da gibt es auch Produkte, für die in so einem Cluster, die bloed, einfach wild kreuz und quer Dienste abschiessen, Netzwerk Verkehr kappen, einfach per Zufall Chaostheorie, dass du dann einfach deine Applikation Härte testen kannst und sehen was passiert denn, wenn wirklich mal so ein Cluster den Geist aufgibt oder Teile davon?
Da die großen Unternehmen die auf 24 7 Betrieb angewiesen sind, die investieren da sehr viel Herzblut um da diese Tests machen zu können, muss man natürlich immer gucken, wie weit das dann auch für die eigene Anwendung passt. Aber ja, im Prinzip ist das alles möglich. Lass uns zu den Nachteilen kommen. Der Monolith ist natürlich hart verklumpt, hat aber dafür dann kurze Response Seiten. Dadurch, dass man einfach kein Netzwerk Round Trip hat und im Grunde nur ein ja wie kann man sagen Memory Round Trip von der einen in die anderen Funktionen.
Und man kann sich jetzt vorstellen, bei zwei, drei Funktionen macht das vielleicht noch nicht so den Unterschied. Wenn aber 20 30 Schritte komplexere Schritte, wo auch vielleicht große Daten, große Listen zum Beispiel ausgetauscht werden müssen, sieht man das im Netzwerk, wenn da diese großen Datenmengen ausgetauscht werden. Und da kann der Monolith Geschwindigkeits mäßig natürlich deutlich nach vorne preschen. Auch bei Microservices Architekturen hat man häufig den Fall, dass Dienste mehrfach geholt werden müssen von unterschiedlichen Services.
Also man kann sich. Prozess vorstellen, dann sagt der Warenkorb Service so, das wurde jetzt bestellt. Dann sagt der Rechnung Service alles klar. Dann muss ich eine Rechnung erstellen über den Betrag. Und wie ist denn der Käufer? Gib mir mal die Adresse von dem Käufer. Aber es gibt auch den Postversand Service. Der druckt halt dann das Etikett was bestellt wurde. Er sagt auch wie ist denn die Adresse von dem Käufer, damit ich die Adresse von dem Käufer da raus drucken kann auf das Etikett usw.
. Innerhalb dieser Ketten. Du weißt, was ich meine, wenn Daten einfach öfter abgeholt, sodass man durch diese bessere Trennung der Zuständigkeiten natürlich auch Redundanzen schafft. Bei der Datenübertragung ganz klar. Der größte Nachteil meiner Ansicht nach, den hast du aber jetzt auch schon drei Mal angesprochen, ist die höhere Komplexität bzw. du nennst es Tracing. Also Du hast ein Problem und möchtest wissen, wo kommt dieses Problem genau her? Welche Nachrichten crashen wo? Wo entsteht welches Problem?
Und das blubbert ja dann zurück. Also sagen wir mal, jetzt sagt der bestellt Server. Ist ja im Moment mal, das Konto von dem Besteller ist gar nicht gedeckt. Dann sagt der bestellt Server ist im Warenkorb Service do kann ich nicht bestellen und dem Post Paket Druck Service du druck das noch nicht, weil der kann das gar nicht bezahlen usw.. Innerhalb dieses Netzwerk ist das jetzt ein sehr einfacher Prozess, wenn sehr viele Nachrichten ausgetauscht und dies dann nachzuverfolgen gibt.
Und im Fehlerfall muss man das natürlich mit eigene Gehirnleistung nachvollziehen, damit man diesen Fehlerfall dann eben ausgleichen kann oder beheben kann. Zusätzlich hat man diese ganze Komplexität, also Netzwerk, Latenz, Nachrichten, Formate laut Balancing wie habe ich hier skaliert funktioniert das alles. Und wenn ich jetzt noch mehrere Technologien einsetze in den einzelnen Microservices, also einen Vorteil, den wir eben extra genannt haben, dann wird es natürlich noch komplexer. Dann braucht man schon sehr viel Expertenwissen, um hier überhaupt ein normales Debugging durchzuführen.
Exakt genau das Debugging.
Dann wollte ich dich noch fragen. Also ein Nachteil ist gegebenenfalls noch das http Protokoll, weil es ja Stadlers ist, das haben wir eingangs schon besprochen, müssen wir immer irgendwelche Token hin und her schicken? Ist dir eine Microsoft Architektur bekannt, wo nicht http gesprochen wird? Mir ist noch keine weggelaufen.
Naja, das hängt vermutlich damit zusammen, dass wir halt auch gerade im Web, Umfeld usw. unterwegs sind. Es gibt natürlich auch Microservices, die andere Protokolle sprechen. Ich denke allein an Go to go Services, dass die mit GbR, PC oder und anderen Protokollen, Shadow oder Proto Bash usw.. Also es gibt sie schon, aber das meiste ist natürlich http völlig klar.
Ist ja unglaublich, dass sich dieser alte STANDARD so lange hält und auch noch in einer so modernen Technologie weiterlebt und in 99 prozent der Fälle benutzt wird.
Es ist auf jeden Fall sehr spannend. Es entsteht täglich irgendwas neues. Also letztens hat es mir noch diesen Link geschickt von diesem Microservices Framework, also wie du APIs definierst und generiert. Dann hat mir ein anderer Kollege von Quarks berichtet Quarks und Gral VM, der eine JVM Kubernetes für Kubernetes, was innerhalb von von Millisekunden startet, weil es nativ kompiliert wird. Also es bewegt sich extrem viel. Ich finde das so spannend. Ich liebe es ist es auch, was ein Nachteil ist, aber natürlich auch irgendwie ein Vorteil.
Oder man lernt dadurch ist natürlich die Komplexität wird größer. Ich würde auch sagen, wenn du heute eine neue Anwendung entwickeln würdest Masiar, würdest du doch wahrscheinlich direkt zu einer Microservices Architektur gehen, oder?
Ja, würde ich, würde ich definitiv einfach um diese Faktoren der cloud-native Entwicklung den Rechnung tragen zu können, um dann eben auch die Vorteile der Laufzeit Umgebungen der Cloud, Laufzeit, Umgebung, Kubernetes, Cluster oder im Grunde sind das die beiden Großen, dass man die eben nutzen kann und da tun sich ja Monolithen sehr schwer, wenn man die da rein zwängen möchte.
Ja, man darf es nicht übertreiben. Es ist meine Meinung. Das Beispiel Gravity CW Wir haben das zerlegt in den Frontend Application. Klar die Application wie das Webserie und das Becken, wo man die Sachen eingeben kann. Wir haben ein Baby Backend, was nicht weiter zergliedert ist. Wir haben ein Billing Backend. Wir haben für den Civic Generator ein eigenes Backend und das wars. Und wir haben noch ein paar Maintenance Konsolen Becken wo ein wobei Jobs laufen und das wars, weil ist klar, je weiter das degli das kleiner macht, umso intensiver wird natürlich auch die Wartung drum herum.
Das Auto muss ja schon sehr genau Gedanken machen und strukturieren. Wer macht was? Wie kann ich was in welcher Reihenfolge die? Das macht es ein bisschen kompliziert. Bei mir war die Ebene und das funktioniert sehr gut und wenn ich Fehler Probleme habe, kann ich fünfmal am Tag die Polen mit Kubernetes und keiner bekommt mit, dass da eine neue Version ist. Hab ich letztens noch mit dem Kollegen geschwärmt. Immer wieder, egal wie oft die Shantanu sie. Trotzdem fasziniert mich das, wie oft man dann plötzlich einfach die Diplomen kann.
Es ist Wahnsinn, macht einfach nur Spaß da und so 5 6 kleine Services und das reicht schon um. Ist ja schon eine moderne und auch eine größere Webanwendung, um von den Vorteilen zu profitieren. Also dass man eben diese unsichtbaren, für Endkunden unsichtbaren Deployment machen kann. Ich weiß, du hattest mir gesagt, ein Kunde hat angerufen, hat ein Bug gemeldet, der. Sofort behoben und eine Stunde später hat er auf der Webseite gesehen Ja, Moment mal, das Problem ist ja behoben und hatte ich dann wiederum angerufen und gemeint, so schnell hätte er noch nie produktiv Bugfix gesehen.
Ja, ja, genau. Mehrmals. Dreimal schon. Und das bestätigt ein, dass du die richtige Architektur gewählt hast. Und diesen Geist, diesen Vorteile versuche ich dann auch bei meinen eigenen Kunden Projekten zu vermitteln und denen auch mal diese Beispiele aufzuzeigen. Was das bedeutet, dass so viele wahrscheinlich noch unvorstellbar, dass man quasi von Anmeldung bis fix plus produktiv nur eine Stunde vergeht. Aber es ist möglich, wenn man konsequent auf neue Technologien setzt, natürlich auch mit diesen umzugehen weiß.
Das müssen wir immer sagen. Es ist kein Selbstläufer. Man muss sich immer damit beschäftigen und sich weiterbilden. Dann kann man aber davon profitieren. Auf jeden Fall. Und ich denke, die meisten Anwendungen, die in Unternehmen laufen, die bewegen sich ja auch in dem Rahmen, dass man die mit 5 6 Diensten betreiben kann. Vielleicht sind es mal 10, aber ich bin da auch so wie du, dass man so einen pragmatischen Ansatz finden muss, dass man nicht jede Funktion in den eigenen Dienst ausgegliedert.
Aber wenn man eine größere Komponente implementiert, wie das Billing, wie das Generieren von CVS, die auch tendenziell sehr viel Last verursachen können abseits des normalen Systems, dann macht es natürlich Sinn, mit Blick auf Skalierung oder auch Erweiterbarkeit das in einem eigenen Dienst zu realisieren.
Ich musste gerade ein bisschen schmunzeln, wenn ich so irgendwo bin bei einem Kunden, der ein bisschen mit dieser Technologie noch nicht so viel zu tun hatte und bekommen dann mit, wieso Admins und Techniker über gewisse Punkte sprechen, wie sie das disziplinieren sollen, sodass sie es testen sollen, wie sie das jetzt auch liefern sollen. Und ich denke, weil ich ja die andere Seite kenne. Ich könnte dir nur sehen, was ich sehe. Man muss ja ein bisschen aufpassen.
Du kannst du nicht mit der Tür ins Haus fallen und sagen Oh ja, alles toll, die schmeißen alles um. Klar, die haben eine Investition in Software, das müssen sie auch mental weiterentwickeln. Man hat halt wenig Zeit, sich um neue Dinge Gedanken zu machen, aber mit dem alten noch so beschäftigt ist und man schaut so innerlich mit den Hufen sagen Kommt, ihr müsst das machen, das löst all eure Probleme. Worüber wir jetzt reden, gehören der Vergangenheit an.
Und da muss ich immer bremsen und auch diplomatisch vorzugehen und das langsam voran zu tragen, weil man auch ein bisschen Rücksicht nehmen muss auf die Umgebung.
Das ist ja natürlich. Du arbeitest ja auch mit Menschen zusammen und die Menschen müssen sich in die neue Thematik einarbeiten. Die haben die alten Systeme, die haben da vielleicht ein großes Team, die haben Dienstpläne, da ist das alles eingeteilt, die wissen, wie man damit umgeht. Und die müssen ja das neue Produkt oder das neue Paradigma so nach und nach beschnuppern, dem Vertrauen. Und dann muss das ein gleitender Übergang durchgeführt werden. Ich glaube, so kann man es schaffen.
Aber ja, das ist natürlich zeitintensiv und auch bedingt einige Mühen, dass man da immer dran bleibt, aber dennoch Microsoft Meshes Service Meshes gehört die Zukunft, würde ich sagen.
Ich sehe das auch so auf mittlere Sicht, wenn unsere zu erfragen haben oder Feedback zur Podcast Episode könnt jetzt gerne eine E-Mail schicken an Podcast Skillbyte Lass uns gerne ein Abo da und eine 5 Sterne Bewertung und empfehle den Podcast weiter an Freunde und Kollegen ebenfalls aus dem IT-Bereich für mehr spannende Technologie Themen könnte auch auf Skillbyte Slash Blog vorbeischauen. Masiar Es war wie immer eine Freude mit dir zu sprechen. Vielen Dank!
Vielen Dank auch dir Maurice.