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.
- Tests de compatibilité : toutes les technologies sélectionnées ont été vérifiées pour garantir un travail efficace et cohérent.
- Préparation de la documentation et des conseils pour les développeurs pour chaque composant et processus
- Développement du code : ~12 mois
- De notre côté, nous avons fourni des services d'assistance et de curation du développement.
- Le projet a été mené à bien.
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.
- 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.
- 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.
.jpg)
.jpg)
