🔅 👳🏿 💵 Microservices oder modulare Systeme? Wie kann ein Kunde einen Ansatz für die IT-Architektur eines Produkts wählen? 🤘🏼 👂 👨🏼‍✈️

Microservice und modulare Systeme sind Arten von IT-Lösungsarchitekturen.

Bei der Arbeit mit Modulen stellen wir eine Box-Version eines vorhandenen IT-Produkts fertig.

Mit der Box-Version meinen wir einen Monolithen, ein fertiges System mit einem Kern, der allen Kunden auf die gleiche Weise "wie sie ist" geliefert wird.

Die Verfeinerung besteht darin, Module mit fehlender Funktionalität zu erstellen.

Wir erhalten neue Module, indem wir Teile des Monolithen (Kern oder andere Module) wiederverwenden.
Geschäftslogik ist in den Monolithen geschrieben: Für ein Programm (Anwendung, Site, Portal) gibt es einen Einstiegspunkt und einen Ausstiegspunkt.

Bei der Arbeit mit Microservices erstellen wir ein IT-Produkt von Grund auf neu und setzen es aus „Bausteinen“ zusammen - atomare Microservices, die für einen separaten kleinen Prozess verantwortlich sind (Brief senden, Bestellinformationen erhalten, Bestellstatus ändern, Kunden erstellen usw.).
Ein Satz solcher Blöcke wird durch Geschäftslogik zu einem gemeinsamen System kombiniert (z. B. unter Verwendung von BPMS). Trotz vorhandener Verbindungen ist jeder Block autonom und verfügt über eigene Ein- und Ausstiegspunkte.

Die meisten IT-Produkte für unsere Kunden beginnen mit der modularen Entwicklung. Einige von ihnen entwickeln sich im Laufe der Zeit zu Microservices. Für den anderen Teil werden keine Mikrodienste benötigt. In diesem Artikel werden wir untersuchen, warum dies genau so ist und anhand welcher Kriterien festgestellt werden kann, ob Microservices implementiert werden müssen oder ob Sie sich an die Arbeit mit Modulen halten sollten.

Bild

Vorteile der modularen Architektur

Alle CMS-Systeme (Bitrix, Magento, Drupal, Hybris usw.), CRM, ERP, WMS und viele andere haben Box-Versionen. Sie verkaufen sich gut und sind sehr gefragt.
Schauen wir uns diese objektiven Gründe an, warum Kunden sich am häufigsten dafür entscheiden, mit einer modularen Architektur zu arbeiten und bereitwillig Boxed-Lösungen zu kaufen.

Hohe Implementierungsgeschwindigkeit Das

Installieren, Konfigurieren und Ausfüllen von Verzeichnissen für solche Software dauert einige Zeit. Für ein mittelständisches Unternehmen ist es realistisch, drei bis vier Monate nach dem Start mit einer Box zu arbeiten, manchmal sogar etwas früher.

Für kleine Unternehmen kann dieser Zeitraum nur wenige Tage betragen.
. , enterprise- .
. . , , , .
,

. , .

Es gibt andere subjektive Faktoren, die irreführend sein und die Entscheidung für die Verwendung von Boxen und Modulen beeinflussen können.

1. Wettlauf der Hersteller

Softwareverkäufer überzeugen ihre Kunden nachdrücklich davon, dass ihre sofort einsatzbereite Lösung die richtige ist: Sie wurde jahrelang getestet und ist modisch, unternehmerisch, beliebt und im Marketing ... Jeder Anbieter: Bitrix, Magento, SAP, Oracle, OpenCart, Django und alle anderen arbeiten hart an Marketing- und Verkaufstechniken.

2. Missverständnisse über die Komplexität von Verbesserungen.

Kunden sind oft voller Optimismus. Sie entscheiden sich für Box-Software und denken: „Ja, Verbesserungen sind erforderlich. Aber es ist einfach: Sie müssen nichts Neues erfinden. Wir haben eine beliebte Version, aber Millionen von Benutzern können keine Fehler machen und ein schlechtes Produkt kaufen. “
Aus ihrer Sicht sieht der Verfeinerungsprozess folgendermaßen aus: Es gibt eine Hauptfunktionalität (in einer Box). Um etwas darin zu "beenden", müssen Entwickler das Modul "nur" neu definieren oder schnell ihr eigenes schreiben. In diesem Fall ist es nicht erforderlich, wiederholte Methoden anzuwenden, da im Monolithen angeblich alles durchdacht ist: Es werden gängige Methoden zur Berechnung der Steuern vorgeschrieben, es gibt klare Regeln für das Schreiben von Liefer- und Zahlungsmethoden, einen klaren Arbeitsablauf für Bestellungen usw.

Im wirklichen Leben sind die Dinge anders. Und nach angenehmen Emotionen vom Beginn der Arbeit mit der Box an sind die Kunden immer noch mit einer harten Realität konfrontiert. Am häufigsten geschieht dies bei Unternehmen aus mittleren und großen Unternehmen, deren Projekte eine einzigartige Geschäftslogik aufweisen und bei denen umfangreiche Verbesserungen erforderlich sind.

Wenn Ihr Unternehmen ein kleines Unternehmen ist und die Software nicht Ihr Hauptbestandteil ist, ist höchstwahrscheinlich eine beliebte Boxed-Lösung (oder besser eine Cloud-Lösung) für Sie geeignet.

Schauen wir uns an, auf welche Probleme Sie bei der Arbeit mit einer modularen Architektur stoßen können und wie Microservices dazu beitragen, dies zu vermeiden.

Probleme modularer Systeme

Das Hauptproblem besteht darin, dass nicht alle modularen Systeme so konzipiert sind, dass sie die Funktionalität ernsthaft neu definieren. Sie haben eine Box, vorgefertigte Module - das ist besser, wenn Sie sie verwenden.

Je näher die Größe des Projekts und die Komplexität ihrer Anpassungen an der Unternehmensebene liegen, desto mehr Probleme treten bei der Fertigstellung der Module auf. Lassen Sie uns über die wichtigsten sprechen.

Problem Nr. 1. Der Kern des Systems wird zu einem Verlangsamungspunkt, und Modularität wird zu einer unnötigen Komplikation

Angenommen, Ihr Projekt ist mit einer komplexen Lagerlogik verbunden. Wenn Sie sich für eine modulare Architektur entscheiden, müssen Entwickler nicht nur Funktionen zum Verwalten dieser Warehouses erstellen, sondern auch das Multicore-Modul neu definieren oder erweitern, das wiederum Kernel-Methoden verwendet.

In diesem Fall muss die komplexe Logik der Rückgabe an Lager berücksichtigt werden: Abhängigkeit von Ereignissen aus dem CRM-System, Warenbewegung zwischen Katalogen usw. Es lohnt sich auch, die versteckte Logik zu berücksichtigen, die mit der Rückgabe von Geldern, Bonuspunkten usw. verbunden ist.

Wenn so viele Neudefinitionen auftreten, ändert sich der Monolith erheblich. Es ist wichtig zu beachten, dass die Beziehung zwischen dem Volumen der neuen Funktion und der Anzahl der Module nicht linear ist: Um eine Funktion hinzuzufügen, müssen Sie entweder Änderungen an mehreren Modulen vornehmen, von denen jedes die Funktionsweise des anderen ändert, oder eine große Anzahl von Methoden anderer Module im neuen Modul neu definieren, wodurch sich das Wesentliche nicht ändert.

Nach all den Änderungen wird das System so kompliziert, dass eine unangemessen große Anzahl von Stunden erforderlich ist, um die folgenden Anpassungen hinzuzufügen.

Bild

Problem Nr. 2. Das Prinzip der Selbstdokumentation wird in modularen Systemen nicht unterstützt.

Die Dokumentation für modulare Systeme ist schwer auf dem neuesten Stand zu halten. Es ist viel davon und es wird mit jeder Änderung veraltet. Die Verfeinerung eines Moduls führt zu Änderungen in mehreren anderen Dokumenten (in der technischen Dokumentation des Benutzers), und alle müssen neu geschrieben werden.

In der Regel gibt es niemanden, der solche Arbeiten erledigt: Zeit mit wertvollen IT-Spezialisten zu verbringen bedeutet, einfach das Budget zu belasten. Selbst die Verwendung von Dokumentationsspeicher in Code (PHPDoc) garantiert nicht dessen Zuverlässigkeit. Wenn sich die Dokumentation von der Implementierung unterscheidet, muss sie sich letztendlich unterscheiden.

Problem Nr. 3. Größere Kohärenz des Codes - der Weg zur Regression: „Sie haben ihn hier geändert, er ist abgefallen“

Die klassischen Probleme modularer Systeme liegen im Kampf gegen die Regression.

Die TDD-Entwicklung ist für Monolithen aufgrund der großen Kohärenz verschiedener Methoden schwierig zu verwenden (Sie können problemlos 30 Testzeilen für fünf Codezeilen plus Fixtures ausgeben).
Im Kampf gegen die Regression ist es daher notwendig, die Funktion mit Integrationstests abzudecken.
Angesichts der ohnehin langsamen Entwicklung (schließlich müssen Sie diese sorgfältig entwickeln, um viele Überschreibungen zu ermöglichen) möchten Kunden nicht für komplexe Integrationstests bezahlen.

Funktionstests werden so groß wie bedeutungslos. Sie laufen stundenlang, auch parallel.

Ja, eine moderne Front wie PWA kann API-funktional getestet werden. Tests hängen jedoch häufig vom Empfang von Daten vom externen Schaltkreis ab - und schlagen daher fehl, wenn beispielsweise der SAP-Test um N Monate hinter dem Lebensmittelgeschäft zurückbleibt und der Test „1C“ falsche Daten sendet.

Wenn Sie für ein Modul eine kleine Bearbeitung hochladen müssen, sollten Entwickler aus zwei Übeln wählen: Starten Sie einen vollständigen CI-Lauf und verbringen Sie viel Zeit mit einer Bereitstellung oder legen Sie einen Hotfix aus, ohne einen Test auszuführen, und riskieren Sie, etwas zu beschädigen. Es ist sehr dramatisch, wenn solche Änderungen am Black Friday von der Marketingabteilung eingehen. Natürlich werden früher oder später Regression und menschliches Versagen auftreten. Ist das bekannt?

Um die Geschäftsziele zu erreichen, geht das Team in den Notfallbetrieb, jongliert gekonnt mit Tests und schaut sich die Dashboards aus den Protokollen genau an - Kibana, Grafana, Zabbix ... Aber was bekommen wir am Ende? Ausbrennen.

Sie müssen zugeben, dass eine solche Situation mit Regression nicht wie ein „stabiles Unternehmen“ ist, wie es in den Träumen und Träumen des Kunden sein sollte.

Problem Nr. 4: Code-Konnektivität und Plattform-Update

Ein weiteres Problem bei der Code-Konnektivität ist die Schwierigkeit bei der Aktualisierung der Plattform.

Zum Beispiel enthält Magento zwei Millionen Codezeilen. Wo immer wir hinschauen, gibt es überall viel Code (Akeneo, Pimcore, Bitrix). Wenn Sie dem Kernel Funktionen hinzufügen, sollten Sie Änderungen in Ihren benutzerdefinierten Modulen berücksichtigen.

Hier ist ein Live-Beispiel für Magento.
Ende 2018 wurde eine neue Version der Magento 2.3-Plattform veröffentlicht. Multistores und Elasticsearch wurden der Open Source Edition hinzugefügt. Darüber hinaus wurden Tausende von Fehlern im Kernel behoben und einige Extras in OMS hinzugefügt.

Womit haben sich E-Commerce-Projekte konfrontiert, die bereits Multistores in Magento 2.2 geschrieben haben? Sie mussten eine Reihe von Logik für die Auftragsabwicklung, das Auschecken und die Produktkarten neu schreiben, um die Box-Funktionalität nutzen zu können. In der Tat "so richtig" - warum die Funktionalität der Box-Version in den Modulen duplizieren? Das Reduzieren des Volumens an benutzerdefiniertem Code in einem großen Projekt ist immer nützlich. Schließlich berücksichtigen alle Box-Methoden diese Multi-Warehouses, und das Aktualisieren der Box ohne ein solches Refactoring kann sinnlos sein (beachten Sie der Einfachheit halber Sicherheitsprobleme, zumal sie ohne Aktualisierung aufgerollt werden können).

Stellen Sie sich nun vor: Wie viel Zeit wird für ein solches Update aufgewendet und wie kann dies ohne schwer zu schreibende Integrationstests getestet werden?

Es ist nicht verwunderlich, dass für viele das Plattform-Upgrade entweder ohne Refactoring, aber mit zunehmender Duplizierung oder (wenn das Team alles mit Feng Shui erledigen möchte) mit dem „Verlassen“ für eine lange Zeit in Refactoring und Wiederherstellung der Reihenfolge erfolgt.

Problem Nr. 5. Opazität von Geschäftsprozessen

Eines der wichtigsten Probleme im Projektmanagement ist, dass der Kunde nicht die gesamte Logik und alle Geschäftsprozesse des Projekts sieht. Sie können nur aus Code oder aus der Dokumentation wiederhergestellt werden (deren Relevanz, wie bereits erwähnt, in modularen Systemen problematisch ist).

Ja, Bitrix verfügt über einen BPM-Teil, während Pimcore über eine Workflow-Visualisierung verfügt. Dieser Versuch, Module über Geschäftsprozesse zu verwalten, steht jedoch immer im Widerspruch zum Vorhandensein eines Kernels. Darüber hinaus Ereignisse, komplexe Zeitgeber, Transaktionsvorgänge - all dies tritt bei BPM-Monolithen nicht auf. Ich wiederhole: Dies gilt für mittlere und große Unternehmen. Für ein kleines Unternehmen reichen die Fähigkeiten modularer Systeme aus. Wenn es sich jedoch um das Unternehmenssegment handelt, fehlt dieser Lösung immer noch ein einziges Kontrollzentrum, in dem Sie das Diagramm jedes Prozesses, jedes Status, wie genau etwas passiert, welche Ausnahmen, Zeitgeber, Ereignisse und Kronen angezeigt werden können . Es gibt nicht genügend Möglichkeiten, Geschäftsprozesse zu ändern, aber keine Module. Das Prozessmanagement des Projekts ertrinkt in der Geschwindigkeit des Wandels und der Kohärenz der Logik.

Problem 6. Komplexität der Systemskalierung

Wenn Sie einen Monolithen bereitstellen, wird er vollständig mit allen Modulen auf jedem App-Server bereitgestellt. Jene. Sie können den Service für die Bearbeitung von Bestellungen und Boni in einer Saison nicht separat vom Rest des Codes erhöhen.

Benötigen Sie mehr Speicher und Prozessoren, was die Kosten des Clusters erheblich erhöht.

Wie Microservices Kunden vor den für die modulare Entwicklung typischen Fehlern bewahren. Microservices Orchestration in Camunda und jBPM

Spoiler: Die Lösung der im letzten Absatz aufgeführten Probleme ist mit BPMS und der Orchestrierung von Microservice-Systemen möglich.

BPMS (English Business Process Management System) ist eine Software zur Verwaltung von Geschäftsprozessen in einem Unternehmen. Beliebte BPMS, mit denen wir arbeiten, sind Camunda und jBPM.

Orchestrierung beschreibt, wie Dienste mithilfe von Messaging miteinander interagieren sollen, einschließlich Geschäftslogik und einer Abfolge von Aktionen. Mit BPMS zeichnen wir nicht nur abstrakte Schemata - unser Geschäftsprozess wird gemäß den gezeichneten ausgeführt. Was wir im Diagramm sehen, korreliert garantiert mit der Funktionsweise des Prozesses, den verwendeten Mikrodiensten, den Parametern, anhand welcher Entscheidungstabellen eine bestimmte Logik ausgewählt wird.

Als Beispiel nehmen wir einen häufig auftretenden Prozess - das Senden einer Bestellung zur Lieferung.

Durch jede Nachricht oder jeden direkten Anruf starten wir die Auftragsabwicklung mit der Auswahl einer Versandart. Die Auswahllogik ist eingestellt.

Infolgedessen sind Prozesse, Dienstleistungen und Entwicklung:

schnell lesbar werden;
Selbstdokumentation (sie funktionieren genau so, wie sie gezeichnet wurden, und es gibt keine Rassynchronisation zwischen der Dokumentation und der tatsächlichen Arbeit des Codes);
nur debuggt (es ist leicht zu sehen, wie dieser oder jener Prozess abläuft und zu verstehen, was der Fehler ist).

Wir werden uns mit den Prinzipien vertraut machen, nach denen Geschäftsprozessmanagementsysteme funktionieren.

BPMS-Prinzip Nr. 1. Entwicklung wird visuell und prozessual

Mit BPMS können Sie einen Geschäftsprozess erstellen, in dem das Projektteam (Entwickler oder Geschäftsbenutzer) die Reihenfolge des Starts von Microservices sowie die Bedingungen und Zweige festlegt, in denen es sich bewegt. In diesem Fall kann ein Geschäftsprozess (Abfolge von Aktionen) in einem anderen Geschäftsprozess enthalten sein.

All dies wird in BPMS klar dargestellt: In Echtzeit können Sie diese Schemata ansehen, bearbeiten und produktiv einsetzen. Hier wird das Prinzip einer selbstdokumentierenden Umgebung maximal erfüllt - der Prozess funktioniert genau so, wie er visualisiert wird.

Alle Microservices werden zu Prozesswürfeln, die einem Geschäftsbenutzer im Handumdrehen hinzugefügt werden können. Das Unternehmen verwaltet den Prozess und der Entwickler ist für die Verfügbarkeit und den korrekten Betrieb eines bestimmten Microservices verantwortlich. Darüber hinaus verstehen alle Parteien die allgemeine Logik und den Zweck des Prozesses.

BPMS-Prinzip Nr. 2. Jeder Dienst verfügt über eindeutige Ein- und Ausgänge.

Das Prinzip klingt sehr einfach, und einem unerfahrenen Entwickler oder Geschäftsanwender scheint es, dass BPMS die Strategie des Schreibens von Microservices in keiner Weise verbessert. Wie normale Microservices können auch ohne BPMS geschrieben werden.

Ja, das ist möglich, aber schwierig. Wenn ein Entwickler einen Microservice ohne BPMS schreibt, hat er unweigerlich den Wunsch, an Abstraktheit zu sparen. Microservices werden offen gesagt groß und manchmal beginnen sie sogar, andere wiederzuverwenden. Es besteht der Wunsch, die Transparenz der Übertragung des Ergebnisses von einem Mikrodienst auf einen anderen zu sparen.

BPMS ermutigt Sie, abstrakter zu schreiben. Die Entwicklung erfolgt präzise prozessual mit der Definition von Input und Output.

BPMS-Prinzip Nr. 3. Parallelität der Warteschlangenverarbeitung

Stellen Sie sich den Prozess der Auftragsabwicklung vor: Wir müssen zu einem Marktplatz gehen, alle guten Aufträge abholen und mit der Bearbeitung beginnen.

Bild

Schauen Sie sich das Diagramm an (Teil des Diagramms). Hier wird festgestellt, dass wir alle 10 Minuten alle Bestellungen des Marktes überprüfen und dann parallel (wie durch den vertikalen „Hamburger“ in der Prozessbestellung angegeben) die Verarbeitung jeder Bestellung ausführen. Übertragen Sie bei Erfolg alle Daten an ERP und schließen Sie die Verarbeitung ab.

Wenn wir plötzlich die Protokolle für die Verarbeitung einer bestimmten Bestellung in Camunda, JBoss oder einem anderen BPMS aufrufen müssen, können wir alle Daten vollständig wiederherstellen und sehen, in welcher Warteschlange sie sich befanden und mit welchen Eingabe- / Ausgabeparametern.

BPMS-Prinzip Nr. 4. Fehler und Eskalation

Stellen Sie sich vor, während des Liefervorgangs ist ein Fehler aufgetreten. Zum Beispiel (dies ist übrigens ein realer Fall) nahm das Transportunternehmen die Bestellung entgegen und dann brannte das Lager nieder. Eine andere echte Geschichte: Silvesterrausch, das Produkt wurde zuerst verzögert, und dann ging es vielleicht verloren.

In diesem Fall werden Ereignisse in BPMS von der Maus ausgelöst, z. B. die Benachrichtigung eines Kunden, falls die Lieferzeit abgelaufen ist. Wenn Sie einen Fehler von der Transportfirma erhalten haben, können Sie den Vorgang in Ihrer eigenen Filiale starten und alles unterbrechen: Benachrichtigen, Rabatt auf die nächste Bestellung gewähren, Geld zurückgeben.

Alle diese Ausnahmen sind nicht nur außerhalb von BPMS (z. B. einem Timer in einem Timer) schwer zu programmieren, sondern auch im Kontext des gesamten Prozesses zu verstehen.

BPMS-Prinzip Nr. 5. Die Auswahl von Aktionen für eines der Ereignisse und Interprozessoptionen

Senden Sie die gleiche Bestellung in Lieferung.

Insgesamt haben wir drei Szenarien:

die Ware wurde wie erwartet geliefert;
die Ware wurde nicht wie erwartet geliefert;
Gegenstand ist verloren gegangen.

Direkt in BPMS können wir das Verfahren für den Versand von Waren an das Transportunternehmen festlegen und eines der Ereignisse auf Bestellung erwarten:

erfolgreiche Lieferung (Nachrichten aus dem Produktlieferprozess, dass alles geliefert wurde);
oder der Beginn einiger Zeit.

Wenn die Zeit nicht abgelaufen ist, müssen Sie einen anderen Service starten: Analysieren dieser bestimmten Bestellung mit dem Bediener (Sie müssen eine Aufgabe dafür im OMS / CRM-System festlegen, um herauszufinden, wo sich die Bestellung befindet) mit weiterer Benachrichtigung des Kunden.

Wurde die Bestellung im Zuge der Untersuchung dennoch geliefert, ist es erforderlich, die Untersuchung zu unterbrechen und die Bearbeitung der Bestellung abzuschließen.

In BPMS befinden sich alle Interrupts und Ausnahmen auf der BPMS-Seite. Sie überladen den Code nicht mit dieser Logik (und das Vorhandensein einer solchen Logik im Code würde Microservices groß machen und in anderen Prozessen schlecht wiederverwenden).

BPMS-Prinzip Nr. 6. In Ihrer Camunda sehen Sie alle Protokolle

Mit Ereignissen und der Interprozessoption können Sie:

Sie sehen die gesamte Abfolge von Ereignissen in einem Fenster (was passiert mit der Reihenfolge, welcher Zweig der Ausnahmen, die es durchlaufen hat usw. - es ist leicht zu sehen);
Sie können alle Analysen für BI nur auf der Grundlage von BPMS-Protokollen erfassen (ohne dass Microservices mit Protokollierungsereignissen überlastet werden müssen).

Auf diese Weise können Sie Statistiken speziell zu Verarbeitungsproblemen, Übergangsraten und allen Prozessen des Unternehmens sammeln. Es gibt eine Vereinheitlichung der Protokollierungsinformationen - es ist einfach, das Ereignis in der Lieferung mit der Aktion des Bedieners oder dem Ereignis eines anderen Informationssystems zu verknüpfen.

Beachten Sie den Unterschied zum modularen System: Dort können auch universelle Protokolle erstellt werden. Wenn Sie jedoch mit anderen Systemen interagieren, müssen Sie auch die Vereinheitlichung der Anmeldung vereinheitlichen. Dies ist nicht immer möglich.

Schlussfolgerungen: Ein Vergleich von Microservice und modularer Architektur

Jede Art von Architektur hat ihre Vor- und Nachteile. Es gibt keine universelle Lösung.

Wir befürworten keine massive Verlagerung auf Microservices. Im Gegenteil, für ein kleines Unternehmen oder bei Verwendung einer sehr geringen Anzahl von Anpassungen ist ein modularer Ansatz besser geeignet.

Wir sind auch nicht gegen eine IT-Lösung (Bitrix, Magento, Frameworks wie Symfony oder Django usw.), da wir allein auf diesen Frameworks jeden Monat mehr als sechstausend Stunden Code entwickeln und die gleiche Menge an Front'a und Microservices. Wir sind daher davon überzeugt, dass es wichtig ist, nach einer geeigneten technischen Lösung zu suchen und nicht die Verwendung einer bestimmten Plattform zu fördern (auf die leider ein erheblicher Teil des IT-Umsatzes abläuft).

In den vorherigen Abschnitten des Artikels haben Sie die Nachteile und Vorteile der modularen Architektur kennengelernt. Wir hoffen, dass dies bereits dazu beigetragen hat, zu bewerten, ob die Verfeinerung der Box-Version oder die Erstellung von Microservices von Grund auf besser geeignet wäre. Wenn es nicht möglich war, eine Entscheidung zu treffen, sehen wir uns an, wie sich die verschiedenen Architekturtypen je nach Projektlebensdauer ändern.

Zu Beginn des Projekts:

Mit Microservices haben Sie keine Funktionalität und müssen alles schreiben, um an die Arbeit zu gehen.
mit einem modularen System - ab der Box-Version steht Ihnen sofort eine große Menge an Funktionen zur Verfügung, und Sie können das Produkt bald nach dem Kauf verwenden.

Nach den ersten 3-4 Monaten der Entwicklung (dies ist das durchschnittliche Veröffentlichungsdatum für das erste MVP) und darüber hinaus:

mit Microservices - das Funktionsvolumen wird im Vergleich zur Box-Version schrittweise angepasst. Für mittelständische Unternehmen wird die Microservice-Architektur schnell genug modular sein, für große jedoch - im Allgemeinen sofort. Und in Zukunft wird die Wartung und Entwicklung eines modularen Systems in Bezug auf eine funktionale Einheit zunehmen.
Mit einem modularen System ist die Geschwindigkeit der Funktionsentwicklung erheblich geringer als bei Microservices.

Lassen Sie uns abschließend anhand konkreter Beispiele untersuchen, wie die Orchestrierung von Microservices aussieht.

Visualisierungsbeispiele für die Orchestrierung von Diensten

Betrachten Sie die Orchestrierung von Diensten mit Camunda. Anhand der folgenden Bilder können Sie bewerten, wie bequem es ist, Microservices mithilfe von BPMS mit einem Orchestrator zu verwalten. Alle Prozesse sind visuell, die Logik ist offensichtlich.

Geschäftsprozesse sehen folgendermaßen aus:
Bild

Beispiel (Bestellung, Verfügbarkeitsservice):

Bild

Es ist ersichtlich, dass in dieser Bestellung eine Filiale „Keine Ware“ vorhanden war.

Eine weitere Kopie der Bestellung (ging zur Baugruppe): Die

Bild

Bestellung ging weiter und ging laut Entscheidungstabelle (DMN) von einem bestimmten Lieferservice-Betreiber (Boxberry) in die Verarbeitungsabteilung:

Bild

Pflege des verschachtelten Prozesses: Der

Bild

verschachtelte Prozess funktionierte:

Bild

Verlauf der Geschäftsprozesse:

Bild

Eigenschaften dieser Visualisierung:

Geschäftsprozesse sind selbst für einen unvorbereiteten Benutzer leicht zu lesen.
Sie sind ausführbar, dh sie funktionieren genau so, wie sie gezeichnet wurden. Es gibt keine Rassynchronisation zwischen der "Dokumentation" und der eigentlichen Arbeit des Codes.
Die Prozesse sind transparent: Es ist leicht zu erkennen, wie ein bestimmter Import, eine bestimmte Bestellung oder eine bestimmte Verarbeitung verlaufen ist. Es ist leicht zu erkennen, wo der Fehler gemacht wurde.

Denken Sie daran, dass wir bei kt.team sowohl modulare als auch Microservice-Entwicklung verwenden und für jedes Produkt die richtige Option auswählen. Wenn jedoch bereits die Entscheidung für eine Microservice-Architektur getroffen wurde, sind wir fest davon überzeugt, dass auf BPM-Systeme wie Camunda oder jBPM nicht verzichtet werden kann.

Siehe auch: Video zum Thema „Microservice oder monolithische Architektur: Was soll ich wählen?“

Microservices oder modulare Systeme? Wie kann ein Kunde einen Ansatz für die IT-Architektur eines Produkts wählen?