de

Wie es funktioniert?

Benötigen Sie Hilfe für Unternehmen?

Kontaktieren Sie uns für ein individuelles, auf Ihre Bedürfnisse zugeschnittenes FinMV-Angebot.

Monolithisch oder Microservice?

Der technische Leiter Ihres Unternehmens muss bei der Planung der Einführung einer Finanzplattform eine Projektarchitekturoption auswählen. Welche Architekturoptionen stehen ihm zur Verfügung und welche ist besser zu wählen?

Option 1. Monolithische Architektur (Monolith)

Eine monolithische Architektur ist wie ein Schneeball. Du startest ein Projekt und hast einen kleinen Schneeball. Es ist so klein, dass es von einem kleinen Team entwickelt und gerollt werden kann. Ein paar Jahre vergehen, und jetzt ist Ihr Schneeball so groß geworden, dass 20 Entwickler ihn bereits vorantreiben. In ein paar Jahren werden Hunderte von Entwicklern Ihren Schneeball mit einer Menge Code rollen, aber die Einführung neuer Funktionen wird sehr langsam werden.

Infolgedessen beginnen die Eigentümer, den technischen Direktor und die Teammitglieder zu wechseln, aber es wird nur noch schlimmer. Neue Teammitglieder kennen die historischen Details nicht, warum der Schneeball so ist, wie er ist und nicht anders. Die Produktdokumentation ist schnell veraltet.

Warum nicht gleich von Anfang an? Erstens gibt es ganz am Anfang eines Unternehmens immer Ressourcen sind begrenzt, es gibt nicht genug Entwickler, Fachwissen und Zeit. Das Handbuch drängt, und die Programmierer haben es eilig, es so schnell wie möglich zu tun.

Zweitens denken technische Ingenieure: "Nun, lass es erstmal eine monolithische Architektur sein, aber wenn das Geschäft wächst, dann machen wir alles neu". Leider ist die Übertragung eines bestehenden monolithischen Projekts in eine Microservice-Architektur in Wirklichkeit zehnmal schwieriger, als alles von Grund auf neu zu schreiben.

Option 2. Microservice-Architektur

Wir machen Ihre Finanzplattform sofort auf Basis einer Microservice-Architektur.

Microservice-Architektur kann mit Pflastersteinen auf Fußwegen verglichen werden. Wenn Ihr Projekt wächst, werden Ihrem Gehweg mehr Kacheln hinzugefügt. Wenn eine Komponente veraltet ist, reicht es aus, diese Kachel durch eine neue zu ersetzen.

Diese Architektur hat viele Vorteile, aber ich nenne die wichtigsten:

  • Einzelne Mitarbeiter sind für den Betrieb jedes Microservices verantwortlich
  • Der Diebstahl von Projektcode wird verhindert, da Entwickler nur auf einen Teil des Codes Zugriff haben
  • Wenn Updates für Programmiersprachen herauskommen, können Sie den Programmcode jedes Dienstes einzeln korrigieren

Beispiele aus dem wirklichen Leben

Erstes Beispiel. Das Management einer P2P-Kreditplattform mit einer großen Anzahl von Benutzern entschied sich für den Eintritt in die Märkte von Ländern mit einer anderen Währung. Die Plattform hatte eine monolithische Architektur und umfasste nur eine Währung – den Euro. Um in die Märkte von Schweden (Schwedische Krone), Polen (Polnischer Zloty) und der Tschechischen Republik (Tschechische Krone) einzutreten, war es notwendig, mehrere Währungen einzuführen.

Es dauerte Monate, bis das gesamte Team diese Funktion implementiert hatte, und die Entwicklung neuer Funktionen verlangsamte sich noch weiter. Im Falle einer Microservice-Architektur wäre alles viel einfacher und schneller.

Zweites Beispiel. Ursprünglich wurde der Website-Builder in der Muttersprache gestartet und das Management wollte nicht in andere Märkte expandieren. Das Projekt hatte eine monolithische Architektur und die Funktionalität wuchs schnell. Das Schema der Plattform war ein komplexes Netz, in dem alles mit allem verbunden war. Eines Tages beschloss das Unternehmen, eine Version der Plattform in anderen Sprachen zu veröffentlichen. Zuerst schien es, dass es ausreichen würde, nur Sprachdateien hinzuzufügen, und jetzt werden wir die gesamte Benutzeroberfläche übersetzen lassen.

In der Praxis musste das gesamte Projekt neu erstellt werden. So sollen beispielsweise die Namen von Firmen und Produkten in der Datenbank nicht mehr nur in einer Sprache, sondern in jeder Sprache gespeichert werden. Aufgrund der Geschäftslogik war es unmöglich, Informationen zu duplizieren, es war notwendig, die Namen für alle Sprachen auf einmal zu speichern. Entsprechend führte dies zu Änderungen an den Schnittstellen von Kabinett und Innendienst. Schnittstellenänderungen erforderten Änderungen der Regeln zur Validierung eingehender Daten, Briefvorlagen aufgrund unterschiedlicher Endungsprinzipien in verschiedenen Sprachen, Änderungen von Tests usw.

Da alles mit allem verbunden war, wurde die Entscheidung getroffen, zusammen mit der Einführung neuer Sprachen auf eine Microservice-Architektur umzusteigen. Der Prozess des Übergangs von der monolithischen zur Microservice-Architektur dauerte mehr als ein Jahr.

Drittes Beispiel. Die Fintech-Plattform wurde auf einer alten Version von PHP und Laravel erstellt. Ein Upgrade auf neuere Versionen sowie der Wechsel der Datenbank von MariaDB auf PostgreSQL war praktisch unmöglich, da das gesamte Team mehrere Monate nur den Migrationsprozess bewältigen musste.

Neue Versionen von PHP und Laravel zu dieser Zeit konnten das Projekt und die Weiterentwicklung beschleunigen, aber die monolithische Architektur erlaubte keine Aktualisierung des Technologie-Stacks

.