Die Umwandlung eines großen, monolithischen Altsystems in ein modernes, verteiltes Microservice-System ist komplex und anspruchsvoll. Bevor die ersten Schritte unternommen werden, sollten die Ziele für eine solche Aufgabe gut durchdacht, explizit definiert und mit allen Entscheidungsträgern diskutiert werden. Entscheidende Fragen, die es zu klären gilt, sind zum Beispiel:
- Geht es darum, schneller auf unterschiedliche Lastszenarien zu reagieren?
- Geht es um eine schnellere Implementierung und Bereitstellung neuer Funktionen, da die Koordination eines größeren Entwicklungsteams schwierig und zeitaufwändig ist?
- Geht es darum, die Ausfallsicherheit zu verbessern, oder ist die Skalierung aufgrund des hohen Ressourcenbedarfs des Monolithen zu teuer?
- Werden in dem Monolithen veraltete Technologien oder Bibliotheken verwendet, die schwer zu ersetzen sind, aber der Sicherheitsabteilung Sorgen bereiten?
Die Ziele sind entscheidend für den Transformationsprozess und dienen als Leitlinien für eine neue Architektur. Sobald sie klar definiert sind, besteht der nächste Schritt darin, ein vollständiges Verständnis über die Funktionalität des Monolithen zu erlangen. In der Regel sind große, monolithische Systeme über einen langen Zeitraum gewachsen, und es gibt möglicherweise tote Codepfade, weil sich die Anforderungen im Laufe der Zeit geändert haben. Ein wichtiger Punkt ist daher die Identifizierung der genutzten und wesentlichen Funktionen und die Skizzierung eines High-Level-Geschäftsmodells anhand des Codes. Außerdem sollten Sie jedem Geschäftsmerkmal und dessen zugehörigem Code einen geschäftlichen Wert zuordnen, um Migrationskosten und Nutzen gegeneinander abwägen zu können. Lohnt es sich, eine bestimmte Funktionalität weiter bereitzustellen, oder ist ihr geschäftlicher Wert vernachlässigbar und steht aufgrund ihres hohen Ressourcenbedarfs in keinem Verhältnis zu den Kosten einer Modernisierung, Wartung und Bereitstellung der Funktion?
Wenn Sie einen Legacy-Monolithen in eine moderne Microservice-Architektur umwandeln, müssen Sie die wichtigsten Aspekte kennen, die es zu berücksichtigen gilt. In diesem Artikel werden Entwurfsziele im Zusammenhang mit Microservices erörtert, Entwurfsansätze für die Zerlegung eines Legacy-Monolithen in eine Reihe kleinerer Dienste vorgestellt, und ein Muster für den eigentlichen Implementierungsprozess empfohlen.
Das Zerteilen des Monolithen
Wenn die relevanten, nicht-trivialen Fragen beantwortet wurden und alle Beteiligten den Antworten und Zielsetzungen zugestimmt haben, kann der eigentliche Übergang zu einer Microservice-Architektur geplant werden.
Doch was ist der richtige Ansatz, um einen Monolithen in Microservices aufzuteilen? Lassen Sie uns zunächst einige gängige Missverständnisse erörtern.
Je kleiner, desto besser?
Hypothese 1: Wie der Name schon sagt, sollte ein Microservice so klein wie möglich sein, d.h. je kleiner, desto besser.
Unter der Annahme, dass diese Hypothese zutrifft, besteht die ideale Lösung darin, den Monolithen an Paket-, Modul- oder sogar an Klassengrenzen aufzuteilen. Als Ergebnis erhalten wir eine Vielzahl winziger Microservices, die alle über das Netzwerk miteinander kommunizieren müssen. Abgesehen davon, dass der Arbeitsaufwand für die Erstellung so vieler Microservices immens hoch ist, besteht das gravierendere Problem darin, dass das neue Design genau der Struktur und dem Programmfluss des alten Monolithen entspricht. Die neue Architektur hat immer noch die gleichen Eigenschaften wie der Monolith, mit all den Unzulänglichkeiten und Problemen, die der eigentliche Anlass waren, überhaupt zu einem Microservice-Design wechseln zu wollen. Eine signifikante Änderung in einem solchen winzigen Microservice wird Sie höchstwahrscheinlich dazu zwingen, auch viele andere Microservices anzupassen – genau wie im monolithischen Fall, wenn Sie eine größere Änderung an einer Schnittstelle, einer Klasse oder einem Modul durchführen. Darüber hinaus ist die neue Microservice-Architektur sogar schlechter als die monolithische, da sie die schnelle prozessinterne Kommunikation durch langsame Netzwerkkommunikation ersetzt.
Es ist offenkundig, dass die Hypothese 1 nicht zutreffen kann, und dass die Größe nicht der entscheidende Faktor für die Aufteilung eines Monolithen ist.
Leistung ist das Wichtigste?
Hypothese 2: Der Programmcode von Altsystemen sollte an natürlich vorhandenen Grenzen aufgebrochen werden, die die beste Leistung für einen Microservice versprechen. Dabei sollte die individuell am besten passende Programmiersprache verwendet werden, um die Leistung eines Microservices zu maximieren.
Nehmen wir hierzu an, das Altsystem ist ein großer monolithischer Hosting-Dienst für Blogartikel, der eine API für die Verarbeitung von Bildern und Texten bereitstellt und unter anderem folgende Funktionalitäten bietet:
- Bilder können gespeichert, skaliert, konvertiert und durch Anwendung verschiedener Filter verändert werden.
- Es gibt eine semantische Suchfunktion, um ähnliche Bilder zu finden.
- Es gibt eine Bild-zu-Text-Operation, um eine Textbeschreibung anhand eines Bildes zu erhalten.
- Texte können gespeichert und als Blog-Artikel veröffentlicht werden.
- Es gibt eine Suchfunktion zum Auffinden ähnlicher Texte.
- Es gibt eine Option zur Rechtschreibkorrektur.
- Es gibt eine Text-zu-Bild-Funktion, die aus einem gegebenen Text ein KI-generiertes Bild erzeugt.
Wir können nun die verschiedenen Funktionalitäten untersuchen und möglicherweise herausfinden, dass z. B. einige Filteralgorithmen am performantesten ausgeführt werden, wenn sie in C++ implementiert werden. Andere hingegen erfordern eine hohe Parallelisierung und werden daher am besten in Golang implementiert. Bildskalierung und -konvertierung sind möglicherweise speicherkritische Operationen und werden daher am besten in Rust implementiert. Für die semantische Suche nach Bildern verwendet der Monolith möglicherweise eine in Azure gehostete Vektordatenbank. Daher bietet ein C#-Microservice für den Zugriff auf die Daten und deren Verwaltung die beste Leistung, während die eigentliche Bild-zu-Text-Funktionalität, aufgrund der KI-Möglichkeiten der Sprache, am meisten von einem Microservice in Python profitiert.
Wir können ähnliche Analysen für den Textverarbeitungsteil durchführen und die Leistung pro Funktionalität optimieren. Anschließend können wir dedizierte Microservices mit der Programmiersprache erstellen, die die beste Leistung verspricht.
Darüber hinaus können wir die Leistung des Datenzugriffs optimieren und eine hohe Datenkonsistenz zwischen allen Diensten gewährleisten, indem wir eine einzige logische Datenbank für Bilder und ebenso für Texte verwenden, um z. B. Netzwerk-Overhead zu vermeiden und Joins über Tabellen mit Daten aus verschiedenen Microservices zu ermöglichen.
Das Design der beschriebenen Microservice-Architektur könnte insofern wie in der nachfolgenden Skizze aussehen:
Allerdings ist auch dieser Ansatz (selbst wenn man den potenziellen Aufwand für die dienstübergreifende Kommunikation zwischen verwandten Diensten außer Acht lässt) mit großen Schwierigkeiten verbunden:
- Das Beherrschen der Vielzahl an Programmiersprachen erfordert hochspezialisierte Kenntnisse in einem Unternehmen (selbst im modernen Zeitalter der KI-Code-Assistenten 😉). Möglicherweise müssen spezielle Teams für jede Programmiersprache und jeden Dienst eingerichtet werden. In einem solchen Fall können die Entwickler nicht einfach in andere Teams wechseln, um auszuhelfen oder die Teamgröße dynamisch an den eigentlichen Bedarf anzupassen.
- Die Zuständigkeiten sind unklar. Wenn z. B. ein neuer Filter implementiert werden soll, welches Team soll das übernehmen?
- Entweder können Teams und Microservices nicht unabhängig voneinander agieren, da sie sich zumindest über externe Schnittstellen und Datenformate austauschen und verständigen müssen – das bedeutet, dass Abhängigkeiten ähnlich wie bei monolithischen Entwicklungen bestehen bleiben. Oder selbst bei logisch zusammengehörigen Microservices, die gemeinsam eine bestimmte Geschäftslogik implementieren, können die APIs völlig unterschiedlich aussehen und völlig unterschiedliche Terminologien, Endpunkte, Benennungen, Datentransferobjekte (DTOs), IDs usw. verwenden.
- Die Verwendung einer einzigen Datenbank für alle Dienste kann zu einem enormen Aufwand führen, um erforderliche Datenformate, Tabellen, Indexe etc. über alle Dienste hinweg zu synchronisieren und zu koordinieren. Andernfalls werden Daten möglicherweise ineffizient gespeichert, dupliziert und an Dienste weitergeleitet, selbst wenn diese nicht alle Daten benötigt. Die nachträgliche Anpassung solcher Datenformate ist ebenfalls ein kostspieliger Vorgang.
- Einige Dienste könnten zudem noch immer eine monolithische Architektur aufweisen und dadurch den angestrebten Zielen entgegenstehen. Im obigen Beispiel könnte dies z. B. für den Datenverwaltungsdienst der Fall sein.
Folglich sind die Abhängigkeiten zwischen den Microservices genauso hoch und der Entwicklungsaufwand genauso komplex, wenn nicht gar noch komplexer als bei einem Monolithen. Insofern kann auch die Hypothese 2 nicht aufrechterhalten werden.
Was ist wirklich wichtig?
Beim Entwurf einer Microservice-Architektur sind die folgenden Grundprinzipien entscheidend.
1. Hohe Kohäsion
Ein Microservice sollte ein Gebilde von stark zusammenhängendem Programmcode mit allen entsprechenden Funktionalitäten enthalten. Wenn ein Teil seiner Funktionalität geändert wird, sollte nur der Code innerhalb dieses Microservices geändert werden müssen. Wenn eine Funktionalität außerhalb eines bestimmten Microservices geändert wird, sollte sich die Änderung nicht auf den gegenwärtigen Microservice auswirken.
Die oben aufgeführte Hypothese 1 über die Größe von Microservices widerspricht diesem Prinzip.
2. Prinzip der einzigen Verantwortung (Single Responsibility Principle, SRP)
Ein Microservice sollte eine einzige, klar definierte Verantwortung oder Funktionalität der zugrundeliegenden Geschäftslogik umfassen. Wenn eine bestimmte Funktionalität aufgrund eines Fehlers oder neuer Anforderungen geändert werden muss, sollte nur dieser eine entsprechende Microservice geändert werden müssen.
Die oben aufgeführte Hypothese 2 garantiert dieses Prinzip nicht. Einige der erwähnten Beispieldienste erfüllen zwar diesen Grundsatz, z. B. bestimmte dedizierte Filterdienste, aber andere hingegen nicht. Der Datenverwaltungsdienst verwaltet beispielsweise den Zugriff auf Bild-, Text- und Vektordatenbanken und muss potenziell sehr unterschiedliche DTOs von verschiedenen Diensten in die entsprechenden spezifischen Speicher-Backend-Abfragen übersetzen.
3. Lose Kopplung
Microservices dürfen nur lose gekoppelt sein, d. h. die Abhängigkeiten zwischen Microservices sollten so gering wie möglich sein. Abhängigkeiten können nicht nur aufgrund expliziter Interaktionen bestehen, sondern auch implizit wegen gemeinsamer Datenformate oder Anforderungen an die Reihenfolge der Inbetriebnahme. Implizite Abhängigkeiten können auch durch die Notwendigkeit entstehen, Wissen auszutauschen, Berührungspunkte zu diskutieren oder aus sonstigen Gründen, die eine Kommunikation zwischen mehreren Teams erfordern.
Die Größe eines Microservices spielt keine Rolle und kann zwischen den verschiedenen Microservices, die zusammen ein System bilden, variieren. Dennoch wird ihre Größe aufgrund des SRP von vorneherein viel kleiner sein als die des ursprünglichen Monolithen.
Wenn Sie bei der Entwicklung einer Microservice-Architektur alle drei Grundsätze beachten, wird Ihre Software effizienter, skalierbarer und wartungsfreundlicher.
- Effizient, da die Ressourcen flexibel jedem Dienst entsprechend dem tatsächlichen Bedarf der jeweiligen Funktion zugewiesen werden können.
- Skalierbar, da Dienste mit unterschiedlichem Ressourcenbedarf durch Replikation individuell hoch- und herab skaliert werden können, ohne andere Dienste zu beeinträchtigen.
- Wartbar, da Fehler und neue Funktionen in einem Microservice sich nur auf eine kleine Teilmenge aller Funktionalitäten des ursprünglichen großen Monolithen beschränken. Andere Microservices können unberührt bleiben.
Nachdem wir nun wissen, worauf bei der Erstellung der Microservices geachtet werden muss, gilt es als nächstes die Frage zu beantworten, wie wir den Monolithen in eine geeignete Menge von Microservices umwandeln können.
Design-Ansätze
Es gibt keine allgemeingültige Vorgehensweise, um einen Monolithen in die richtige Menge von wohl-definierten Microservices aufzuteilen. Der Prozess ist anspruchsvoll und benötigt neben tiefem Wissen über die Interna des zugrundeliegenden monolithischen Dienstes und der zu erfüllenden Geschäftslogik, auch Wissen darüber, welchen Wert jede Komponente zum Geschäftsmodell beiträgt. Schlussendlich ist auch eine große Menge an Erfahrung für das Entwerfen einer geeigneten Microservice-Architektur wichtig.
Es gibt jedoch empfohlene Pfade, denen man zur Aufteilung eines Monolithen in Microservices folgen kann und die als Richtlinien dienen können. Ein solcher Pfad beginnt mit der Identifizierung von Geschäftsfähigkeiten (Business Capabilities).
Identifizieren von Business Capabilities (BC)
Im Wesentlichen beschreiben BCs die Tätigkeiten eines Unternehmens, die für das Unternehmen und seine Kunden einen Wert schaffen. In diesem Ansatz bestimmen die BCs die Grenzen der Microservices und die Aufteilung erfolgt aus der Geschäftsperspektive. Die Umsetzung dieses Ansatzes ist jedoch keine leichte Aufgabe, da die geschäftlichen Abläufe am besten von Fachkräften aus dem Geschäftsumfeld verstanden werden, während die architekturelle Neugestaltung von Entwicklern durchgeführt wird. Daher müssen die Verantwortlichen aus dem jeweiligen Bereich, d. h. aus dem Geschäftsumfeld und der Software-Entwicklung, dieselbe Sprache sprechen und ein gemeinsames Verständnis für jede BC finden. Einmal identifiziert, können BCs die Grundlage für dedizierte Microservices und ein guter Start für ihre Gestaltung sein. Dennoch können BCs zu einer zu groben Partitionierung des Monolithen und zu komplexen Microservices führen, so dass eine weitere Unterteilung in kleinere Dienste erforderlich sein kann. Ein Ansatz, um auf der Grundlage der BCs eine geeignete Menge von Microservices zu finden, ist das Domain-Driven Design.
Domain-Driven Design (DDD)
DDD gibt Ihnen Prinzipien und Muster an die Hand, um komplexe Domänenmodelle zu entwickeln. Eine Domäne ist „ein Bereich von Wissen, Einfluss oder Aktivität“. Die BCs entsprechen typischerweise den Domänen auf der höchsten Ebene. Mit DDD und seinen strategischen Mustern können jedoch komplexe Geschäftslogiken weiter in kleinere Unterdomänen unterteilt werden und das gesamtheitliche Modell eines Monolithen in kleinere, dedizierte und verwaltbare Domänenmodelle aufgeteilt werden. Die Unterdomänen definieren die Grenzen der entsprechenden Microservices. Die taktischen Muster von DDD leiten hierbei das Softwaredesign eines Microservices auf der Grundlage des zugehörigen Subdomänenmodells und führen zu hochgradig entkoppelten, kohärenten Diensten. Darüber hinaus hilft DDD bei der Kategorisierung der Subdomänen in drei Typen (Kern, unterstützend, generisch) basierend auf ihrem geschäftlichen Wert und ihrer Komplexität. Dies ermöglicht die Priorisierung von Microservices und die Abwägung der Kosten einer Eigenentwicklung gegenüber der Nutzung oder Lizenzierung bestehender Lösungen.
Microservice Grundlagen
Bei der Entwicklung einer modernen Softwarearchitektur, insbesondere eines modernen Cloud-nativen oder Microservice-Systems, sind viele Dinge zu beachten. Die Details würden den Rahmen dieses Artikels sprengen. Da ich jedoch ausdrücklich darauf hingewiesen habe, dass der Datenverwaltungsdienst im vorangehenden Design-Vorschlag kritisch zu betrachten ist, lassen Sie uns kurz die Datenverwaltung im Kontext von Microservices diskutieren.
Jeder Microservice, der Zugriff auf Daten aus einem externen Speicher-Backend benötigt, sollte seine eigene dedizierte Datenbank erhalten. Auf diese Weise ist die Datenautonomie für jeden Microservice gewährleistet, und es sind spezialisierte Datenbanksysteme mit unabhängigen Schemata möglich. Somit können Daten entsprechend den jeweiligen Bedürfnissen oder zwecks Leistungsoptimierung individuell gespeichert werden. Außerdem werden die Dienste weiter entkoppelt und die Teams können unabhängig voneinander agieren, z. B. wenn sie Daten oder Schemata ändern. Besondere Vorsicht ist jedoch geboten, wenn mehrere Microservices dieselben Daten benötigen und daher Kopien oder Duplikate erstellt werden. Die Daten sollten nur einem verantwortlichen Team und Microservice gehören und dieser Dateneigentümer sollte die einzige “Quelle der Wahrheit” für alle Kopien sein. Wenn ein Microservice auf Daten eines anderen Microservices zugreifen muss, sollte dies immer über eine wohldefinierte API geschehen und nicht durch direkten Zugriff auf die Datenbank. Folglich führt dies zu einer höheren Latenz, und anstelle einer strikten Konsistenz (engl. strong consistency) kommt ein nachlaufendes Konsistenzmodell (engl. eventual consistency) zur Anwendung. Zur Vermeidung potenzieller Leistungsprobleme können Caches bereitgestellt werden. Weiterhin ist zu beachten, dass im Gegensatz zu einem System mit einer traditionellen, einzelnen Datenbank keine direkte Unterstützung für Transaktionen und komplexe Join-Operationen vorhanden ist. Dies kann zu zusätzlichen Herausforderungen beim Entwurf der neuen Microservice-Architektur führen.
Ein modernes Design einer Microservice-Architektur für das oben beschriebene System könnte wie in der folgenden Skizze aussehen. Die Skizze ist jedoch nur ein erdachtes Beispiel. Ein echter Entwurf hängt stark von den Anforderungen und Details der zugrundeliegenden Geschäftsfunktionen und Domänen ab.
Die Dienste innerhalb der Box „Domain: Image Processing“ gehören logisch zusammen. Je nach Komplexität und Anforderungen können sie als dedizierte Microservices oder prozessinterne Funktionen desselben Services implementiert werden. Diese Skizze soll eine Vorstellung von einem möglichen Design geben und dessen einfache Erweiterbarkeit aufzeigen. Zum Beispiel kann das Design leicht erweitert werden, um Microservices für die Videoverarbeitung analog zur Bildverarbeitung und einen Microservice für die PDF-Verarbeitung analog zur reinen Textverarbeitung einzubeziehen. Für jeden Microservice und jeden Anwendungsfall können spezialisierte Speicher-Backends verwendet werden, z. B. entweder für optimierten Nur-Lese- oder Nur-Schreib-Zugriff. Die “Quelle der Wahrheit” liegt beim Eigentümer der Daten, d.h. bei den Diensten, die die Daten schreiben. Um den in Bezug auf Hypothese 2 erwähnten Problemen entgegenzuwirken, sollte die Programmiersprache für die Implementierung eines Microservices nur aus einer kleinen Anzahl verschiedener Sprachen ausgewählt werden.
Vom Entwurf zur Implementierung
Der Entwurf einer modernen Microservice-Architektur ist nicht die einzige große Herausforderung. Die nächste ist, wie man mit der Umsetzung beginnt und wie man am besten vom Altsystem zum modernen System übergeht.
Wenn es sich bei dem Altsystem um einen komplexen Monolithen handelt, ist es nicht der beste Weg, diesen in einer einzigen, großen Anstrengung durch eine neue Microservice-Architektur zu ersetzen. Der Zeitaufwand und die Kosten eines solchen Ansatzes sind einfach zu hoch. Während einer solchen Implementierungsphase könnten keine neuen Funktionen implementiert werden, oder sie müssten zweimal implementiert werden – im alten und im neuen System. In einem solchen Fall ist es schwierig, den zusätzlichen Zeit- und Arbeitsaufwand abzuschätzen, der zu den voraussichtlichen Gesamtkosten hinzukommt.
Würgefeigenmuster (Strangler-Fig-Muster)
Stattdessen ist es ratsam, das Strangler-Fig-Muster anzuwenden. Hierbei werden die Microservices einer nach dem anderen erstellt und ersetzen iterativ Teile des Altsystems. Das Altsystem kann folglich nach und nach abgeschaltet werden, bis es in Gänze durch die neue, moderne Architektur ersetzt wurde.
Dadurch wird der kontinuierliche Betrieb der Software sichergestellt, während neue Funktionen in einem der neuen Microservices implementiert werden können. Darüber hinaus können bestimmte Probleme mit dem Altsystem schneller gelöst werden, indem entsprechender Programmcode durch moderne Microservices ersetzt werden. Dies bedeutet, dass der Geschäftsbetrieb nicht unterbrochen wird, die Entwicklung parallel erfolgen kann und Fortschritte schnell und kontinuierlich sichtbar werden.
Nach der Fertigstellung des Entwurfs der Microservice-Architektur besteht der nächste wichtige Schritt darin, die Microservices zu identifizieren, die zum Erreichen Ihrer Ziele am geeignetsten sind und somit den größten Nutzen haben. Entsprechend können die Microservices in der Planung zur Umsetzung priorisiert werden.
Ausschlaggebend sind hierbei die Merkmale des Programmcodes im Monolithen, die durch einen Microservice ersetzt werden sollen:
- Code mit hoher Änderungsrate: Code, der häufig geändert wird, ist häufig am wichtigsten für das Erreichen der Geschäftsziele und profitiert am meisten von einer Modernisierung und einer schnellen, produktiven Nutzung. Code, der sich nie ändert, muss nicht verbessert werden!
- Code mit hohen Anforderungen an die Skalierbarkeit: Die horizontale Skalierung der entsprechenden Microservices kann eine Lösung für Ressourcenengpässe des Monolithen sein und ermöglicht eine flexible Anpassung an verschiedene Anwendungsfälle und Lastszenarien.
- Sauberer und kohärenter Code: Eine gute logische Trennung definiert auf natürliche Weise die spezifische Domäne eines Microservices.
Durch kontinuierliches Re-Evaluieren der Microservices und deren iterativen Priorisierung, können die Dienste nacheinander implementiert werden, bis die gesamte Architektur fertiggestellt ist.
Voraussetzungen für die Implementierung
Eine weitere wichtige Frage ist, wie sichergestellt werden kann, dass die neuen Microservices ihre vorgesehenen Funktionen korrekt ausführen. Angenommen, die Geschäftslogik wird direkt vom Monolithen übernommen. Wie können wir garantieren, dass sich die Neuimplementierung genau gleich verhält, selbst wenn neue Technologien und ein völlig anderes Softwaredesign verwendet werden?
Der Schlüssel dazu ist eine gute Testabdeckung des Programmcodes der Teile des Monolithen, die ersetzt werden sollen. Durch die Migration von Tests (z. B. System-, Funktions-, Akzeptanz- und bis zu einem gewissen Grad auch Integrationstests) zu den entsprechenden Microservices kann sichergestellt werden, dass sich die neue Architektur semantisch gleich verhält. Das bedeutet auch, dass bei einer geringen Testabdeckung zunächst mehr Tests für den Code des Monolithen geschrieben werden müssen.
Schließlich muss vor Beginn der Entwicklung eines neuen Microservices eine saubere API definiert werden, die dazu verwendet werden kann, Aufrufe von Komponenten des Monolithen abzufangen und an den neuen Microservice weiterzuleiten. Auf diese Weise können neue Microservices in den Betrieb des Monolithen integriert, getestet und ggf. wieder abgeschaltet und verbessert werden, bevor der entsprechende Code im Monolithen endgültig entfernt wird.
Sind Sie bereit für die Herausforderungen?
Die Umstellung von Monolithen mit komplexer Geschäftslogik auf eine moderne Microservice-Architektur ist ein kompliziertes Unterfangen. Um eine Microservice-Architektur zu entwerfen, müssen der Code, das Modell und die Geschäftslogik des Legacy-Monolithen analysiert und verstanden werden, um die entsprechenden Geschäftsfunktionen zu identifizieren und sie in Domänen und Unterdomänen aufzuteilen. An diesem Prozess sind viele verschiedene Rollen in einem Unternehmen beteiligt, von Fachkräften aus dem Geschäftsumfeld über Domänenexperten bis hin zu Entwicklern, und er erfordert eine intensive Kommunikationsphase, noch bevor die ersten Überlegungen zum eigentlichen Design angestellt werden können. Ein gemeinsames Verständnis und eine Einigung über Funktionen und Anforderungen sind für alle Beteiligten unerlässlich. Für die Implementierung moderner Microservices sind Erfahrungen mit entsprechenden Technologien und Kenntnisse über Best Practices, Fallstricke und potenzielle Leistungsengpässe erforderlich.
Wenn Sie in Ihrem Unternehmen ein solch anspruchsvolles Vorhaben planen und Unterstützung suchen, stehen wir von der CID mit unserer langjährigen Erfahrung gerne zur Verfügung. Sprechen Sie uns an!
