Blogue
Wand.ai : Cas d'architecture agnostique Cloud Underlayer

Cas d'architecture agnostique Cloud Underlayer : solution élégante pour Wand.ai

Daniel Yavorovych
February 17, 2023

Comme vous l'avez peut-être deviné, notre coopération avec Wand.ai ne s'est pas arrêtée partie consultante. La raison pour laquelle nous avons poursuivi notre coopération sur le plan pratique réside dans le fait que Dysnix a proposé le projet de solutions de travail le plus complet par rapport aux autres entreprises engagées par Wand. Nous avons remporté ce « concours » grâce à notre expertise, notre concept était mieux décrit, plus technologique et plus complet en général.

L'équipe qui a travaillé sur le conseil s'est donc impliquée dans la réalisation pratique du projet de conseil. Comme auparavant, il s'agissait d'un architecte de solutions et de deux ingénieurs DevOps seniors. La charge de travail dépendait de l'étape de mise en œuvre, mais quoi qu'il en soit, le temps consacré au projet était suffisant pour couvrir tous les problèmes que nous avions prévus.

Contexte de la mise en œuvre

Revenons un peu en arrière pour avoir une vue d'ensemble de l'affaire. La fonction métier du futur produit qui devrait fonctionner sur l'architecture Dysnix consiste à créer des environnements mutualisés distincts pour les utilisateurs, capables de créer plusieurs pipelines de données métier personnalisés sur la base du principe du low-code et d'utiliser le pool de données collecté en leur appliquant des modèles AI/ML. Nous pouvons extraire les principales exigences de l'architecture à partir de cette description :

  • Les utilisateurs finaux sont des représentants des industries de la fintech, de la technologie médicale, du Web3 et des entreprises de différentes tailles qui pourraient avoir un besoin vital de lancer des services similaires dans des périmètres fermés. Cela signifie que l'architecture que nous devons créer doit être indépendante de la couche sous-jacente et peut être démarrée sur site ou dans le cloud avec le même succès.

Pour nous, en tant qu'architectes, cela signifie que nous devons sélectionner un ensemble unique d'outils qui fonctionneront comme, disons, un dénominateur commun qui nous donnera la possibilité de créer une telle architecture. Les exigences relatives à cette boîte à outils étaient encore relativement élevées : elle devait être composée d'outils fiables, standardisés, pris en charge et complémentaires. Nous ne pouvons donc pas nous fier à quelque chose de trop moderne ou d'exotique.

  • Les fonctions ETL de la future architecture doivent être parfaitement conçues, répondant à toutes les exigences de mutualisation : toutes les données d'un utilisateur final doivent être isolées des autres, tout doit être sécurisé et contrôlé à 100 % par le propriétaire. Le produit doit fonctionner de la même manière dans des environnements séparés, quel que soit le volume de charge. Peu importe si l'utilisateur final souhaite télécharger uniquement des données provenant de Google Analytics, ainsi qu'une feuille de calcul d'une seule page contenant les clients à analyser ou dix sources de données commerciales des 10 dernières années.

Du point de vue technique, nous comprenons que nous devons fournir des options de transfert, de stockage et de mise à l'échelle flexibles des données pour que tous les processus ETL se déroulent sans heurts. Sans une infrastructure prête à relever de tels défis, le produit ne fonctionnera pas.

  • Nous devions également nous soucier de la partie du produit réservée aux modèles ML. La connexion avec cette partie est essentielle pour apporter la valeur du produit aux utilisateurs finaux. Nous en avons également tenu compte lors de la conception de l'architecture du produit.

La pile technologique que nous sélectionnons doit inclure des technologies compatibles avec l'IA et le ML qui fonctionnent sans beaucoup de code supplémentaire ni intégrations complexes.

  • Un autre point qui nous tient toujours à cœur est le temps. Notre client doit disposer de suffisamment de temps pour développer, écrire le code à l'aide de nos guides d'architecture et livrer le produit le plus rapidement possible sur le marché.

Les délais serrés pour notre travail sont une exigence typique pour nous. Nous pouvons y faire face grâce à l'expertise accumulée dans le cadre de dizaines d'autres projets, à des inventions internes prêtes à l'emploi, à de nombreuses pratiques open source et à notre capacité à prendre les bonnes décisions techniques à court terme.

Les exigences étaient précises et nous avons poursuivi notre travail. Nous avons élaboré un plan pour faire bouger les choses.

Étapes du processus d'implémentation

Il s'agit d'une vue aérienne de l'ensemble du processus de mise en œuvre, du début au dernier moment de la coopération.

  • Étape de consultation : 2 semaines. En conséquence, le client a obtenu un concept technique d'architecture
  • Phase SOW + R&D : 2 mois.
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.  
  • Mise en œuvre de l'architecture : 2 mois.
  1. Tests de compatibilité : toutes les technologies sélectionnées ont été vérifiées pour garantir un travail efficace et cohérent.
  2. Préparation de la documentation et des conseils pour les développeurs pour chaque composant et processus
  • Développement du code : ~12 mois
  1. De notre côté, nous avons fourni des services d'assistance et de curation du développement.
  2. Le projet a été mené à bien.
  • Lancement du projet

La technologie et l'architecture du projet que nous avons créées

Pour répondre aux exigences du projet, nous avons créé une architecture indépendante du cloud et de la sous-couche sur la base de l'ensemble d'outils universel disponible pour des tâches similaires que nous avons effectuées précédemment.

Nous avons sélectionné avec soin l'ensemble d'outils et de technologies natifs de Kubernetes applicables à nos objectifs. Nous avons développé une solution utilisant k8s en raison de sa disponibilité, de sa standardisation, de sa prévisibilité et de son expérience dans l'utilisation de ces outils. Nous avons dû minimiser le nombre d'intégrations absentes ou la nécessité d'écrire du code supplémentaire, nous avons donc utilisé au maximum la solution réutilisable, ce qui était une approche assez « écologique », si l'on peut dire. Nous avons utilisé des outils basés sur Kuber non seulement pour les fonctionnalités mais également pour les opérations d'orchestration, tout a été extrait via le configurateur k8s.

Néanmoins, nous ne pouvons pas dire que notre ensemble créé soit devenu trop courant. La liste des outils inclut, sans toutefois s'y limiter :

  • Terraforme
  • Kubernetes
  • Flux CD
  • Prometheus Stack
  • Istio
  • Cluster ElasticSearch
  • Noyau Seldon
  • Préfet Orion
  • Jäger
  • Pile Ory

L'architecture qui s'est développée sur la base de ces outils était moderne, stable, prévisible, évolutive, automatisée et prise en charge. Rien ne pouvait donc entrer en conflit avec les exigences en matière de mutualisation ou de sécurité.

Les avantages que nous apportons au projet et les leçons que nous en avons apprises

Comme nous l'a montré la phase de développement, les problèmes que nous avons essayé de prévoir lors des phases de conseil ou de R&D n'étaient pas uniquement le fruit de notre imagination. Grâce à notre préparation, l'équipe de développement a évité de multiples impasses et jonctions concernant la sélection des outils et leur intégration, le suivi des bogues, la correction, ainsi que la rapidité de livraison et de déploiement.

Deux points doivent également être mentionnés concernant les avantages que nous avons présentés.

  1. Infrastructure en tant que code : avec cette approche appliquée, le client sera en mesure d'ajouter des modifications à l'infrastructure du projet en quelques minutes et de la mettre à niveau de manière fluide. L'ensemble de la configuration n'est pas une boîte noire pour l'équipe interne mais un guide expliqué de leur produit.
  2. Le système de traçage distribué est basé sur Istio/Jäger. Cette solution aidera les développeurs à détecter les problèmes dans l'ensemble de l'infrastructure en quelques minutes s'ils apparaissent.

En ce qui concerne les enseignements que nos ingénieurs ont tirés de ce projet, nous avons été ravis d'utiliser la pile d'outils préférée et de créer une autre solution authentique pour le client sur une base Kubernetes. Nous pensons que cette technologie restera irremplaçable pour tous les projets nécessitant une solution claire et élégante.

Si vous vous demandez si votre projet peut avoir une solution efficace, rencontrez personnellement nos architectes
Nous contacter
Daniel Yavorovych
CTO and Co-founder at Dysnix
Brainpower and problem-solver, meditating and mountain hiking.
Table des matières
Articles connexes
Abonnez-vous au blog
La meilleure source d'informations pour le service client, les conseils de vente, les guides et les meilleures pratiques du secteur. Joignez-vous à nous.
Merci de votre inscription au blog Dysnix
Vous serez désormais le premier à savoir quand nous publierons un nouvel article
J'ai compris
Oups ! Une erreur s'est produite lors de l'envoi du formulaire.
Copié dans le presse-papiers
Collez-le où vous voulez