Blog
Wand.ai: Beispiel für eine Cloud-Underlayer-unabhängige Architektur

Cloud Underlayer Agnostic Architecture Case: Elegante Lösung für Wand.ai

Daniel Yavorovych
February 17, 2023

Wie Sie vielleicht vermutet haben, hat unsere Zusammenarbeit mit Wand.ai nicht aufgehört beratender Teil. Der Grund, warum wir unsere Zusammenarbeit im praktischen Bereich fortgesetzt haben, liegt in der Tatsache, dass Dysnix im Vergleich zu anderen von Wand beauftragten Unternehmen das umfassendste Projekt an Arbeitslösungen anbot. Wir haben diesen „Wettbewerb“ mit unserer Expertise gewonnen. Unser Konzept war besser beschrieben, technisch versierter und im Allgemeinen umfassender.

Das Team, das an der Beratung gearbeitet hat, war also an der praktischen Umsetzung des Beratungsprojekts beteiligt. Nach wie vor waren es ein Solution Architect und zwei Senior DevOps Engineers. Die Arbeitsbelastung hing von der Implementierungsphase ab, aber trotzdem reichte die für das Projekt aufgewendete Zeit aus, um alle geplanten Probleme abzudecken.

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.
  1. Kompatibilitätstests: Alle ausgewählten Technologien wurden auf effiziente und kohärente Arbeit überprüft.
  2. Vorbereitung der Dokumentation und Anleitung für Entwickler für jede Komponente und jeden Prozess
  • Codeentwicklung: ~12 Monate
  1. Von unserer Seite aus haben wir Unterstützungsleistungen erbracht und die Entwicklung kuratiert.
  2. Das Projekt wurde erfolgreich abgeschlossen.
  • Start des Projekts

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.

  1. 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.
  2. 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.

Wenn Sie sich fragen, ob Ihr Projekt eine effiziente Lösung haben kann, lernen Sie unsere Architekten persönlich kennen
Kontaktiere uns
Daniel Yavorovych
CTO and Co-founder at Dysnix
Brainpower and problem-solver, meditating and mountain hiking.
Table of content
In die Zwischenablage kopiert
Fügen Sie es ein, wo immer Sie möchten