Comprendre et maîtriser les coûts de Microsoft Fabric

Phare Data

0:00Dans Fabric, consommer des CU est facile. Savoir combien elle vous coûte, pourquoi et comment optimiser la facture, c'est là que la solution gratuite open source et communautaire Fabric Coston Analysis FCA entre en jeu. Ouais, bonjour et bienvenue sur Fardata, la chaîne qui éclaire vos données. Aujourd'hui, nous allons aborder une question très concrète. Comment comprendre et optimiser réellement les coûts de Microsoft Fabric ? Avec Fabric, nous avons pour suivre la consommation des capacités en terme de CU. Cependant, dès lors qu'on adopte une approche FinOPS, d'autres questions surgissent rapidement. Quel est le coût réel de la consommation ? Quel est le coût de stockage du Oneelx ? Sachant qu'il est exclu du prix de la capacité, quel est l'impact sur le coût global et surtout où se situe des opportunités d'optimisation. Connaître sa consommation est une chose, être capable de la traduire en coup, de l'expliquer, d'optimiser et en est tout ou une autre. C'est précisément l'objectif du FCA et de la session qu'on va vous présenter aujourd'hui. Chez Farata, notre objectif est simple, vous aider à y voir plus clair dans l'univers des données, de l'analyse et de l'intelligence artificielle. Chaque épisode est préparé par des passionnés, animés par l'envie de partager, d'apprendre et de rendre ces sujets utiles au plus grand nombre. Fardata est une plateforme ouverte. Alors n'hésitez pas à nous suggérer des thèmes ou même à partager votre expertise dans un prochain épisode. Et si le contenu vous plaît, pensez à vous abonner pour ne manquer aucune de nos prochaines publications. De la session d'aujourd'hui, on va aborder le FinOPS, on va aborder Microsoft Fabric et la solution FCA. On va vous partager aussi quelques retours terrain et j'ai le plaisir d'accueillir aujourd'hui Manel et Antoine qui sont les co-créateurs de la solution FCA. Bonjour et merci d'être parmi nous aujourd'hui. Je vous laisse vous présenter. Merci Romain. Bonjour moi c'est M Alomanie. Je suis clou de chaîne architecte data chez Microsoft de France. Bonjour Romain merci de nous avoir invité. Moi c'est Antoine Richer. Je suis aussi club Solution architecte dans les équipes d'Atania avec Manel. On va rentrer dans le vif du sujet et avant peut-être d'évoquer le Phinops, est-ce que Manel, tu peux nous rappeler qu'est-ce que le Phinops ?

FinOps

2:18Oui, bien sûr. Déjà, on voulait être très clair. On voulait insister sur le fait que le FINOPS n'a pas pour objectif de réduire vos coûts, mais de tirer un maximum de profit de votre utilisation des ressources cloud. Concrètement, au lieu de consommer plus, vous consommez mieux en exploitant au maximum les ressources qui sont mises à votre disposition. On en parle beaucoup aujourd'hui car c'est un domaine en pleine expansion. contenu à la fois de l'augmentation de certains coûts euh notamment liés à l'utilisation de l'IA, mais aussi dans une démarche de développement durable qui consiste à gaspiller le moins de ressources possibles. Et aujourd'hui, on le voit énormément parce qu'en fait tous les modèles économiques qui sont basés sur le cloud ont permis à d'innombrables métiers et business de se développer grâce à des architectes sur cloud qui sont décentralisés, adaptés aux besoins clients, facilement scalables, avec toute une couche agentique. Mais malheureusement ce constat vient aussi avec un coût. Cette facilité d'abscaler ou cette facilité à utiliser les différents outils IA peut vite entraîner un dépassement du chiffrage initialement prévu. C'est dans ce contexte là où le FINOPS intervient en permettant de mieux contrôler les coûts, en optimisant l'usage des ressources plutôt qu'en les augmentant. Si on regarde les priorités d'être dirigeants aujourd'hui, le message est assez clair. La priorité numéro 1 reste l'optimisation des workload et la réduction du gaspillage avec plus de 40 % des attentes sur le schéma qu'on voit. Ensuite, on voit une montée forte de la gouvernance, pas surprenant, de l'alignement des équipes et de l'extension du phinops à plus de périmètres. La capacité à prévoir les coûts et à les allouer correctement devient alors essentiel. Et ces nouveaux périmètres par exemple sont des sujets émergents comme la FINAPS pour l'IA ou le multicloud. On va évoquer tout au long de notre session ces différents sujets. Ouais, très bien. Et en effet, si on regarde le coût de la donnée, on voit qu'elle augmente naturellement tout au long de son cycle de vie. à chaque étape, que ce soit l'ingestion, son stockage, sa transformation, sa modélisation, ben tous ces étapes ajoutent finalement un coût à notre donnée, mais la valeur, elle n'apparaît vraiment qu'à la fin quand la donnée devient exploitable par le métier. C'est là que le Phinops devient clé avec la notion de unité d'unité économique. L'objectif, c'est de mesurer le coût par usage métier. Autrement dit, on cherche à aligner les dépenses techniques avec la valeur business réellement générée. Si ma plateforme coûte X mais qu'elle me rapporte X + 10, bah tout va bien. Sinon, il faudrait optimiser. Tout l'enjeu, c'est donc de reconnecter le coût de la donnée à sa valeur, à sa vraie valeur une fois activée.

Microsoft Fabric

4:52Maintenant que nous avons compris le Phinops, voyons pourquoi Fabricie. Microsoft Fabric c'est une plateforme de données, on le cite souvent unifiée. On peut la comparer à un système d'exploitation comme Windows. La fondation c'est le oneel leg, c'est notre stockage unifié pour les données. Puis au-dessus, on a une capacité partagée pour le calcul et les briques transverses comme la gouvernance, la sécurité et les workspace. Au lieu d'avoir une multitude d'outils séparés, vous avez un seul environnement qui regroupe tous les workloads en gestion, data engineering, data science et cetera. finalement moins de silo, plus de cohérence et surtout une bien meilleure maîtrise des coûts et des usages. Dans Microsoft Fabric, on y rassemble l'ingénierie des données, la science des données, l'informatique décisionnelle et bien d'autres he on voit des bases de données relationnelles maintenant et bien plus encore. Donc c'est vraiment un environnement unifié. Mais du coup, quels sont les facteurs qui influencent le coût de microsas Fabric ? On va regarder ça un peu plus dans le détail. Ben déjà la première chose qui va influencer justement les coûts de Fabric et c'est quelque chose à laquelle on pense pas forcément, ce sont les différentes licences qu'on doit utiliser quand on est en train de développer dans Microsoft Fabric ou quand on veut consommer des ressources dans Microsoft Fabric. On retrouve notamment la licence free qui va nous permettre un petit peu de tester ce que Microsoft Fabric peut faire mais uniquement dans notre espace de travail personnel. c'est elle est elle est dédiée plus à du test et à plus à des projets personnels. Ensuite, on va avoir la licence pro qui sera utilisée en fait pour de la self service ou et notamment aussi pour toute la partie collaboration et partage et euh et euh et la sécurité dont Microsoft Fabric. Et enfin, on va retrouver les licences PPU PPU ou PowerBI Premium user euh qui vont nous donner des fonctionnalités un peu plus avancées comparé aux licences pro. On peut citer un utilisateur free a la capacité sur une capacité Fabric de créer des items sans qu'il ait besoin d'avoir une pro hein. Le Pro est vraiment porté pour les activités PowerBind, hein. Ouais, tout à fait. Ensuite euh un autre coup, c'est plutôt les capacités Fabric qui sont conçues pour être partagé. Euh étant donné qu'on est sur la même plateforme, on a la même unité de mesure, donc on a la possibilité de partager justement cette capacité Fabric entre différents euh euh scénarios et use case. À l'intérieur de Fabric. On peut faire du data warehousing, du data engineering, de l'intégration de données, de la data science, du reporting. Donc on a la possibilité en fait d'utiliser la même capacité pour différents workload. Ensuite, on a aussi la possibilité de partager cette même capacité entre différents espaces de travail et du coup entre différents projets. Et enfin, on a la possibilité de partager cette capacité entre différents utilisateurs, notamment tous les utilisateurs qui veulent consommer des rapports, qui veulent voir euh euh différentes reportings, on a la possibilité en fait de leur donner accès à la même capacité via différents rapports et via différents projets. Alors Antoine, tu peux nous parler concrètement comment ça se passe la création d'une capacité ? Est-ce qu'on peut en faire ?

Azure

8:15Tout à fait. Ben comme le disait Manel jusqu'à présent, on identifie plusieurs workloads. Tu as passé le slime, on identifiait plusieurs workload et on avait deux coûts, deux dimensions de coût principales qui étaient le compute et le stockage avec un compute qui est donc capacitaire comme vous pouvez nous l'expliquer Manel et du stockage qui va nous permettre de euh bah d'identifier le volume de data stocké sur Oneelake et d'avoir un coût propre à de l'azure storage pour ces conservations de données. la l'achat d'une capacité, ça se situe au niveau donc d'une souscription cette fois-ci, contrairement à ce qu'on pouvait avoir dans Power BI qui était plus lié à l'abonnement PowerBI 365 qu'on pouvait avoir ici on va ouvrir la souscription, on va créer une nouvelle ressource de type Fabric et on va voir la possibilité de la localiser dans une dans un ressource groupe, une région et à un pour une certaine taille de capacité unit. Ici, on voit dans le slide que le SKU désignant les capacités sont des F avec une unité de mesure F2, F4, F8, F16 qui vont représenter le nombre de Cu secondes disponible pour ce type de SKU et qui vont avoir un prix euh identifiable par mois si on la laisse tourner 24h sur 24 et un prix avec un discount qui est propre aux réservations qu'on va pouvoir passer sur une réservation d'un an ou de 3 ans maintenant pour avoir un coût plus intéressant. Le coût de stockage, comme j'en parlais précédemment va avoir va être vraiment lié à au volume de gigabit qu'on va pouvoir avoir sur le oneel et on va s'apercevoir que suivant le type de stockage, on va avoir des coûts liés comme un azure storage et un ADLS gen2 avec des coups hautes cold, cold et des coûts de cash suivant les workload utilisés comme par exemple un event house qui pourrait utiliser de la donnée sur du SSD qui aura un coût différent. Comme toute ressource Azure, on va avoir cette capacité de pouvoir l'augmenter ou la diminuer selon les besoins. Donc on va pouvoir resaiser une KA avec les SKU disponibles avec les CU disponibles pour chaque taille mais aussi pour des environnements de non production avoir la possibilité de mettre en pause une capacité ce qui va avoir comme conséquence directe réduire la facturation une capacité qui ne tourne pas. Le compute n'est pas facturable n'est pas payé. Par contre, pour la partie stockage, on conserve le gigabit sur le onedeck. Donc, on aura toujours le storage qui sera facturé pendant qu'une capacité est en pause. Ouais. Et on peut rajouter aussi que le prix du SKU est par heure. Donc si je fais tourner ma capacité 1 heure et que je l'arrête, c'est early based. Peut rajouter le fait et c'est en preview de pouvoir ajouter à notre SKU une capacity overage, c'est-à-dire que lorsque j'auraiis dépassé le seuil de mes CU, pouvoir consommer d'autres CU sans que ce soit à l'intérieur de ma capacité sans avoir à dublier son SKU, ce qui peut être intéressant en cas de besoin.

Estimation des coûts

11:15Mais Manel, comment rendre cela gérable à une échelle d'entreprise pour contrôler les coûts ? Ben pour cela, on va avoir plusieurs outils qui sont mis à notre disposition. Déjà, le premier outil euh qui existe, c'est euh la calculatrice Azure qui va vous permettre pour une capacité donnée dans une région particulière avec un SKU particulier, quel serait le coût associé à à ce compute et quel serait aussi le coût associé au storage ? Ça déjà avec rien qu'avec ça, ça va nous donner une idée très globale du coup qui sera payée par mois ou par an. Ensuite, si on veut aller un peu plus finement, on va avoir le Fabric estimator où on a la possibilité en fait de donner certains comme par exemple combien je compte je compte rafraîchir mes données par jour, par mois et cetera, combien d'utilisateurs fin finaux ils vont consommer mes rapports, euh quels sont les workloads que je vais utiliser, est-ce qu'il y aura de l'activateur, du RTI et cetera. Et du coup, ça va ça peut euh nous donner une indication sur la le SKU le plus adapté à notre projet. Ça reste un conseil, ça reste un tips, mais ça ça a ça a le mérite d'être d'être là pour mieux nous guider sur le SKU minimum qu'on doit utiliser. Après, d'un point de vue outil interne à Fabric, on va retrouver différents euh différentes choses. Déjà, on va trouver toute la partie capacité mrique app et capacity chargeback qui vont nous permettre de monitorer l'usage descu, c'est-à-dire cet espace de travail, combien de compute unit il a consommé. Pareil pour cet item Fabric rapport power BMO sémantique, data warehouse ou autre. Quelle est la part des cu que cet élément a consommé ? Donc ça ça concerne la partie usage des CU. Et pour la partie usage en dollar, donc le coût réel associé à mon utilisation, on peut retrouver toute la partie Azure Billing Meeter dans le portail Azure, là où on a acheté justement notre ressource Fabric qui va nous donner pour différentes meeters le coût associé en euros ou en dollars selon l'accurrencie de chaque de chaque client. Et en plus de tous ces outils qui sont qui sont

Fabric Cost Analysis

13:35disponibles, on va retrouver le FCA pour le fabric analysé, ce qui est la solution qu'on a développé et qui va nous permettre de mieux monitorer nos coûts. Oui, parce que comme pour l'analyse des usages, finalement la communauté a créé différentes solutions open source. Nous, on a créé une solution qui va nous permettre de monitorer l'ensemble des couves Fabric. Mais avant ça, rappelons pourquoi. Ben, chaque fois qu'un client nous pose une question, on s'efforce d'y répondre. Mais s'il y a beaucoup de clients qui se posent la même question, il y a peut-être opportunité de créer une solution. Et c'est comme ça qu' est né le FCR. L'idée c'est que lorsqu'on monitore les coûts en Fabric de de Fabric, on a dans Azure un certain nombre de metteurs. Ces metteurs, ils sont pas simplement compréhensibles de tous, d'où la création d'un article que j'avais rédigé il y a quelques temps. Parce que lorsqu'on regarde ces matters, vous voyez, on en a qui sont inclus, il y en a qui sont exclus. On a parlé du Oneel qui est des coûts additionnels. Les clients font pas toujours clairement la distinction entre les coûts inclus exclus de la plateforme, le stockage, le oneel qu'on a parlé, mais la facturation spark en autoscale est aussi des coûts additionnels. Le capacity overage, on l'a cité tout à l'heure, c'est aussi des coûts additionnels et bref, il y en a de plus en plus des coûts additionnels au-dessus du coût de la capacité. Donc ici, lorsqu'on regarde le portail Azur, c'est pas très simple de lire euh combien on va payer à la fin du mois. En plus, il y a certaines particularités liées à ce modèle capacitaire. La suspension de ma capacité interrompt immédiatement toutes les charges de travail et stopp les coûts associés. B, c'est pas tout à fait vrai parce que lorsque la capacité est suspendue, les activités lissées sont réconciliées, facturées séparément au tarif Paz Hugo car les remises associées aux réservations ne s'appliquent qu'aux capacités actives. Donc ça faut le savoir. [grognement] Et puis d'autres questions que les clients ont comment suivre l'utilisation des réservations et valider leur portée, leur scope ? Est-ce qu'il est bien défini ? Comment consulter les quotas Azur ? Est-ce que il m'en reste ? Est-ce que je peux évaluer l'impact tarifaire d'un déploiement multiéo ? Bref, dans plusieurs régions, de nombreuses questions auxquelles on répond généralement à de nombreux clients, mais c'est pas très scalable. D'où l'idée de créer cette solution. Donc on l'a créé aussi avec Cédric qui est pas avec nous mais qu'un expert finop. C'est qui nous a permis bah de comprendre un petit peu les rouages des des coûts dans dans Azur. Euh la solution FCA donc Fabric cost Analysis est disponible sur le fabric Toolbox Git Repository qui vise à mettre en lumière les coûts de la plateforme Microsoft Fabric en s'appuyant sur les exports des coûts Azurs. On verra le format dans quelques slides. Et de donner enrichi sur les compteurs des réservations et des quotas. FCA est entièrement développé grâce aux fonctionnalités de Fabric. C'est important, on utilise les pipeline, les notebooks comme outil clé pour l'extraction et la transformation des données. Les données sont gérées à la fois au format brut et au format Delta parquet, permettant aux utilisateurs d'y accéder directement via PowerB directe. FCA inclut des rapports offrant une vue d'ensemble des données et des modèles de données. Pardon. La plateforme ouverte de Fabric permet l'intégration avec des sources de données externes pour des analyses plus approfondies si nécessaires. Donc c'est une plateforme qu'on peut rendre évolutif par la suite et qu'on continuera de faire évoluer. Attention, l'accélérateur de solution FCA n'est pas un produit Microsoft officiel. Il s'agit d'un accélérateur de solution qui peut vous aider à mettre en œuvre une solution de suivi des coûts au sein et pour Fabric. Par conséquent, aucun support officiel n'est fourni et risque potentiel de panne subsiste. Voyons maintenant comment commencer. Donc sur le repository git dont on parlait précédemment, on va retrouver toute la description, les différentes images mettant FC en avant. Nous sommes largement inspirés de Fuam avec qui nous travaillons en étroite collaboration pour harmoniser les solutions proposées dans la boîte à outil. Le fichier Rmi fournit des instructions détaillées pour l'installation et la mise à jour de la solution ainsi que des exemples de résultats concrets. L'équipe va maintenant présenter en détail chaque partie de la solution. Ouais. N'hésitez pas à nous remonter des issues sur Gitup directement si vous voyez ben des choses à corriger ou améliorer, hein. N'hésitez pas à à nous le remonter. Nous allons maintenant dévoiler et présenter donc la solution étape par étape. Donc l'idée c'est de commencer par les données. Alors on va pouvoir collecter des données dans Azure sur les quotas. Et donc ici vous voyez les différents quotas. Alors ça c'est c'est une source de données qui est optionnelle qui est pas forcément obligatoire mais ça vous donne aussi cette visibilité sur les quotas. Euh on peut rappeler ce que sont les quotas hein. Euh c'est un sujet particulièrement en plus d'actualité compte tenu des préoccupation lié à la surutilisation des des data center. Donc de nombreux services Azure disposent de quota qui correspondent au nombre de ressources allouées à votre abonnement Azur. L'idée c'est ça vise à vous protéger vos clients contre le déploiement mal dimensionné les erreurs de consommation et ça permet aussi aux équipes Azure de planifier ce qu'ils vont avoir besoin demain en terme de capacité. Donc euh c'est en quelque sorte euh bon dans les deux sens hein. L'idée c'est de sécuriser la capacité à l'avance en garantissant la disponibilité des ressources en cas de besoin. Mais c'est pas parce que vous avez des quota que vous pourrez non plus les utiliser. Mais au moins ça euh annonce aux équipes Azure que vous en aurez peut-être besoin demain. Donc les quotas Azure constituent une source optionnelle pour le FCR. Maintenant on a aussi les réservations. Et là les réservations, c'est une c'est aussi une source optionnelle du FCA. Les réservations vous permettent de réaliser des économies en s'engageant sur un produit Azur. Donc c'est pas seulement lié aux ressources Fabric, hein, mais c'est un engagement le euh qui donne droit à une réduction. Donc on peut citer 41 % pour Fabric. Et les clients peuvent choisir de payer ses réservations en une seule fois mensuellement ou euh en en advance. Et Microsoft, on l'a dit, hein, dispose maintenant des réservations sur 3 ans. Euh donc les réservations Azure est l'une des source aussi optionnelle du FCA. Et la source qui est non optionnelle, c'est celle-ci à savoir les coûts au format focus. Donc les coûts au format focus, c'est un format assez intéressant parce que open source est aussi adopté par différents cloud providers. L'idée c'est si vous exportez des coûts dans Amazon, des coûts euh dans Azure, ben ils sont au même format, c'est savoir au format focus. Donc c'est euh standardiser l'export et l'analyse des coûts. Donc pour exporter les coûts au format focus, je retourne sur mon portail Azure. Je vais sélectionner dans cost management export. Et là, je peux avoir plusieurs exports. Euh l'idée, c'est que tous les jours, il m'exporte les coûts de la veille dans un compte de stockage. Alors, souvent dans les organisations avec lesquelles on travaille, euh, ils n'ont pas forcément les droits suffisants pour exporter ces données. Donc, il demandent à des équipes Philops d'exporter alors que eux mettent à disposition le compte de stockage. Et euh voici à quoi ressemble l'export. On a choisi de de les exporter au format Snapi parquet pour avoir un un format compressé. Après avoir regarder et découvert les formats supportés par FCA, focus, réservation, quota, nous allons rentrer dans le vif du fusé en regardant l'intérieur du Lhous et la partie data intégration. Donc FCA va exploiter ses données natives de Fabric pour simplifier l'analyse descoues données. Ce sont le format focus qui arrive sur un storage account dans la subscription sur laquelle on est on a configuré l'export. à travers des shortcuts, on va pouvoir accéder à ces données qui étaient en snappy parquet comme l'a dit Romain, sans les déplacer, donc pour les rendre accessibles directement à l'intérieur du Hoaus. À partir de là, pour compléter les informations dont on pourrait avoir besoin, on va utiliser des API Azure ARM pour se connecter et effectuer l'extraction des côtats qui elle ne vient pas comme les réservations et les données de focus à travers l'export sur le storage à côte. Par la suite, un pipeline va être configuré, va orchestrer les différents notebooks pour pouvoir préparer à partir de ces données R nos données silver et notre donnée gold qui servira de sémantique model au rapport d'cklec powerbi dont on parlera tout à l'heure. Donc là, pour pouvoir déployer et installer, on se reconnecte au euh Repository Git, on télécharge le notebook de déploiement, on le met à l'intérieur du workpace qu'on a créé qui était vide. Et à l'intérieur de ce notebook, il nous reste à l'exécuter. Il va installer les différentes dépendances dont les MS Fabric Cli pour permettre d'interagir avec Fabric et d'installer pour nous les différents notebooks et pipeline dont on parlait précédemment. Les cellules déroulées jusqu'à des actions de postcfiguration qui vont venir créer des métadonnées, des tables supplémentaires à l'intérieur duous comme la définition précise des différents SKU et des regroupements que nous voulons en faire. pour pouvoir faire une analyse point à point des consommations de chaque workload. Donc là, on est encore dans la le déploiement des différents artefacts, le poste déployment qui s'exécute et on va pouvoir si on se connecte sur le Lhous, découvrir les euh nouvelles tables, au préalable, créer les shortcuts pour rendre disponibles, comme je l'expliquais précédemment, les exports focus afin que les différents notebooks et pipeline puissent les exploiter durant l'intégration. Voilà, on voit tout l'historique focus qui a été préparé en amont. Ensuite, il reste le pipeline d'intégration. Donc on se connecte au pipeline, on modifie les dates à partir de quand à quand, c'est-à-dire à partir de quel mois dans l'historique a été généré jusqu'à le mois actuel pour exécuter la reprise d'historique sur les mois prochains ou sur les jours prochains. Il suffira juste de réintégrer le mois précédent et le mois en cours pour être sûr d'avoir les données toujours à jour. Et ensuite, on va dans le Lhous, on voit les nouvelles tables qui sont apparues, des tables qui vont nous être expliqué par la suite dans le modèle sémantique par Manel. Ouais. Et avant ça, on peut citer le fait que si aujourd'hui je déploie la solution, je peux récupérer un an d'historique via les export Azur et donc ici aussi démarrer le FCA avec déjà un an d'historique. Et du coup, après avoir chargé les données avec tout l'historique que qu'on veut sur la partie sur la partie fineups, on arrive justement à la partie reporting et au modèle sémantique. Donc dans FCA, quand vous allez installer justement la solution, vous allez trouver un modèle sémantique qui va regrouper trois sujets qu'on essaie un petit peu de représenter dans le même rapport. Donc nous on va retrouver toute la partie focus data où on va on va avoir la possibilité justement de filtrer la donnée par souscription, par ressource groupe, par date, par meur. Ensuite, on va avoir toute la partie ajour et aussi la partie réservation.

24:57Mais en fait, ce qui est le plus intéressant dans la CS, c'est vraiment cette connaissance Phinops qu'on a eu grâce à notre collègue Cédric où justement euh les meeters qui étaient euh les billing meeters qu'on avait récupéré depuis Azure Cost Management n'était pas forcément facile à interpréter. Donc on avait souvent euh on était souvent obligé de regrouper certaines comme par exemple si on a envie de calculer uniquement le coût associé à la capacité Payazugo, même si je suis en reserve instance, il y avait certains à inclure ou à exclure euh pareil pour la capacité available ou pour des meurs beaucoup plus straight forward comme par exemple Sparkale, copyot et cetera. Et enfin, on arrive justement à la partie reporting où on essaie un petit peu de vous montrer les différentes mesures qu'on a créé pour euh la partie monitoring des coûts en trois stages. Donc euh la première page qu'on voit, c'est la page inform euh où on a justement la possibilité de voir le coût associé à nos différentes capacités Fabric. Bien évidemment, on va pouvoir les filtrer par ressources groupe, souscription, région, par capacité. On a la possibilité de voir un petit peu le maturity, le finance maturity score. Mais le plus important ici, c'est qu'on a la possibilité de voir justement la part de notre coût total par réservation, pay par payasugo, par additional cost et par le storage de One Lake. Et on a bien évidemment la possibilité de rentrer dans le détail sur chacune des catégories pour voir précisément quel est le coût associé à mon usage de copilote, à mon usage de du work RTI, à mon usage de mon worklog de data intégration. Pareil pour toute la partie oneel. Donc ici encore une fois on donne les différentes métriques liées à l'information autour de votre consommation euh des coûts à Fabric. Ensuite on va avoir d'autres pages qui vont nous permettre de rentrer un peu plus dans le détail notamment à la page Samarie où on a la possibilité de voir différentes régions. Et puis on a la partie optimisation des coûts notamment via cette page où on peut voir justement quel est le coût associé à la capacité qu'on approvisionner, quel est le coût qu'on a réellement consommé à travers les différents workload projet espaces de travail rattaché à notre capacité et enfin quel est le coût lié aux différentes comput unit qu'on n' pas consommé et ça en fait c'est quelque chose qui est vraiment valuable parce que si on se retrouve avec un coût disponible de notre capacité qui dépasse 50 %. Ça voudrait dire que notre capacité, elle est sous utilisée. On a la possibilité de rajouter d'autres workload ou d'autres projets. On va retrouver ici aussi euh la page optionnelle liée à la réservation où on peut voir justement le nombre de réservations euh associé à notre souscription, s'ils sont à 100 % utilisés euh ou pas, dans quelle région ils sont, quel est le coût euh qu'on paye pour ces différentes capacités. Donc on voit ici toute la partie détail liée à tout ça. Et puis au niveau du cost detail, on a justement la possibilité de voir la part de chaque catégorie d'usage de Fabric et son coût associé. Donc ici, on peut voir dans ce tableau le coût associé à l'arril, à l'utilisation de Spark, au lake, au data flow, au data movement, au Power BI, mais aussi les les CU qui qui ne sont pas utilisés. Et ça c'est quelque chose qui est très très important parce que ça nous donne une vision globale de qu'est-ce qu'on utilise à l'intérieur de notre capacité Fabric et quel est le rou le coût pardon en montant dollar ou en euros associé à ces usages. Après, on verra la page quota et enfin on retrouve la page de support où on vous invite justement à nous donner des feedback, à nous donner des idées pour les prochaines releas de SCA. J'aimerais revenir rapidement sur la page Azur Cota. Donc ici, on a la possibilité justement de vous donner euh sur différentes régions la euh les quotas associés euh de Fabric, les quotas associés à vos régions. Euh juste une petite précision, s'il vous reste du quota, ça ne veut pas forcément dire ce n'est pas une garantie euh qui vous permett la capacité Fabric. Ça reste un côtat disponible mais il faudrait faire attention notamment sur des régions qui sont qui sont qui sont surcharge. Avoir des quotas ne veut pas forcément dire qu'on a la possibilité de créer une capacité ou d'une réservation instin sur cette même région. Mais euh ça ça reste quelque chose qu'il faut monitorer. De toute façon, si vous n'avez pas le côte à vous ne pouvez pas créer la capacité. Et puis quelque chose qu'on a ajouté tout récemment, donc il y a à peine quelques semaines, c'est notamment la possibilité de filtrer par tag euh vos différentes ressources et vos différentes capacités Fabric. Donc vous avez la possibilité en fait de choisir le tag et les valeurs du tag. Et en fait grâce à ça, vous pouvez filtrer sur toutes les capacités qui répondent au filtres tag name et tag value. Super. Merci Manel. Et donc dernière étape, maintenant qu'on a toutes ces données et ces rapports, on a créé aussi en optionnel un data agent qui va vous permettre de converser en langage naturel avec ces données, avec un expert en Finops qui a toutes les infos sur la consommation de euh vos coûts sur sur Fabric. Donc on voit ici dans notre documentation comment le déployer. Donc comme c'est un data agent, ça doit tonner sur une capacité Fabric et donc pas accessible sur du trial. C'est aussi pour ça qu'on l'a rendu optionnel. Pour l'installer, il suffit d'exécuter un notebook comme pour l'installation de la solution. Et là, il est déjà configuré. Il a déjà un certain nombre de skills, de connaissances de ce qui sait faire et cetera. Ce qui lui permet de répondre assez simplement ici à la question quelles sont les les ressources qui consomment le plus ? et les datas agences sont aussi accessibles et maintenant encore plus simplement à Microsoft 365 donc à copilote. Donc on ait pas forcément besoin comme on avait pu le faire dans cette démonstration de créer un copilote studio au dessus mais ce qui nous permet aussi de vous montrer qu'on peut enrichir ces data agents et les consommer aussi à travers de différents autres solutions. Notre traitement aussi maintenant avec un MCP. Donc on va pouvoir chatter avec notre agent expert en Philops de différentes façons. Si on parle du coût de la solution parce que c'est souvent quelque chose qu'on nous demande, ben il faut savoir que pour un déploiement euh sample, donc à savoir quatre régions, 50 capacités et 13 réservations, ça a coûté environ 2 % d'une F64 chez un de nos clients, ce qui est ce qui est finalement pas beaucoup hein Antoine. Tout à fait. avec une exécution une fois par jour et on recharge que le mois en cours et le mois courant et le mois précédent. Donc on est vraiment sur quelque chose de peu consommateur et et qui permet d'avoir une vraie vision sur sur la consommation Finops de de Fabric. On peut citer que le FCA est largement adopté worldwide. Euh on voit qu'il y a pas mal de consommation de téléchargement de la solution. Donc ça c'est plutôt intéressant et ce qui nous motive à enrichir cette trop de map. Donc on travaille avec l'équipe du FOAM là, une nouvelle solution qui permettrait ben d'avoir une granularité plus fine dans le FCA et donc sur vos coût au niveau des workspace. On travaille là-dessus, ce qui va nous permettre aussi de corréler vraiment les CU avec le coût associé et on va continuer d'inclure de nouveaux meters, le warehouse autoscale qui devrait arriver et pourquoi pas proposer aussi du forecast. J'ai pas pris de Rail qui aurait été mon coûpt si j'avais pris une RAI il y a 3 mois et cetera. ce genre d'analyse, on va essayer de les supporter et puis on va essayer de connecter aussi les activités maintenant qu'on a les operation event en real time sur les capacités euh pour avoir peut-être des informations un peu plus de temps réel sur les coûts. Donc maintenant, si vous deviez retenir 10 choses de cette présentation, ben voici quelques conseils. Donc la première chose ou le premier type Swan, c'est de ne surtout pas mettre pause

Tips & Learnings

33:04votre capacité qui est sous une reserve instance. En fait, la reserve instance, elle est là pour un une capacité qui est tout le temps on h24 pendant 12 mois. Donc à partir du moment où vous mettez votre capacité en pause, en fait vous allez quand même continuer à payer votre reset instance. Et ici c'est une perte de compute. Et le plus important aussi, ne mettez jamais pause. Ne mettez jamais pause seulement si vous comprenez précisément quel est l'impact derrière euh derrière ce POS. Pourquoi ? Parce que comme on l'a expliqué au tout début, quand on met une capacité en pause, tout ce qui a été smoothé sur 24 he est réconcilié et vous allez payer en fait cette réconciliation au payzugo. Donc c'est un coût supplémentaire qui peut être là même si au tout départ vous aviez une reserve instance. Oui, la MTRI vous permet de savoir quelles sont les activités qui restent encore qui sont encore smoussées sur votre capacité, ce qui vous permet de savoir si euh si je mets en pause l'impact que ça aura. On peut aussi citer maintenant qu'on peut surveiller les coûts et pas juste un pourcentage d'utilisation car grâce au FCA, il vous est possible maintenant de surveiller combien coûte chaque usage de Fabric et pas seulement en terme de CU mais aussi en terme de coût par exemple j'ai des clients qui ont découvert que certaines capacités est utilisée pour des opérations copilotes et là on peut s'arrêter un peu et dire que ben j'aurais pas fait ces activités copilote mon coût de ma capacité aurait été la même. Par contre, du fait que j'ai fait du copilote sur ses capacités, ben j'utilisais du CU pour ces activités là qui peut-être auront été dédiées à d'autres activités si j'avais pas fait de copilote sur cette capacité. On peut aussi citer le FCC, donc c'est roer finalement la consommation CU euh par les activités copilotes mais aussi de date agent sur une capacité qui serait déliée. Typiquement, c'est ce qu'on conseille avant d'ouvrir euh largement l'usage de copilot sur des capacités de production. Dans cette typ, on voit que l'utilisation de des indicateurs pour corréler l'utilisation réelle avec le coût dans Azure Cost Management va vous donner de la visité, la visibilité, pardon, pour vous aider à identifier les capacités sous-utilisées et aller justement les optimiser efficacement euh leur allocation. Ensuite, pour la type 5, c'est de toujours monitorer vos Azur quota proactivement. Donc en fait, il faudrait toujours prévoir dans le cas où on a besoin de faire un appilling ou dans le cas où on a besoin de souscrire une capacité en plus parce qu'on est en période de pic de consommation. Donc garder en tête la partie Azur quota et encore une fois avoir un quota n'est pas une garantie de la possibilité de réserver une capacité dans une région qui est un dark pressure. Donc c'est juste une petite parenthèse ici. Oui. Pensez aussi à l'activation du capacity overage qui peut être dans certains cas intéressant plutôt que de voir scaler, multiplier la taille du SKU. Ça peut être intéressant dans certains cas. Maintenant qu'on voit la location des coûts de compute mais surtout des coûts de storage, on va avoir un focus un peu plus important sur la partie storage. On va vous demander forcément en terme de première type, c'est-vous besoin de tout ce stockage ? Pouvez-vous le réduire pour réduire le coût associé au storage ? et et en preview sur Fabric, on a des fonctionnalités qui deviennent intéressantes comme sur les ADL GN 2, c'est au niveau du workspace de pouvoir faire du teering différent, donc de positionner le type de fichier en mode H cold cold pour faire varier le prix si on veut garder des données plus long terme et y accéder moins souvent, ça va nous permettre d'avoir des meilleures pratiques de coût de stockage. On vous conseille forcément d'éliminer la duplication, de vraiment vous baser sur les shortcut même entre les workspace, un peu comme une système de mèche, on va s'échanger la donnée, mais on accède à la donnée où elle est avec du zéro copie. Quand on travaille sur du houseous, on a des delta table qui dit delta table dit gestion des différentes versions dans le temps des fichiers parquet. Donc pensons à faire du vacum. Le vacuum par défaut, il doit être de 7 jours. On peut le diminuer, on peut le réduire. Si on veut effacer de la donnée, on peut passer un vacuum avec 0 he pour cleiner tout l'historique et repartir d'une copie blanche. Donc vraiment pensez à faire vos cycles de nettoyage après les updates, après les merges. Pensez à faire vos optimizes. On repense à la couche stockage comme tout fonctionnement de l'house optimiz compactation optimize rate automatique à activer. Essayer de prévenir les petits petits fichiers pour exploser les métadata et revendre la consommation des des delta tabell très lentes. À vous de gérer la partie maintenance. [grognement] Euh toujours dans le même design et même best practice de sémantical model aussi. Supprimer les colonnes que vous utilisez pas. Évitez d'avoir des données avec plusieurs copies. Évitez d'avoir la même information dans différents formats. Euh réfléchissez un petit peu avant de mettre en place pour réduire la volumétrie nécessaire. Et euh sur les eventus euh pareil, on a de la suppression automatique de l'historique. Bah regardez bien à la base de données, mais vous pouvez aller voir au niveau granulaire de la table avec des tables où je conserve des données agrégagées sur 1 an et d'autres tables où je garde sur un mois, 2 mois avec des données détaillées pour réduire la taille et la taille du cash qu'il aura un impact sur le coût du stockage plus important, ça utilise du SSD. Ouais. L'idée du FINOP, c'est de la gouvernance hein. C'est pas de d'arriver en mode pompier. Si on peut prémunir euh d'avoir des ralentissements sur notre capacité, ça peut être intéressant. Et en ça, on a différentes techniques, notamment le surge protection avec soit au niveau du workspace, soit au niveau des activités background. Donc le workspace, c'est les activités interactives comme background, mais après au niveau de la capacité globale, pour les activités background, on peut mettre des seuils, ce qui bloquera euh la capacité ou le workspace. Et puis il y a quelque chose qu'on oublie souvent de faire, c'est la création des alertes euh au niveau de Azure euh sur des budgets euh et même la création aussi des alertes depuis notre rapport à FC. Donc on a la possibilité de dire "Ah tiens, dès que j'atteins ce ce budget euh je veux recevoir une alerte proactive sur mon Outlook. Euh et sur on a la possibilité de créer en fait des activateurs euh qui nous disent tiens, j'ai atteint un seuil euh critique d'un point de vue budget, je veux recevoir rapidement une notification sur Teams ou sur mon outlink. La typ suivante, c'est vraiment planifier à long terme l'utilisation de Fabric. On a sorti les les 3 années de réservation que vous pouvez prendre dès maintenant. Avec l'outil FCA, vous pouvez voir justement le volume de CU nécessaire qui ne sont pas couverts par des réservations. Aujourd'hui, vous assurer que vos réservations couvre bien à 100 % ou en tout cas sont utilisées à 100 %. Dans l'autre sens, pensez à récupérer du discoun en prenant une réservation d'un an, pensez à voir plus loin avec une réservation de 3 ans qui ne donnera pas beaucoup plus de discount que la 1 an, mais qui permettrait bah déjà de se projeter et aussi de permettre à Microsoft de voir tous les clients qui utilisent de la capacité. sur un data center et et à long terme pour pour le fournir. Et enfin, en fait, ce qui permet de regrouper ces types, c'est un petit peu le maturité score qu'on a rajouté récemment. Euh ça reprend en fait cinq bonnes pratiques de Phinops. Euh pour notre cas, on a on a pris justement un poids sur la couverture à rail, l'utilisation des ris, est-ce que j'utilise bien ma capacité ? Est-ce que je fais des pauses de ma capacité ? Est-ce qu'il y a de l'autoscale ou pas ? Donc l'idée générale, c'est d'améliorer votre score maturité score Finops qui reprend un petit peu toutes les bonnes pratiques qu'on vient d'annoncer avec Romain et Antoine.

Conclusion

41:02Vous êtes désormais une vision plus claire, je l'espère, on l'espère, du FCA et ce qui peut vous offrir. N'hésitez pas à le tester, à nous donner du feedback sur ce qui est pertinent, sur ce qu'il est moins, si vous avez des idées aussi pour l'améliorer. Merci à Manel et Antoine pour leur explication, les éclairages et les démonstrations. Et si vous avez trouvé cet épisode utile, alors n'hésitez pas à vous abonner à Fardata. On vous dit à très bientôt pour un nouvel épisode. À bientôt. Au revoir.