![\"\"](\"https:\/\/lh4.googleusercontent.com\/LJNBLc7RQmE82gtn20rlG5_f5-9x7L_OLHhH4tO4adLJka9RTjUPe0WzVFh7ksCVDJJwYkj1FAeuLw1LSmu6byQZevHtsP4GVQMZdmpI6YLp8W4g6rAvEVFqNYtSAOXmsSELETIIkoLLwE0KnQzzMQ\")
<\/figure>\n\nDie monolithische Architektur ist das traditionelle Modell, bei dem ein Softwareprogramm als eine kombinierte Einheit entwickelt wird, die in sich geschlossen und unabh\u00e4ngig von anderen Anwendungen ist. Diese Architektur gilt als der traditionelle Ansatz f\u00fcr die Entwicklung und Erstellung von Anwendungen als einzelne, einheitliche Einheiten. Typischerweise besteht dieser Ansatz aus einer clientseitigen Benutzeroberfl\u00e4che, einer serverseitigen Anwendung und einer Datenbank. Eine monolithische Architektur ist ein umfangreiches Computernetzwerk mit einer gro\u00dfen Codebasis, in der alle gesch\u00e4ftlichen Belange integriert sind. <\/p>\n\n
Wenn Sie eine monolithische Anwendung \u00e4ndern m\u00f6chten, m\u00fcssen Sie den gesamten Stack aktualisieren, indem Sie auf die Codebasis zugreifen und eine aktualisierte Version der service-seitigen Schnittstelle erstellen und installieren.<\/p>\n\n
Monolithische Software besteht in der Regel aus drei Komponenten;<\/p>\n\n
- \n
- Client-seitige Benutzeroberfl\u00e4che – besteht aus HTML-Seiten oder Javascript, die in einem Browser ausgef\u00fchrt werden<\/li>\n\n\n\n
- Serverseitige Anwendung – bearbeitet HTTP-Anfragen, implementiert dom\u00e4nenspezifische Logik, ruft Daten aus der Datenbank ab und aktualisiert sie und f\u00fcllt die HTML-Ansichten, die an den Browser gesendet werden.<\/li>\n\n\n\n
- Datenbank – enth\u00e4lt viele Tabellen, die in einem relationalen Datenbankmanagementsystem \u00fcblich sind.<\/li>\n<\/ul>\n\n
Mit diesem Modell kann die ETL-Pipeline gestreamt werden, w\u00e4hrend die Daten \u00fcber den Monolithen in eine einzige Datenbank flie\u00dfen. Aber auch wenn Sie ein Microservices-Modell anwenden, k\u00f6nnen Sie Ihre ETL-Pipeline mit einer kodierungsfreien L\u00f6sung wie Xplenty vereinfachen. <\/p>\n\n
Vorteile der monolithischen Architektur<\/strong><\/p>\n\n
Ein Unternehmen kann in Abh\u00e4ngigkeit von verschiedenen Faktoren von einer monolithischen Architektur profitieren. Die Verwendung einer monolithischen Architektur bei der Entwicklung Ihrer Anwendung hat mehrere Vorteile, von denen wir Ihnen im Folgenden einige vorstellen. <\/p>\n\n
- \n
- Einfache Handhabung von Problemen, die die gesamte Software betreffen k\u00f6nnen. In der Regel bezeichnen die Entwickler diese Probleme als \u00fcbergreifende Belange, einschlie\u00dflich Leistungs\u00fcberwachung, Caching, Protokollierung und Handhabung. In einer monolithischen Anwendung befindet sich alles an einer Stelle und ist nicht auf verschiedene Microservices verstreut. Die monolithische Architektur minimiert die Schwierigkeiten, die mit der Bew\u00e4ltigung solcher Probleme verbunden sind, betr\u00e4chtlich. <\/li>\n\n\n\n
- Einfachheit. Bei der Entwicklung kleiner bis mittelgro\u00dfer Anwendungen ist eine monolithische Architektur einfacher zu entwickeln, einzusetzen und zu skalieren. Die meisten integrierten Entwicklungsumgebungen und Entwicklungslaufwerke unterst\u00fctzen die monolithische Architektur als traditionelles Modell f\u00fcr die Erstellung von Anwendungen. End-to-End-Tests sind viel einfacher, wenn Sie nur mit einer umfangreichen Codebasis arbeiten. <\/li>\n\n\n\n
- Leistung. Monolithische Anwendungen haben in der Regel eine bessere Leistung als Microservices. Eine API kann in monolithischen Anwendungen denselben Zweck erf\u00fcllen, da sie \u00fcber konsolidierten Code und Speicher verf\u00fcgt. <\/li>\n<\/ul>\n\n
Nachteile der monolithischen Architektur<\/strong><\/p>\n\n
Monolithische Anwendungen sind praktisch, bis sie expandieren und ihre Skalierung ein Problem wird. Die Bereitstellung einer geringf\u00fcgigen \u00c4nderung in einer Funktion erfordert die Kompilierung und das Testen der gesamten Plattform, was dem modernen agilen Ansatz, den die meisten Entwickler verwenden, widerspricht. Die monolithische Architektur hat einige Nachteile, von denen im Folgenden einige aufgef\u00fchrt werden. <\/p>\n\n
- \n
- Skalierbarkeitspotenzial. Das Skalierbarkeitspotenzial einer monolithischen Anwendung h\u00e4ngt von ihrer Gr\u00f6\u00dfe ab. Wenn Sie eine umfangreiche und komplexe Anwendung entwickeln m\u00f6chten, gibt es bessere Softwarearchitekturen als die monolithische Architektur. Bei einer komplexeren Anwendung wird die Skalierbarkeit enorm sein. Sie wird zu einem erheblichen Problem, da die Verwaltung und Eind\u00e4mmung eines umfangreichen Softwareprojekts unter einer gro\u00dfen Codebasis anstrengender wird. <\/li>\n\n\n\n
- Flexibilit\u00e4t. Monolithische Anwendungen sind unflexibel, wenn es um Flexibilit\u00e4t geht. Bei einer monolithischen Anwendung k\u00f6nnen Sie davon ausgehen, dass Sie sie eine ganze Weile nutzen k\u00f6nnen, ohne Ihren technischen Stack zu \u00e4ndern. Und eine \u00c4nderung Ihres Stacks ist bei einer monolithischen Architektur praktisch unm\u00f6glich. Sie m\u00fcssen Ihre Software neu schreiben, um den Stack unterzubringen, den Sie implementieren m\u00f6chten, was umfangreiche Ressourcen erfordert und sich nicht lohnt. <\/li>\n\n\n\n
- Eine monolithische Architektur macht Ihren Code komplizierter. Da es eine einzige Codebasis gibt, wird sie exponentiell komplexer, wenn sich die Anwendung entwickelt und \u00e4ndert. Diese \u00c4nderungen oder Aktualisierungen m\u00fcssen in der gesamten Anwendung koordiniert werden, aber die Benutzer k\u00f6nnen sie \u00fcber einen einzelnen Teil hinaus erweitern. <\/li>\n<\/ul>\n\n
Microservice Architektur<\/strong><\/p>\n\n
<\/figure>\n\n
W\u00e4hrend eine monolithische Anwendung eine einzige integrierte Einheit darstellt, wird sie bei der Microservice-Architektur in mehrere kleinere, in sich geschlossene Einheiten aufgeteilt. Diese Einheiten f\u00fchren normalerweise jeden Anwendungsprozess als unabh\u00e4ngigen Dienst aus. Daher haben alle Dienste ihre eigene Datenbank und Logik und f\u00fchren spezifische Funktionen aus. <\/p>\n\n
Die Microservice-Architektur ist ein Ansatz, bei dem eine einzelne Anwendung als eine Reihe kleiner Dienste entwickelt wird, von denen jeder in seinem eigenen Prozess arbeitet und mit leichtgewichtigen Mechanismen, in der Regel einer HTTP-Ressourcen-API, kommuniziert. Sam Newman, ein unabh\u00e4ngiger Berater, sagt: „Microservices sind die kleinen Dienste, die zusammenarbeiten.“ <\/p>\n\n
Die Microservice-Architektur besteht aus einer Sammlung kleiner, autonomer Dienste. Jeder Dienst ist unabh\u00e4ngig und implementiert eine gesch\u00e4ftliche oder technische F\u00e4higkeit der Anwendung, die er innerhalb eines begrenzten Kontexts kapselt. Ein eingegrenzter Kontext bezieht sich auf einen nat\u00fcrlichen Bereich innerhalb der Organisation und bildet eine klare Grenze, innerhalb derer das Dom\u00e4nenmodell existiert. <\/p>\n\n
Die Architektur von Microservices hat erhebliche Auswirkungen auf die Beziehung zwischen der Datenbank und der Anwendung. Anstatt also eine einzige Datenbank mit anderen Microservices zu nutzen, hat jeder Microservice seine eigene Datenbank. Eine Datenbank pro Microservice ist unerl\u00e4sslich, wenn Sie von dieser Architektur profitieren m\u00f6chten, um eine lose Kopplung zu gew\u00e4hrleisten. <\/p>\n\n
Komponenten der Microservice-Architektur<\/strong><\/p>\n\n
![\"\"](\"https:\/\/devologyx.io\/wp-content\/uploads\/2023\/07\/pexels-pixabay-326461-1024x678.jpg\")
<\/figure>\n\nMicroservices sind klein, in sich geschlossen und lose gekoppelt. Ein kleines Team von Programmierern kann den Dienst schreiben und unterst\u00fctzen, da jeder Dienst seine eigene Datenbank besitzt. Die Dienste sind f\u00fcr die Bewahrung ihrer Daten oder ihres externen Zustands verantwortlich. Dies steht im Gegensatz zum traditionellen Ansatz, bei dem eine separate Datenschicht f\u00fcr die Datenerhaltung zust\u00e4ndig ist. Hier sind einige der Komponenten einer Microservices-Architektur <\/p>\n\n
- \n
- Orchestrierung. Diese Komponente befasst sich mit der Platzierung von Diensten auf Knoten, der Erkennung von Ausf\u00e4llen, der Stabilisierung von Diensten auf verschiedenen Knoten usw. In der Regel handelt es sich bei dieser Komponente um eine Off-the-Shell-Technologie wie Kubernetes und nicht um eine ma\u00dfgeschneiderte L\u00f6sung. <\/li>\n\n\n\n
- API-Gateway. Das API-Gateway ist der Zugangspunkt f\u00fcr Clients. Anstatt die Dienste direkt aufzurufen, rufen die Clients das API-Gateway an und leiten den Anruf an die entsprechenden Dienste am Backend weiter. <\/li>\n<\/ul>\n\n
Vorteile der Microservices-Architektur<\/strong><\/p>\n\n
![\"\"](\"https:\/\/devologyx.io\/wp-content\/uploads\/2023\/07\/pexels-sebastian-voortman-411207-1024x683.jpg\")
<\/figure>\n\nDie Microservices-Architektur hat sich dank der Cloud, der Containerisierung und der hypervernetzten Systeme weiterentwickelt. Au\u00dferdem hat die Microservices-Architektur einige Vorteile f\u00fcr den Benutzer, wie unten aufgef\u00fchrt. <\/p>\n\n
- \n
- Verbesserte Agilit\u00e4t. Mit dieser Art von Softwarearchitektur k\u00f6nnen Entwickler an unabh\u00e4ngigen Modulen arbeiten. Jeder Entwickler kann ein Modul unabh\u00e4ngig erstellen und bereitstellen, wodurch die operativen Reibungen im Team minimiert werden. Au\u00dferdem ist es einfach, Fehlerkorrekturen und Update-Releases zu kontrollieren. Sie k\u00f6nnen einen Dienst aktualisieren, ohne die gesamte Anwendung neu bereitzustellen, und die Aktualisierung abbrechen, wenn sie schief geht. Wenn bei monolithischen Anwendungen ein Fehler in einem Teil entdeckt wird, kann dies normalerweise den gesamten Freigabeprozess blockieren. <\/li>\n\n\n\n
- Bessere Skalierbarkeit. Die Microservices-Architektur kann jeden einzelnen Dienst unabh\u00e4ngig skalieren. Sie erm\u00f6glicht es Ihnen, Teilsysteme, die mehr Ressourcen ben\u00f6tigen, zu skalieren, ohne die gesamte Anwendung zu skalieren. Die Skalierung monolithischer Anwendungen verschlingt Zeit und Kosten, selbst wenn sie nicht erforderlich ist. Durch die Verwendung eines Orchestrators wie Service Fabric oder Kubernetes wird eine h\u00f6here Dichte an Diensten auf einem Host erreicht, was eine effiziente Nutzung der Ressourcen erm\u00f6glicht. <\/li>\n\n\n\n
- Die Microservices-Architektur f\u00f6rdert die Dezentralisierung. Eine fokussierte Zentralregierung ist entscheidend f\u00fcr eine erfolgreiche Regierungsf\u00fchrung. Diese Art von Struktur w\u00e4re, abgesehen von der Politik, leicht zu Fall zu bringen. Die Zentralisierung der Dinge an einem Ort bedeutet, dass, wenn etwas schief geht. Das gesamte System f\u00e4llt auseinander. Die Microservices-Architektur umfasst eine Dezentralisierung, bei der die Entwickler unabh\u00e4ngiger agieren und unabh\u00e4ngig vom Standort als Team arbeiten k\u00f6nnen. Au\u00dferdem bietet sie Flexibilit\u00e4t. Sie k\u00f6nnen mehrere Tech Stacks in einer einzigen Anwendung implementieren. So k\u00f6nnen Sie den einflussreichsten Tech-Stack f\u00fcr die Entwicklung eines Dienstes ausw\u00e4hlen. <\/li>\n<\/ul>\n\n
Nachteile der Microservices-Architektur<\/strong><\/p>\n\n
![\"\"](\"https:\/\/devologyx.io\/wp-content\/uploads\/2023\/07\/pexels-tim-gouw-52608-1024x685.jpg\")
<\/figure>\n\nDie Vorteile von Microservices sind zu gut, um kostenlos zu sein. Die Nachteile einer Microservices-Architektur sind ein wenig schwer zu ertragen. Au\u00dferdem m\u00fcssen Sie sich sicher sein, ob Sie die vorbildliche Software-Architektur f\u00fcr Ihr Unternehmen w\u00e4hlen. <\/p>\n\n
- \n
- Komplexit\u00e4t. Eine Microservices-Architektur hat mehrere bewegliche Teile als eine monolithische Architektur. Jeder Dienst ist einfach, aber das System als Ganzes wird komplex. Die Kommunikation zwischen den Diensten ist kompliziert. APIs f\u00f6rdern in der Regel diese Kommunikation und werden in der Regel implementiert, um Softwareplattformen zu verbinden. Die Komplexit\u00e4t in Microservices-Anwendungen steigt mit der Zunahme der Microservices. <\/li>\n\n\n\n
- \u00dcberlastung des Netzwerks. Die Verwendung vieler kleiner Dienste kann zu einer Kommunikation zwischen den Diensten f\u00fchren. Und wenn die Kette der Service-Abh\u00e4ngigkeiten sehr lang wird, wird die zus\u00e4tzliche Latenz zu einem Problem. Das bedeutet, dass Sie APIs sorgf\u00e4ltig erstellen m\u00fcssen. Denken Sie \u00fcber Serialisierungsformate nach und suchen Sie nach M\u00f6glichkeiten, asynchrone Kommunikationsmuster zu verwenden. <\/li>\n\n\n\n
- Entwicklung und Testen. Die Entwicklung eines kleinen Dienstes, der von anderen abh\u00e4ngigen Diensten abh\u00e4ngt, erfordert eine andere Herangehensweise als das Schreiben eines herk\u00f6mmlichen mehrschichtigen Programms. Die verf\u00fcgbaren Tools sind nicht immer f\u00fcr die Arbeit mit Dienstabh\u00e4ngigkeiten ausgelegt. Das Refactoring \u00fcber Servicegrenzen hinweg wird m\u00fchsam, und das Testen von Serviceabh\u00e4ngigkeiten ist komplex, vor allem, wenn sich die Anwendung schnell weiterentwickelt. <\/li>\n<\/ul>\n\n
Migration von Monolithen zu Microservices<\/strong><\/p>\n\n
![\"\"](\"https:\/\/devologyx.io\/wp-content\/uploads\/2023\/07\/pexels-liz-lauren-6000599-1024x683.jpg\")
<\/figure>\n\nSkalierbarkeit ist der Hauptgrund, warum Entwickler von einer monolithischen zu einer Microservices-Architektur wechseln. Die Skalierbarkeit selten genutzter Komponenten ist unbedeutend. Komponenten, die von den meisten Benutzern genutzt werden, sollten bei der Umstellung zuerst ber\u00fccksichtigt werden. Im Folgenden finden Sie eine typische Vorgehensweise f\u00fcr den Wechsel von einem monolithischen System zu einem Microservices-Ansatz. <\/p>\n\n
- \n
- Identifizieren Sie die logischen Komponenten.<\/li>\n<\/ol>\n\n
Es gibt haupts\u00e4chlich drei Informationskomponenten mit den im System verwendeten Daten: Datenobjekte, Aktionen, auszuf\u00fchrende Aufgaben und Anwendungsf\u00e4lle. Die logischen Konstrukte sind die Datenobjekte, die die verwendeten Daten darstellen. Datenaktionen sind Befehle zur Ausf\u00fchrung einer Aufgabe f\u00fcr einzelne oder mehrere Datenobjekte. Die auszuf\u00fchrenden Aufgaben sind die Funktionen, die Benutzer aufrufen, um ihre Aufgaben zu erf\u00fcllen. <\/p>\n\n
- \n
- Refactor Komponenten<\/li>\n<\/ol>\n\n
Wenn Sie alle Komponenten identifiziert und zusammengestellt haben, organisieren Sie sie intern – einige doppelte Funktionen m\u00fcssen vor der Anwendung des Microservices beseitigt werden. Es sollte nur einen Microservice geben, der eine Funktion ausf\u00fchrt. <\/p>\n\n
- \n
- Identifizieren Sie Abh\u00e4ngigkeiten von Komponenten<\/li>\n<\/ol>\n\n
Nachdem die zu migrierenden Komponenten identifiziert und organisiert wurden, muss das System die Abh\u00e4ngigkeiten innerhalb der Komponenten erkennen. Dazu wird in der Regel eine statische Quellcodeanalyse durchgef\u00fchrt, um nach Aufrufen zwischen verschiedenen Bibliotheken und Datentypen zu suchen. <\/p>\n\n
- \n
- Spot Komponenten Gruppen<\/li>\n<\/ol>\n\n
Der Systemarchitekt muss sich darauf konzentrieren, die Komponenten in Gruppen zu kategorisieren, die in Microservices umgewandelt werden k\u00f6nnen. Das Ziel ist es, eine kleine Gruppe von Objekten und deren elementare Aktionen zu finden, die im endg\u00fcltigen System getrennt werden m\u00fcssen. <\/p>\n\n
- \n
- Erstellen Sie eine API f\u00fcr die Remote-Benutzeroberfl\u00e4che<\/li>\n<\/ol>\n\n
Die Remote-Benutzerschnittstelle ist der einzige Ansatz f\u00fcr die Kommunikation zwischen dem System, seinen Komponenten und den Benutzern des Systems. Diese Schnittstelle muss systematisch geplant und skalierbar sein, um Probleme zu vermeiden, wenn das System w\u00e4chst. <\/p>\n\n
- \n
- Verschieben Sie Komponentengruppen in Makroservices.<\/li>\n<\/ol>\n\n
Makrodienste neigen dazu, eine moderate Haltung gegen\u00fcber der Aufteilung von Datenbest\u00e4nden einzunehmen und komplexere Interaktionen mit Datenobjekten zu erm\u00f6glichen. Daher ist es wichtig, ihre Verwendung als einen vorl\u00e4ufigen Schritt zur Vervollst\u00e4ndigung der Migration zu betrachten. <\/p>\n\n
- \n
- Makroservices in Microservices umwandeln<\/li>\n<\/ol>\n\n
Das Ziehen von Datenobjekten, Komponenten und Funktionen aus der monolithischen Architektur zu Makrodiensten gibt Aufschluss dar\u00fcber, wie diese Komponenten weiter in Mikrodienste unterteilt werden k\u00f6nnen. Denken Sie daran, dass jeder Microservice seine Datenbank enth\u00e4lt und nur eine begrenzte Anzahl von Aktionen auf seinen Datenobjekten ausf\u00fchrt. <\/p>\n\n
- \n
- Einsatz und Tests<\/li>\n<\/ol>\n\n
Der folgende Schritt umfasst Integrationstests und die Bereitstellung, sobald der Microservice fertig ist. Die monolithische Architektur muss so angepasst werden, dass sie den neuen Dienst f\u00fcr ihre Datenanforderungen anstelle der alten Datenbank verwendet. <\/p>\n\n
Fazit<\/strong><\/p>\n\n
Die Umstellung auf eine Microservices-Architektur ist kein Allzweckansatz. Die monolithische Architektur ist zwar ber\u00fcchtigt und weniger ber\u00fchmt, hat aber neben ihren St\u00e4rken auch handfeste und schwerwiegende Vorteile gegen\u00fcber Microservices. Sie sollten mit einer monolithischen Architektur beginnen, um Ihre neue Gesch\u00e4ftsidee zu validieren. Ein kleines Team von Entwicklern begleitet Sie bei der Entwicklung einer einfachen Anwendung, f\u00fcr die Sie keine Microservices ben\u00f6tigen. <\/p>\n\n
Die Microservices-Architektur ist f\u00fcr umfangreiche und komplexe Anwendungen besser geeignet. Sie bietet Produktl\u00f6sungen f\u00fcr ein komplexes System mit mehreren Funktionen und Diensten innerhalb einer einzigen Anwendung. Microservices eignen sich perfekt f\u00fcr Plattformen, die viele User Journeys und Workflows abdecken. <\/p>\n","protected":false},"excerpt":{"rendered":"
Ich bin mir sicher, dass Ihnen das Thema Monolithische Architektur vs. Microservices-Architektur seltener begegnet ist, als dass Sie geh\u00f6rt haben, wie \u00fcber Programmierparadigmen, Tools oder Software-Frameworks diskutiert wird. Sie m\u00fcssen die Art der Softwarearchitektur gleich zu Beginn Ihres Projekts ausw\u00e4hlen. Sie tr\u00e4gt dazu bei, das Design Ihrer Anwendung zu definieren und ist eine der wichtigsten […]<\/p>\n","protected":false},"author":1,"featured_media":16700,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_themeisle_gutenberg_block_has_review":false,"_jet_sm_ready_style":"","_jet_sm_style":"","_jet_sm_controls_values":"","_jet_sm_fonts_collection":"","_jet_sm_fonts_links":"","footnotes":""},"categories":[20],"tags":[],"writer":[],"class_list":["post-19698","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-unkategorisiert"],"_links":{"self":[{"href":"https:\/\/devologyx.io\/de\/wp-json\/wp\/v2\/posts\/19698","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devologyx.io\/de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devologyx.io\/de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devologyx.io\/de\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/devologyx.io\/de\/wp-json\/wp\/v2\/comments?post=19698"}],"version-history":[{"count":1,"href":"https:\/\/devologyx.io\/de\/wp-json\/wp\/v2\/posts\/19698\/revisions"}],"predecessor-version":[{"id":19700,"href":"https:\/\/devologyx.io\/de\/wp-json\/wp\/v2\/posts\/19698\/revisions\/19700"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devologyx.io\/de\/wp-json\/wp\/v2\/media\/16700"}],"wp:attachment":[{"href":"https:\/\/devologyx.io\/de\/wp-json\/wp\/v2\/media?parent=19698"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devologyx.io\/de\/wp-json\/wp\/v2\/categories?post=19698"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devologyx.io\/de\/wp-json\/wp\/v2\/tags?post=19698"},{"taxonomy":"writer","embeddable":true,"href":"https:\/\/devologyx.io\/de\/wp-json\/wp\/v2\/writer?post=19698"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
- Einsatz und Tests<\/li>\n<\/ol>\n\n
- Makroservices in Microservices umwandeln<\/li>\n<\/ol>\n\n
- Verschieben Sie Komponentengruppen in Makroservices.<\/li>\n<\/ol>\n\n
- Erstellen Sie eine API f\u00fcr die Remote-Benutzeroberfl\u00e4che<\/li>\n<\/ol>\n\n
- Spot Komponenten Gruppen<\/li>\n<\/ol>\n\n
- Identifizieren Sie Abh\u00e4ngigkeiten von Komponenten<\/li>\n<\/ol>\n\n
- Refactor Komponenten<\/li>\n<\/ol>\n\n
- Identifizieren Sie die logischen Komponenten.<\/li>\n<\/ol>\n\n