Hintergrund der Lösungsimplementierung
Lassen Sie uns einen Schritt zurücktreten, um das vollständige Bild des Falls zu sehen. Die Geschäftsfunktion des zukünftigen Produkts, das auf der Dysnix-Architektur funktionieren sollte, besteht darin, separate Mehrinstanzenumgebungen für Benutzer zu schaffen, die auf der Grundlage des Low-Code-Prinzips mehrere benutzerdefinierte Geschäftsdaten-Pipelines erstellen und den gesammelten Datenpool nutzen können, indem sie KI/ML-Modelle darauf anwenden. Aus dieser Beschreibung können wir die wichtigsten Anforderungen der Architektur ableiten:
- Bei den Endnutzern handelt es sich um Vertreter der Fintech-, Medtech- und Web3-Industrie sowie Unternehmen unterschiedlicher Größe, die möglicherweise unbedingt ähnliche Dienste in geschlossenen Räumen anbieten müssen. Das bedeutet, dass die Architektur, die wir erstellen müssen, unabhängig von der Unterschicht sein muss und vor Ort oder in der Cloud mit dem gleichen Erfolg gestartet werden kann.
Für uns als Architekten bedeutet das, dass wir einen einzigen Satz von Tools auswählen müssen, der, sagen wir, als gemeinsamer Nenner funktioniert, der uns die Möglichkeit gibt, eine solche Architektur zu erstellen. Die Anforderungen an diese Toolbox waren immer noch relativ hoch: Sie musste aus zuverlässigen, standardisierten, unterstützten und ergänzenden Tools bestehen. Wir können uns also nicht auf etwas verlassen, das viel zu modern oder exotisch ist.
- Die ETL-Funktionen der zukünftigen Architektur müssen einwandfrei konzipiert sein und alle Mehrmandantenanzanforderungen erfüllen: Alle Daten eines Endbenutzers sollten von anderen isoliert sein, und alles sollte gesichert sein und zu 100% in der Kontrolle des Eigentümers liegen. Das Produkt sollte in getrennten Umgebungen unter einer Last beliebiger Lautstärke gleich gut funktionieren. Ganz gleich, ob der Endnutzer nur Daten aus Google Analytics plus eine einseitige Tabelle mit Kunden zur Analyse hochladen möchte oder zehn Geschäftsdatenquellen der letzten 10 Jahre.
Aus technischer Sicht wissen wir, dass wir Datenübertragungs-, Speicher- und flexible Skalierungsoptionen bereitstellen müssen, damit alle ETL-Prozesse reibungslos ablaufen können. Ohne eine Infrastruktur, die für solche Herausforderungen bereit ist, wird das Produkt nicht funktionieren.
- Wir mussten uns auch darum kümmern, den Teil des Produkts für die ML-Modelle bereitzustellen. Die Verbindung mit diesem Teil ist unerlässlich, um den Endbenutzern den Wert des Produkts zu bieten. Dies haben wir auch bei der Entwicklung der Produktarchitektur berücksichtigt.
Der Tech-Stack, den wir auswählen, sollte KI/ML-kompatible Technologien enthalten, die ohne viel zusätzlichen Code oder komplexe Integrationen funktionieren.
- Ein weiterer Punkt, der uns immer wichtig ist, ist Zeit. Unser Kunde muss genug Zeit haben, um zu entwickeln, den Code mithilfe unserer Architekturleitfäden zu schreiben und das Produkt so schnell wie möglich auf den Markt zu bringen.
Die engen Termine für unsere Arbeit sind eine typische Anforderung für uns. Dank des Fachwissens, das wir in Dutzenden anderer Projekte gesammelt haben, dank vorgefertigter innerer Erfindungen, einer breiten Open-Source-Praxis und der Fähigkeit, kurzfristig die richtigen technischen Entscheidungen zu treffen, können wir damit umgehen.
Die Anforderungen waren präzise und wir fuhren mit unserer Arbeit fort. Wir haben einen Plan erstellt, um die Dinge in die Tat umzusetzen.
Etappen des Implementierungsprozesses
Dies ist der Hubschrauberblick auf den gesamten Implementierungsprozess vom Anfang bis zum letzten Moment der Zusammenarbeit.
- Beratungsphase: 2 Wochen. Als Ergebnis erhielt der Kunde ein technisches Architekturkonzept
- SOW + F&E-Phase: 2 Monate.
During this stage, we conducted technology benchmarking for selecting the best fit for the client. Each part of the architecture was analyzed during the search for best-tailored solutions and estimated the possibility of their implementation. For example, in selecting the tools for serving ML models, we’ve come up with Seldon Core after reviewing over 7 other products.
- Implementierung der Architektur: 2 Monate.
- Kompatibilitätstests: Alle ausgewählten Technologien wurden auf effiziente und kohärente Arbeit überprüft.
- Vorbereitung der Dokumentation und Anleitung für Entwickler für jede Komponente und jeden Prozess
- Codeentwicklung: ~12 Monate
- Von unserer Seite aus haben wir Unterstützungsleistungen erbracht und die Entwicklung kuratiert.
- Das Projekt wurde erfolgreich abgeschlossen.
Der technische Stack und die Architektur des Projekts, die wir gebaut haben
Um den Anforderungen des Projekts gerecht zu werden, haben wir die Cloud-/Underlayer-unabhängige Architektur entwickelt, die auf dem universellen Toolset basiert, das für ähnliche Aufgaben verfügbar ist, die wir zuvor abgeschlossen haben.
Wir haben die Kubernetes-nativen Tools und Technologien, die für unsere Ziele geeignet sind, von Hand ausgewählt. Aufgrund der Verfügbarkeit, Standardisierung, Berechenbarkeit und Erfahrung im Umgang mit diesen Tools haben wir eine Lösung mit k8s zusammengestellt. Wir mussten die Anzahl fehlender Integrationen oder die Notwendigkeit, zusätzlichen Code zu schreiben, minimieren, also haben wir einfach das Maximum der wiederverwendbaren Lösung genutzt, was, wenn wir das so sagen dürfen, ein ziemlich „ökologischer“ Ansatz war. Wir verwendeten Kuber-basierte Tools nicht nur für die Funktionalität, sondern auch für Orchestrierungsoperationen. Alles wurde über den k8s-Konfigurator abgerufen.
Dennoch können wir nicht sagen, dass unser kreiertes Set zu häufig geworden ist. Die Liste der Tools umfasst, ist aber nicht beschränkt auf:
- Terraform
- Kubernetes
- Flux CD
- Prometheus-Stapel
- Istio
- ElasticSearch-Cluster
- Seldon Core
- Präfekt Orion
- Jäger
- Ory-Stapel
Die Architektur, die auf der Grundlage dieser Tools wuchs, war modern, stabil, erwartbar, skalierbar, automatisiert und unterstützt. Somit konnte nichts im Widerspruch zu den Anforderungen von Mehrmandantenfähigkeit oder Sicherheitsfragen stehen.
Vorteile, die wir in das Projekt einbringen, und Lektionen, die wir gelernt haben
Wie uns die Entwicklungsphase gezeigt hat, waren die Probleme, die wir in der Beratungs- oder F&E-Phase vorhersehen wollten, nicht nur in unserer Vorstellung. Bei unserer Vorbereitung vermied das Entwicklungsteam mehrere Sackgassen und Knotenpunkte in Bezug auf die Toolauswahl und deren Integration, Fehlerverfolgung, Behebung und schnelle Lieferung und Bereitstellung.
Zwei Punkte sollten auch in Bezug auf die Vorteile erwähnt werden, die wir auf den Tisch gebracht haben.
- Infrastruktur als Code: Mit diesem Ansatz kann der Kunde innerhalb von Minuten alle Änderungen an der Infrastruktur des Projekts vornehmen und diese nahtlos aktualisieren. Das gesamte Setup ist keine Blackbox für das interne Team, sondern eine erläuterte Anleitung zum Produkt.
- Das verteilte Tracing-System basiert auf Istio/Jaeger. Diese Lösung hilft Entwicklern, Probleme in der gesamten Infrastruktur innerhalb von Minuten zu finden, wenn sie auftreten.
In Anbetracht dessen, was unsere Ingenieure aus diesem Projekt gelernt haben, waren wir froh, den beliebtesten Tool-Stack zu verwenden und eine weitere echte Lösung für den Kunden auf Kubernetes-Basis zu entwickeln. Wir glauben, dass diese Technologie für alle Projekte, die eine klare und elegante Lösung benötigen, unersetzlich bleiben wird.
.jpg)
.jpg)
