Retour d’expérience client : couverture de l’ensemble de la chaine de valeur IT et digitale

Pouvez-vous nous présenter l’activité de votre client ? Quels étaient ses enjeux ?

Le client est un acteur de la protection sociale complémentaire, un assureur à vocation sociale à but non lucratif.

Dans le cadre de la modernisation de son système d’information, notre client conduit un programme de transformation quant à la refonte de sa solution Data et BI actuellement on-premise.

D’une part, le but est d’agréger la totalité des sources de données actuelles sous une unique application.

D’autre part, afin de répondre au besoin de performance de traitement de données et dans le but de rationaliser les coûts, il a été décidé de migrer la plateforme data on-premise vers le cloud Ms Azure en se basant sur la solution Azure Synapse Analytics. Ce service réunit à la fois le moteur d’intégration de données Azure Data Factory ainsi que les technologies SQL pour l’entreposage de données et Spark pour le big data.

A quelles étapes du projet êtes-vous intervenus ?

Dans le cadre de la mise en place de cette nouvelle plateforme, nous avons tout d’abord réalisé le cadrage du projet, afin de :

• Designer l’architecture cible sur Ms Azure ;
• Identifier les différents prérequis nécessaires à la mise en place du tenant Ms Azure selon les best practices de gestion et de sécurité ;
• Formaliser une analyse budgétaire des services et consommations cibles avec recommandation de dispositif FinOps à mettre en œuvre pour maitriser les coûts futurs ;
• Proposer un plan d’actions de mise en place du projet et un calendrier associé.

Nous avons ensuite réalisé l’ensemble de la phase de conception de l’architecture technique Azure, incluant la définition du plan de migration des données.

Enfin, nous avons mis en œuvre un PoC de l’architecture technique préalablement conçue. L’objectif était de challenger les choix techniques du client et de confirmer la faisabilité du projet ainsi que sa pertinence vis-à-vis des besoins exprimés.

Comment étaient répartis les rôles au sein de l’équipe Almond ?

Ayoub était le garant de l’expertise technique et data durant la première phase de cadrage du projet.

Il s’est dans un premier temps concentré sur la conception d’une architecture de Data Warehouse moderne basée sur le service analytique du cloud Microsoft (Azure Synapse Analytics) et l’outil de data visualisation Tableau puis sur la modélisation des scénarios d’ingestion des données on-premise vers la nouvelle plateforme cloud.

Udaya était d’une part le chef de projet garant de l’atteinte des objectifs, et d’autre part, pilote des segments cloud, accompagné des équipes d’ingénieurs cloud, afin de :

• Concevoir l’architecture cible de la plateforme cloud ;
• Définir les mesures de sécurisation, protection et continuité des données ;
• Définir la trajectoire de build des environnements ;
• Modéliser l’ensemble des scénarios budgétaires en build et en run avec recommandations.

Nos équipes cloud sont intervenues sous plusieurs casquettes :

• Cloud Architect : notamment en charge d’accompagner le client dans ses choix techniques, tout en veillant à l’optimisation des coûts opérationnels de la plateforme data dès la phase de conception selon les best practices FinOps.
• Data Architect : en charge de travailler avec les équipes data du client pour mettre en place l’entrepôt de données et développer la logique d’ingestion et de transformation de données sur Azure.
• DevOps : en charge de l’ensemble de l’automatisation du déploiement de l’infrastructure cloud via Terraform ainsi que de toute la partie automatisation des livraisons de pipelines d’extraction, de transformation et de chargement de données (ELT/ETL) à l’aide d’Azure DevOps.

Comment ont été intégrés les aspects budgétaires lors du projet ?

L’axe budgétaire a été pris en considération pendant toutes les phases de ce projet et cela dès la phase de Build.

Durant la phase de développement du nouveau Datawarehouse, nous avons travaillé sur des instances Azure Synapse Dedicated pool à puissance réduite de 100 DWUs (Data Warehouse Units). La puissance choisie était largement suffisante pour développer et mettre en place le DWH tout en bénéficiant du traitement massif parallèle des données MPP (Massively Parallel Processing).

Enfin, pour valider les performances du nouveau DWH et recetter les développements réalisés, il a fallu tester en préproduction sur des instances plus puissantes et qui étaient ressemblantes à celles déployées en production.

Les différents tests réalisés en préproduction ont permis d’affiner le besoin du client et de réfléchir à d’autres optimisations afin de réduire les coûts opérationnels.

Nous avons pu constater qu’une durée maximale de 2h/jr était nécessaire pour faire tourner les pipelines ETL du client.

Nous avons donc réfléchi à une logique applicative permettant de mettre à disposition les ressources Azure telles que les Dedicated SQL Pool et les Self-hosted integration runtime (permettant de collecter la donnée depuis le réseau On-Premise du client) uniquement durant ces créneaux-là, et d’éviter de payer pour du compute non utilisé durant le reste de la journée.

La solution était donc de mettre en place une logique de start & stop à travers des activités de Pipeline qui allument les ressources avant chaque collecte de données (à 6h du matin) et les éteignent à la fin du pipeline ETL.

Quel regard avez-vous porté sur la dimension FinOps du projet ?

Un tel projet vise à faciliter la prise de décision à tous les niveaux de l’entreprise. Ici les optimisations techniques ont permis de réduire les coûts de la nouvelle plateforme data. Ce qui a permis à notre client d’investir ce budget dans l’achat de licences Dataviz : Tableau Software pour l’ensemble des métiers.

Dans les projets cloud, il faut prendre en compte chaque petite action et cela durant toutes les étapes du projet. Par ailleurs, il est très important de comprendre chaque paramètre avant le choix d’une nouvelle ressource. Enfin, il faut veiller à mettre des limites à l’élasticité de son cloud en exploitant les mécanismes mis à disposition par les hyperscalers.

Aujourd’hui, le FinOps est un vecteur indissociable de toute transformation cloud. Tirer profit des leviers que promet le cloud n’est possible qu’en incluant cette approche, notamment pour justifier le ROI des projets engagés au regard de la création de valeur pour le métier.

Les mesures FinOps doivent être prises en amont d’un projet cloud, en suivre sa progression et être maintenues en phase d’exploitation :

• Depuis la création de la landing zone ;
• En amont de la migration par une phase d’assessment des ressources ;
• Pendant la migration, en passant par une phase probatoire d’évaluation du comportement des ressources puis en les dimensionnant au plus juste et en fin en sélectionnant les bonnes instances à réserver ;
• En phase d’exploitation, en ayant une gouvernance dédiée via une fonction FinOps, en pilotant la consommation des actifs via des outils et dashboards dédiés ainsi qu’en optimisant de manière continue ses infrastructures/architectures au regard des fonctionnements applicatifs.