Get best of the week

Wie wir das Problem der drei Monolithen gelöst haben

In den Strategien der meisten Unternehmen wird die Digitalisierung zunehmend erwähnt: Einige Unternehmen versuchen, moderne Technologien (z. B. Big Data, IoT, AI, Blockchain) zu implementieren, während andere überall ihre internen Prozesse automatisieren. Trotz wachsender Anstrengungen und Investitionen in die Systemimplementierung sehen viele die Ergebnisse als mittelmäßig an. Im Idealfall sollten moderne Unternehmen in der Lage sein, schnell neue digitale Produkte zu erstellen oder sich in beliebte Dienste von Drittanbietern zu integrieren. Prozesse über ihre Organisation hinausführen; in der Lage sein, effektiv mit Partnern zu interagieren und gleichzeitig die Isolation ihrer Prozesse aufrechtzuerhalten. Sie müssen außerdem in der Lage sein, Daten nicht nur zu erfassen, sondern auch schnell darauf zuzugreifen und zu verwalten. Selbst reife Unternehmen stehen jedoch vor der Herausforderung, Daten zu transformieren und zu verwalten.mit ständigem Wettbewerb der Geschäftsprioritäten. Was hindert sie daran, Perfektion zu erreichen? 

Die Erfahrung unseres DTG-Teams bei der Erstellung digitaler Produkte und Dienstleistungen ermöglicht es uns festzustellen, dass die Lösung dieser Probleme durch das Problem der drei Monolithen behindert wird: Anwendungsmonolith, Integrationsmonolith und Datenmonolith . Sie sind das Ergebnis der ererbten Paradigmen traditioneller Architektur, Kultur, die sich auf verfügbare Daten stützen und in einem „geschichteten“ System arbeiten, in dem die Isolation der IT-Abteilung und des Geschäfts zum Verlust von Daten und Wissen über sie führt. Als Lösung für dieses Problem sehen wir einen Übergang von traditionellen Entwicklungs- und Managementansätzen zu verteilten Ansätzen, der gravierende technische und kulturelle Veränderungen in der Organisation impliziert.

Aber das Wichtigste zuerst. Lassen Sie uns kurz beschreiben, was die berüchtigten Monolithen sind, und dann werden wir zu den Lösungen übergehen, die wir vorschlagen, um die durch Monolithen verursachten Schwierigkeiten zu überwinden.


Anwendung Monolith


Eines der drei Architekturprobleme beim Erstellen von Unternehmenslösungen ist der Monolith von Anwendungen , der auftritt, wenn einer vorhandenen Anwendung immer mehr Funktionen hinzugefügt werden. Im Laufe der Jahre verwandelt sich die Anwendung in ein "Monster" mit vielen verwobenen Funktionen und voneinander abhängigen Komponenten, was die folgenden negativen Punkte mit sich bringt:

  • das Vorhandensein eines einzelnen Fehlerpunkts (im Falle eines Fehlers in einem der Anwendungsmodule schlägt die gesamte Anwendung fehl und alle Mitarbeiter, die mit dieser Anwendung arbeiten, funktionieren nicht mehr);
  • Schwierigkeiten bei der Sicherstellung der erforderlichen Qualität des entwickelten Produkts, Notwendigkeit volumetrischer Regressionstests;
  • ein monolithisches Team, dessen Erweiterung nicht praktikabel ist, da dies den Entwicklungsprozess nicht beschleunigt und erleichtert;
  • , ; , ; 
  • ( -). , , « ». ;
  • .

Microservices helfen, die beschriebenen Probleme zu überwinden. Die Bedeutung des Ansatzes besteht darin, dass eine monolithische Anwendung in mehrere kleine Anwendungen unterteilt ist, die aus einer Gruppe von Diensten bestehen. 


Im Gegensatz zu monolithischen Anwendungen bietet dies eine viel größere Skalierbarkeit als der monolithische Ansatz, da es möglich wird, hoch belastete Dienste nach Bedarf und nicht die gesamte Anwendung zu skalieren. Mit Microservices können mehrere Teams in einer Organisation unabhängig voneinander arbeiten und nach eigenem Ermessen neue Funktionen veröffentlichen.

Obwohl die Idee der Modularität seit vielen Jahren besteht, bietet die Architektur von Microservices eine viel größere Flexibilität, sodass Unternehmen schneller auf sich ändernde Marktbedingungen reagieren können.

Glauben Sie jedoch nicht naiv, dass Microservices Ihre IT-Umgebung vollständig vor Komplexität bewahren. Mit dem Aufkommen von Microservices gibt es einen Kompromiss, um die Entwicklungsflexibilität zu erhöhen und gleichzeitig die Komplexität von Management, Entwicklung und Support aufgrund ihrer Dezentralisierung zu erhöhen. Darüber hinaus ist nicht jede Anwendung in einer Unternehmensumgebung für die Microservice-Architektur geeignet.

Integrationsmonolith


Das zweite Architekturproblem, der Integrationsmonolith, hängt mit der Verwendung des Integrations-Unternehmensbusses ( Enterprise Service Bus , ESB) zusammen. Dies ist ein Architekturmuster mit einer einzigen unternehmensweiten Interaktionsschicht, die ein zentrales und einheitliches ereignisorientiertes Messaging bietet. 


Bei diesem traditionellen Ansatz wird die Integration als Zwischenschicht zwischen Schichten von Datenquellen und ihren Verbrauchern angesehen. ESB bietet Dienste an, die von vielen Systemen in verschiedenen Projekten verwendet werden. Der ESB wird von nur einem Integrationsteam verwaltet, das sehr qualifiziert sein muss. Darüber hinaus ist es schwierig zu skalieren. Aufgrund der Tatsache, dass das ESB-Team der „Engpass“ des Projekts ist, ist es schwierig, Änderungen und eine wachsende Anzahl von Verbesserungen vorzunehmen:

  • Die Integration ist im Rahmen der nächsten Version nur über den Bus möglich. Aufgrund des großen Datenflusses in wenigen Monaten ist es besser, einen Antrag zu stellen.
  • Änderungen können nur vorgenommen werden, wenn sie mit anderen Verbrauchern vereinbart wurden, da nicht alles zerlegt und isoliert ist. Die technische Verschuldung nimmt zu und nimmt mit der Zeit nur zu. 

In monolithischen Architekturen „ruhen“ Daten. Das gesamte Geschäft basiert jedoch auf Streaming-Ereignissen und erfordert schnelle Änderungen. Und wo sich alles sehr schnell ändert, ist der Einsatz von ESB unangemessen. 

Um diese Probleme zu lösen, hilft der Agile Integration-Ansatz, der keine einzige zentralisierte Integrationslösung für das gesamte Unternehmen oder ein einziges Integrationsteam impliziert. Dabei erscheinen mehrere funktionsübergreifende Entwicklungsteams, die wissen, welche Daten sie benötigen und welche Qualität sie haben sollten. Ja, mit diesem Ansatz kann die geleistete Arbeit dupliziert werden, aber Sie können die Abhängigkeit zwischen verschiedenen Teams verringern und hauptsächlich die parallele Entwicklung verschiedener Dienste leiten.

Datenmonolith


Das dritte, aber nicht weniger wichtige Architekturproblem ist das Problem des Datenmonolithen, das mit der Verwendung eines zentralisierten Unternehmens-Data-Warehouse ( Enterprise Data Warehouse) verbunden ist, EDW). EDW-Lösungen sind teuer, sie enthalten Daten in einem kanonischen Format, das aufgrund spezifischer Kenntnisse nur von einem Team von Spezialisten unterstützt und verstanden wird, das allen dient. Daten in EDW stammen aus verschiedenen Quellen. Das EDW-Team überprüft sie und konvertiert sie in ein kanonisches Format, das die Anforderungen verschiedener Verbrauchergruppen innerhalb der Organisation erfüllen sollte, und das Team wird geladen. Darüber hinaus können Daten, die in ein bestimmtes kanonisches Format konvertiert wurden, nicht für alle und immer bequem sein. Fazit: Die Arbeit mit den Daten dauert zu lange. Dementsprechend ist es nicht möglich, ein neues digitales Produkt schnell auf den Markt zu bringen.


Eine solche Ausrichtung auf die zentrale Komponente, ihre Abhängigkeit von Änderungen in den umgebenden Systemen, ist ein echtes Problem bei der Entwicklung neuer digitaler Prozesse und der Planung ihrer Verbesserungen. Änderungen können widersprüchlich sein und ihre Koordination mit anderen Teams verlangsamt die Arbeit weiter. 

Um das Problem des Datenmonolithen zu lösen, wurde das unstrukturierte Datenrepository Data Lake erfunden.. Der Hauptunterschied besteht darin, dass „Rohdaten“ in Data Lake geladen werden. Es gibt kein einziges Team, das mit ihnen arbeitet. Wenn ein Unternehmen Daten zur Lösung seines Problems benötigt, wird ein Team gebildet, das die für eine bestimmte Aufgabe erforderlichen Daten extrahiert. In der Nähe kann ein anderes Team dasselbe für eine andere Aufgabe tun. So wurde Data Lake eingeführt, damit mehrere Teams gleichzeitig an ihrem Produkt arbeiten können. Dieser Ansatz impliziert, dass die Daten in verschiedenen Domänen dupliziert werden können, da die Teams sie in eine Form konvertieren, die für die Entwicklung ihres Produkts geeignet ist. Hier tritt das Problem auf - das Team muss über Kompetenzen verfügen, um mit verschiedenen Datenformaten arbeiten zu können. Dieser Ansatz birgt zwar das Risiko zusätzlicher Kosten,verleiht dem Unternehmen eine neue Qualität und wirkt sich positiv auf die Geschwindigkeit der Erstellung neuer digitaler Produkte aus.

Und nur wenige fortgeschrittene Unternehmen verwenden einen noch „ausgereifteren“ Ansatz für die Arbeit mit Daten - das Data Mesh , das die Prinzipien der beiden vorherigen erbt, aber ihre Mängel beseitigt. Die Vorteile von Data Mesh sind Echtzeit- Datenanalysenund niedrigere Kosten für die Verwaltung der Big-Data-Infrastruktur. Der Ansatz begünstigt die Stream-Verarbeitung und impliziert, dass das externe System einen Datenstrom bereitstellt, der Teil der Quelllösungs-API wird. Die Datenqualität liegt in der Verantwortung des Eigentümers des Systems, das diese Daten generiert. Um diesen Ansatz zu maximieren, ist eine strengere Kontrolle darüber erforderlich, wie Daten verarbeitet und angewendet werden, um zu vermeiden, dass „Menschen in eine Reihe bedeutungsloser Informationen geraten“. Dies erfordert eine Änderung des Denkens des Managements und des Teams hinsichtlich der Art und Weise, wie die Interaktion der IT mit dem Unternehmen aufgebaut wird. Dieser Ansatz funktioniert gut in einem produktorientierten Modell und nicht in einem projektorientierten.

Eine solche Dateninfrastruktur eröffnet eine völlig andere Perspektive und erleichtert den Übergang vom Status „Speichern von Daten“ zum Status „Reagieren auf Daten“. Durch die Stream-Verarbeitung können digitale Unternehmen beim Generieren von Daten sofort auf Ereignisse reagieren und auf intuitive Weise Analysedaten und Echtzeiteinstellungen von Produkten oder Dienstleistungen abrufen, mit denen das Unternehmen seinen Wettbewerbern einen Schritt voraus ist.

Verteilte Ansätze


Zusammenfassend ist die Lösung für die Probleme aller aufgelisteten Monolithen:

  • Aufteilung des Systems in separate Blöcke, die sich auf Geschäftsfunktionen konzentrieren;
  • die Zuweisung unabhängiger Teams, von denen jedes eine Geschäftsfunktion schaffen und betreiben kann;
  • Parallelisierung der Arbeit zwischen diesen Teams, um die Skalierbarkeit und Geschwindigkeit zu erhöhen.

Es gibt keine einfachen Lösungen für den Aufbau der IT-Infrastruktur einer modernen Organisation. Und der Übergang von traditioneller zu verteilter Architektur ist nicht nur eine technische, sondern auch eine kulturelle Transformation. Es erfordert Änderungen im Denken in Bezug auf das Zusammenspiel von Geschäfts- und Informationssystemen. Und wenn es früher monolithische Anwendungen in der Organisation gab, funktionieren jetzt Tausende von Diensten, die in Bezug auf Schnittstellen und Daten verwaltet, gewartet und verglichen werden müssen. Dies erhöht die Kosten, erhöht die Anforderungen an die Fähigkeiten der Mitarbeiter und das Projektmanagement. Die IT-Abteilung und das Unternehmen müssen zusätzliche Aufgaben übernehmen. Wenn sie lernen, mit dieser Komplexität umzugehen, kann das Unternehmen mit dieser Infrastruktur auf Marktherausforderungen mit einer neuen, höheren Qualität reagieren.

Und jetzt, wo genau sind wir?Verwenden wir DTG als Lösung für das „Problem der Monolithen“, wenn wir die digitalen Prozesse unserer Kunden und deren Integration in das Ökosystem der Partner optimieren? Unsere Antwort ist die Klasse der Digital Business Technology Platform (siehe Gartner Analytics-Klassifizierung). Wir haben sie GRANUM genanntund basiert traditionell auf einer Kombination von Open Source-Technologien, mit denen wir schnell und einfach komplexe verteilte Systeme in einer Unternehmensumgebung erstellen können. Wir werden im Folgenden näher auf Technologien eingehen. Was ist einfacher und schneller geworden? Mithilfe der Plattform haben wir die Integration bestehender Kunden-IT-Plattformen, Kundeninteraktionssysteme, Datenmanagement, IoT und Analytics erheblich beschleunigt und konnten Kundensysteme schnell in Ökosystempartner integrieren, um Geschäftsereignisse zu bewältigen und gemeinsame Entscheidungen zur Schaffung eines gemeinsamen Werts zu treffen. Der Einsatz von Open Source-Technologien hat uns auch dabei geholfen, auf Kundenanfragen im Zusammenhang mit der Vermeidung von lizenzierter Software zu reagieren. 

Aus technischer Sicht konnten wir während der Digitalisierung von Prozessen mithilfe einer verteilten Architektur (Microservices und DataMesh-Ansatz) die gegenseitige Abhängigkeit von Komponenten verringern und das Problem einer komplexen und langwierigen Entwicklung lösen. Darüber hinaus konnten wir Streaming-Ereignisse in Echtzeit verarbeiten, die Datenqualität erhalten und eine vertrauenswürdige Umgebung für die Interaktion mit Partnern schaffen.


Die Plattform kann in drei logische Schichten unterteilt werden. 

  1. Die unterste Schicht ist die Infrastruktur. Entwickelt, um grundlegende Dienstleistungen bereitzustellen. Dies umfasst Sicherheit, Überwachung und Analyse von Protokollen, Containerverwaltung, Netzwerkrouting (Load Balancing) und Devops. 
  2. Integrationsschicht - unterstützt eine verteilte Architektur (DataMesh-Ansatz, Microservices und Streaming-Datenverarbeitung).
  3. — . (track&trace), , . . 

Lassen Sie uns genauer auf die von uns ausgewählten Open-Source-Technologien eingehen. Welche von ihnen werden von führenden Internetunternehmen wie Netflix, LinkedIn und Spotify in ihrer Best Practice verwendet? Die Technologien von Kubernetes, Jenkins, Keycloak, Spring Boot, Fluentd, Grafana und Prometheus werden ausgewählt, um den Anwendungsmonolithen zu bekämpfen und die Microservice-Architektur aufzubauen und damit zu arbeiten sowie um Flexibilität und Geschwindigkeit der Änderungen zu erreichen. Um sich von einer monolithischen Architektur zu entfernen, verwendet der Agile Integration-Ansatz normalerweise Apache Camel, NiFi und WSO2 API Manager. Und schließlich sind Kafka, Flink und Salase Event Portal nützlich, um das Problem des Datenmonolithen, seine Partitionierung und den Übergang zur Echtzeitdatenanalyse mithilfe des Data Mesh-Ansatzes zu lösen.

Die folgende Abbildung zeigt eine Reihe von Technologien, die wir als Ergebnis von Experimenten bei der DTG als optimal für die Lösung des Problems der drei Monolithen angesehen haben.


Wir haben vor etwa einem Jahr mit der praktischen Anwendung der beschriebenen Plattform begonnen und können bereits heute zu dem Schluss kommen, dass eine solche Lösung unabhängig von der Branche für Unternehmen von Interesse ist, die daran denken, die Kosten für die Ausführung ihrer Geschäftsprozesse zu senken, die Effizienz der Interaktion mit Partnern zu steigern und zu schaffen neue Wertschöpfungsketten. Solche Unternehmen zielen auf schnelle digitale Flussexperimente (Hypothesentest, Integration, schnelle Markteinführung und, falls lokaler Erfolg, globale Implementierung) ab und werden auch neue Kommunikationskanäle mit Kunden eröffnen und eine intensivere digitale Kommunikation mit ihnen aufbauen die Welt. 

In unserer Unternehmensgruppe sind immer interessante Stellen offen . Wir warten auf Sie!

More articles:


All Articles