🚩 Version de l’article en Anglais sur LinkedIn : FinOps for Microsoft Fabric

Le FinOps et Microsoft Fabric, deux sujets qui m’intéressent particulièrement, c’est probablement la raison pour laquelle l’article est plus long que prévu !

1 – Introduction

Au même titre que le Cloud apporte un certain nombre de bénéfices, il apporte aussi son lot de changements et certaines bonnes pratiques doivent être mises en place pour maximiser son bon usage et ainsi tirer pleinement parti de ses avantages, il en est de même pour les services SaaS tels que Microsoft Fabric.

L’approche FinOps, combinaison des termes Finance et Opération, vise au monitoring et à l’optimisation des coûts en matière de Cloud Computing. « Le FinOps est une discipline de gestion du Cloud public qui permet aux organisations d’obtenir une valeur commerciale maximale du Cloud en permettant aux équipes technologiques, financières et commerciales de collaborer sur des décisions de dépenses basées sur des données. » J.R. Storment.

Les services Data représentant pas moins de 30 % des usages Cloud chez nos clients, leurs optimisations sont donc cruciales. J’ai rédigé il y a quelques temps plusieurs articles et présentations sur le sujet :

• FinOps & Azure Data Services
• FinOps & Azure Data Services – Deuxième article
• FinOps pour les services de données dans Microsoft Azure (juillet 2022)
• La carte heuristique reste encore pertinente FinOps and Data (Merci Stanislas Quastana)
• …

À l’époque, j’abordais les services Data dans Azure en modes IaaS et PaaS. Il est grand temps d’inclure la partie SaaS avec Microsoft Fabric !

 

2 – Tips & Learning

J’ai recensé quelques Tips & Learnings que j’ai découpé en fonction des 4 Domaines décris par la FinOps Fondation : « Quantify Business Value », « Understand Cloud Usage & Cost », « Optimize Cloud Usage & Cost », « Manage the FinOps Practice ». Je ne vais (forcément) pas être exhaustif sur toutes les bonnes pratiques mais essayons de rappeler quelques bases qui je l’espère vous seront utiles au bon usage du service et de vos Capacity Units (CU) ! N’hésitez pas à partager en commentaires d’autres astuces 😉

2.1 – Quantify Business Value

Dans ce premier domaine de la FinOps Fondation, les organisations font correspondre les coûts monétaires et non monétaires du Cloud aux budgets, utilisent les informations historiques et les plans futurs pour faire des prévisions, établissent et mesurent les KPI techniques et organisationnels, et effectuent des analyses comparatives entre les équipes, les unités opérationnelles et avec d’autres organisations.

Unit Economics

Rappelons que le FinOps n’est pas (seulement) une question d’optimisation des coûts, mais aussi d’optimisation de l’utilisation du Cloud, dans notre cas du service SaaS. Dépenser plus sur Microsoft Fabric (ou tout autre service Cloud) peut s’avérer pertinent afin de générer plus de revenus, être compétitif, prendre de bonnes décisions, … Le FinOps consiste donc à gérer l’utilisation de l’informatique dématérialisée pour gagner de l’argent.

Forrester Total Economic Impact™ study: Microsoft Fabric delivers 379% ROI over three years

Rappelons aussi que la Donnée a de la valeur que si elle est activée et rendue intelligible (Data Companies). Il est essentiel de comprendre et de quantifier la valeur commerciale des données. Le coût unitaire économique (Économie de l’unité) devient une mesure essentielle dans cette analyse, fournissant une mesure tangible de la valeur dérivée des données par rapport aux coûts associés. En évaluant les données à travers le prisme du coût unitaire économique, les entreprises peuvent mieux évaluer le retour sur investissement de leurs actifs de données.

Des facteurs tels que la quantité, la qualité, la rareté, la variété, la valeur au fil du temps et la sophistication des données doivent être pris en compte pour établir une compréhension globale de la valeur des données. Ce processus de quantification permet aux organisations de prendre des décisions éclairées sur l’utilisation des données et l’investissement, en s’assurant qu’elles maximisent la valeur de leurs données tout en minimisant les dépenses inutiles.

Remarque : Les données peuvent également avoir une valeur indirecte, notamment celles qui enrichissent les modèles de Machine Learning ou qui soutiennent des processus d’analyse avancés.

Dans Microsoft Fabric, les coûts directs sont liés à la licence des utilisateurs (Free, Pro, PPU), à la taille des capacités octroyant un certain nombre de CU, ainsi qu’à l’utilisation du stockage (en Go) et du réseau (transfert de données entre régions). D’autres coûts moins directs existent et sont due à l’utilisation de certaines fonctionnalités, comme ceux liés à la sécurité. Par exemple, la mise en place de RLS dans un entrepôt peut entraîner une plus grande consommation de ressources. En ce qui concerne le coût humain, les CoPilots, bien qu’ils puissent consommer des ressources, peuvent également accélérer le développement ou simplifier les tâches pour les utilisateurs ou analystes, leur faisant ainsi gagner du temps et permettant une économie de temps humain (How Much Does Copilot Cost In Microsoft Fabric?).

💡 La monétisation des Data Product inter ou extra entreprise peut s’avérer pertinent pour accroitre la valeur des données et faciliter le calcul sur la rentabilité concernant les investissements dans le Cloud.

En donnant la priorité au coût unitaire économique des données, les entreprises peuvent atteindre un équilibre entre l’efficacité financière, les performances et l’innovation nécessaires pour atteindre leurs objectifs informatiques et opérationnels.

Planning & Estimating & Forecasting

Comme pour tout service, il est primordial de comprendre le mode de facturation afin de l’utiliser efficacement. Rappelons donc ici quelques bases :

• Dans Microsoft Fabric vous achetez une Capacité ayant un SKU (scalable à l’heure et pouvant être mise en pause). Cette capacité vous permet de consommer des CU toutes les 30 secondes. A titre d’exemple une F64 permet de consommer 1920 CUs toutes les 30 secondes (F64 * 30s = 1920 CUs) : Understand how consumption is calculated
• Dans Microsoft Fabric, vous consommez des ressources de calcul (CU) et du stockage indépendamment. Un Tenant = Un OneLake
• Les capacités peuvent être réservées sur une année et vous permettre de réaliser de belles économies (environ 41%) : Save costs with Microsoft Fabric Capacity reservations. Notez que la réservation concerne les CUs. Une réservation F128 peut être utilisée pour une capacité F128 ou pour deux capacités F64
• La capacité Microsoft Fabric est éligible au Microsoft Azure Consumption Commitment (MACC). Les clients peuvent ainsi imputer leurs dépenses sur leur engagement et bénéficier de tarifs préférentiels
• Le Stockage est facturé en Pay-as-you-go (par GB consommé par mois)
• Plusieurs Workspaces peuvent utiliser une même capacité. Un Workspace utilise les ressources d’une capacité et les différents Workloads dans le Workspace consomment les CUs et espace de stockage associé
• Le Smoothing et le Bursting permettent d’optimiser (pour vous) l’usage des CUs : Understand your Fabric capacity throttling
• Si vous consommez plus de ressources que vous ne payez, voici les 3 paliers 🤿 :
  • Au-delà de 10 minutes de surconsommation, vos activités interactives subiront des délais
  • Au-delà de 60 minutes de surconsommation, vos activités interactives seront rejetées
  • Au-delà de 24 heures de surconsommation, les tâches d’arrière-plan seront également rejetées

Il y aurait encore beaucoup à dire, mais restons-en là pour le moment…

Diverses techniques sont disponibles pour estimer les coûts dans Microsoft Fabric :

• Plan your capacity size
• Microsoft Fabric – Pricing

Malheureusement, il n’existe pas de méthode d’estimation unique qui convienne à toutes les situations. Les dépenses sont variables car en fonction de vos données et de vos traitements, ils sont donc difficiles à prévoir en avance. Le déploiement de Proof of Concept (POC) peut être utilisé pour quantifier la consommation réelle. Les capacités Fabric de Trial peuvent être utiles pour ce type d’activités, tout comme l’utilisation d’une capacité dédiée que l’on peut mettre en pause pour ce type de test.

Pour faciliter le choix de la bonne capacité (SKU), une nouvelle calculatrice d’estimation sera bientôt rendue publique :

2.2 – Understand Cloud Usage & Cost

Dans ce deuxième domaine de la FinOps Fondation, les organisations relient l’utilisation à la valeur commerciale afin de garantir que la valeur créée et l’impact de cette utilisation correspondent de manière transparente aux attentes.

Data Ingestion & Reporting & Analytics

Il est donc temps de parler de Monitoring et il y a plusieurs niveaux :

• Le Monitoring du coût dans Azure
• Le Monitoring de l’usage des CUs dans Microsoft Fabric

Lorsque vous utilisez une capacité Fabric, vos frais d’utilisation apparaissent dans le portail Azure sous votre abonnement dans l’expérience Microsoft Cost Management : Understand your Fabric capacity Azure bill.

Il existe un certain nombre de fonctionnalités très intéressantes au sein de Microsoft Cost Managment dans Azure, tel que :

• La création de budgets : Create and manage budgets
• La création d’alertes : Monitor usage and spending with cost alerts in Cost Management
• La création de rapports : Use built-in views in Cost analysis – Microsoft Cost Management
• Et bien entendu, la possibilité d’analyser ces données avec Power BI : Connect to Microsoft Cost Management data in Power BI

FOCUS (FinOps Open Cost and Usage Specification) est une initiative visant à unifier un format open-source pour les données de facturation Cloud (pour les différents fournisseurs), facilitant ainsi la tâche des praticiens FinOps.

L’accès à ces données normalisées est possible depuis Microsoft Fabric via la création d’un Shortcut sur les données régulièrement extraites dans un compte de stockage. Les étapes sont décrites dans la documentation suivante : Create a Fabric workspace for FinOps.

Après avoir configuré l’export dans un ADLS Gen 2 :

J’ai créé un nouveau Lakehouse et un Shortcut sur les données FOCUS exportées :

J’ai ensuite importé les données dans une table me permettant de les analyser :

L’import de ces données peut être automatisé, voici un exemple avec du code Python : Python script

Il ne reste plus qu’à créer un modèle sémantique, des rapports et de les partager :

📢 Je prévois la rédaction d’un article détaillé sur l’analyse des couts FOCUS extrait de Azure dans lequel j’inclurai un modèle sémantique et un rapport Template.

Après avoir évoqué le monitoring du coût dans Azure, regardons à présent le monitoring de l’usage des CUs dans Microsoft Fabric.

Alors que dans un ordinateur, vous surveillez la consommation des ressources telles que la RAM, le CPU, etc., dans Microsoft Fabric, nous surveillons l’utilisation des CUs. Dans votre ordinateur, cette surveillance peut être effectuée via le Task Manager, alors que dans Microsoft Fabric, cela peut être fait avec l’application Microsoft Fabric Capacity Metrics app. L’application donne un autre angle de vue différent de l’analyse effectuée des coûts dans Azure puisque celle-ci renseigne sur la consommation des CUs. La vue par défaut de l’application montre les tendances de la consommation par charge de travail au cours des 14 derniers jours. Pour avoir plus d’historique il vous suffit d’exporter ces données et de les conserver par exemple dans un OneLake. C’est ce que nous faisons en Python depuis un Notebook dans le cadre de notre offre de service Microsoft Fabric Go Live Assessment afin de faire du Forecast ou de l’optimisation de consommation des CUs (offre de service Microsoft délivrée uniquement par des CSAs accrédités et vendue uniquement dans le cadre du contrat unifié) :

La consommation des CUs varie selon la charge de travail, il est pertinent de comprendre leurs modèles afin de les utiliser de manière optimale :

• Pour les Warehouse : Data warehouse billing and utilization reporting, Using sempy to get SQL query CU cost from the Fabric Capacity Metrics app
• Pour les Data Pipelines : Pricing for data pipelines
• Pour les Dataflow Gen 2 : Pricing for Dataflow Gen2
• Pour les bases Eventhouse : Eventhouse overview
• Pour les bases SQL Database : Pendant la période de Preview, la base de données SQL dans Fabric est gratuite (comme la plupart des fonctionnalités en Preview)
• Les VNet Data Gateways génèrent des couts additionnels : Virtual network data gateways capacity consumption | Microsoft Learn
• …

D’autres rapports présents dans le service renseignent sur l’usage et l’adoption du service :

• Feature usage and adoption report
• Use the Monitor hub
• Microsoft Purview hub in Microsoft Fabric

D’autres solutions peuvent les compléter :

• La librairie Sempy Lab peut faciliter la collecte d’informations
• Monitoring Microsoft Fabric Copilot Adoption
• Pour suivre l’usage du Tenant :
  • FUAM
  • GitHub – RuiRomano/pbimonitor
• Pour suivre l’usage des Gateways :
  • GitHub – ecotte/rt-gateway-log
  • GitHub – RuiRomano/pbigtwmonitor

💡 Certaines solutions peuvent également avoir un impact sur la consommation des CU, il est donc conseillé de les comparer (Costs of querying semantic models in Power BI and Fabric. XMLA vs. API calls).

Allocation

Analyser les données et créer des rapports pour identifier les modèles d’utilisation et de dépenses, trouver des améliorations et faciliter la prise de décisions informées est une première étape. Désormais ces données peuvent être partagées à l’organisation et nous pouvons responsabiliser les utilisateurs (Show Back) ou refacturer (Charge Back) ainsi que recenser les sous-ensembles de coûts partagés. A ce titre le rapport ChargeBack (toujours en Private Preview mais bientôt disponible) facilitera une répartition des coûts entre Workspaces utilisant une même capacité.

D’autres rapports annoncés pour une vision multi capacités verront le jour très prochainement :

Anomaly Management

Vous pouvez configurer des notifications (Capacity notifications) ou créer une solution custom à partir des données extraites précédemment (Create alerts) afin de détecter, identifier, alerter et gérer en temps utile les irrégularités inattendues ou imprévues en matière de coûts et d’utilisation afin de réduire les risques liés à la rentabilité des activités sur le service.

2.3 – Optimize Cloud Usage & Cost

Dans ce troisième domaine de la FinOps Fondation, les organisations doivent optimiser l’utilisation du service pour améliorer l’efficacité et la rentabilité. Cela inclut la gestion des capacités, leurs réservations, le Scale Up/Down ou encore le Scale Out ou la mise en pause éventuelle.

Rate Optimization

L’efficacité des tarifs Cloud est assurée par une combinaison de remises liées à l’engagement (RIs, Savings Plans, MACC, Committed Use Discounts) et d’autres mécanismes de tarification permettent d’atteindre les objectifs opérationnels et budgétaires de l’organisation. Noté que le prix n’est pas le même d’une région à une autre, ce qui peut dans certains cas constituer un levier d’optimisation du coût.

Documentation : Save costs with Microsoft Fabric Capacity reservations

Architecting for Cloud

Il est nécessaire de concevoir et moderniser des solutions en tenant compte des coûts et de l’efficacité afin de maximiser la valeur de l’entreprise tout en atteignant les objectifs de performance, d’évolutivité et d’exploitation. Ainsi il faut équilibrer les facteurs de coût, de durabilité et de conception opérationnelle tout en modernisant en permanence.

Alors que de nouvelles fonctionnalités apparaissent rapidement, il est pertinent de les tester, de valider leur pertinence et de se les approprier. À titre d’exemple dans le monde Spark, le Native execution engine permet d’améliorer l’exécution des tâches Apache Spark dans Microsoft Fabric. Il est également pertinent de maintenir les environnements et les Runtime à jour. En effet, à moins de les changer manuellement, l’espace de travail continuera d’utiliser le runtime précédemment défini, même si une nouvelle version est disponible. À ce titre, voici un exemple de solution : Upgrade Fabric Workspaces To The Latest GA Runtime.

L’utilisation de la capacité sur différentes régions peut être utile ou nécessaire dans certains cas, tels que la réglementation en termes de résidence des données, la réduction du trafic réseau ou de la latence. Cependant, cela peut engendrer des couts de transfert réseau supplémentaire et complique les migrations interrégion car les espaces de travail contenant des éléments non-Power BI Fabric ne peuvent pas être déplacés d’une région à l’autre. Documentation : Multi-Geo support for Fabric.

La mise en pause de la capacité peut s’avérer utile dans certain scénario, attention cependant à bien comprendre le mode de facturation en cas de Pause :

• Les charges de travail cessent d’être exécutées et n’acceptent plus de nouvelles demandes de la part des utilisateurs sur une capacité en Pause
• Le coût de stockage persiste sur une capacité en Pause
• ⚠️ Les dépassements cumulés restants et les opérations lissées sur votre capacité sont additionnés et ajoutés à votre facture Azure

Documentation : Pause and resume your capacity – Microsoft Fabric | Microsoft Learn

Quelques ressources pour automatiser la gestion des capacités :

• fileshare/CapacityFlows
• fileshare/CapacityChecker
• manage_fabric_capacity_python_runbook

Une question fréquemment posée par les clients concerne la meilleure stratégie de déploiement : Une capacité par projet, une capacité par domaine, une capacité pour plusieurs projets, ou encore la meilleure répartition des Workspaces sur une capacité. Il n’existe pas de réponse unique à cette question car cela dépend de l’organisation, des considérations en termes de management, de sécurité, du cycle de vie du développement, de la sécurisation des données, de leur localisation, de la gestion des coûts, ainsi que de la structure de l’entreprise et des projets. Voici quelques bonnes pratiques et Pattern :

• Power BI implementation planning: Tenant-level workspace planning
• Deployment patterns for Microsoft Fabric

Maintenant, si un Workspace ou un objet prend toutes les ressources d’une capacité, comment faire ?

Nous avons précédemment appris à identifier le Workspace et le ou les objets qui génèrent le plus de CUs via la Metrics App.

Plusieurs niveaux de réponses :

• Remédiation rapide :
  • Scale Up : Augmentation de la capacité en question (tarification à l’heure), automatisation custom possible
  • Scale Out : Tirer parti des capacités plus petites et donc moins chères offrant une plus grande flexibilité telles que les F2 et créer des capacités additionnelles afin de déplacer des Workspaces, automatisation possible : https://www.microsoft.com/en-us/microsoft-fabric/blog/2024/12/02/automate-your-migration-to-microsoft-fabric-capacities/. Cette option permet d’isoler rapidement les mauvais acteurs (éléments dont la consommation de CU est élevée)
• Remédiation moins rapide :
  • Optimisation : Collaborer avec les créateurs de contenu pour vérifier que les bonnes pratiques sont respectées sinon y apporter les corrections
  • Sensibiliser au bon usage : Certaines mauvaises pratiques récurrentes chez les clients comme l’export de toutes les données pour une analyse dans Excel entraine une grosse consommation des ressources et posent des problèmes de sécurité. Si analyse dans Excel il est recommandé de sélectionner d’abord les filtres, puis les mesures avant les autres champs
• Remédiation proactive :
  • Isolation : Isoler les projets sensibles, les rapports pour la Leadership Team, les environnements de Développements de ceux de Production, … Tester un nouveau traitement sur une capacité de test peut être utile pour connaître à l’avance son impact sur la capacité cible avant son déploiement
  • Capacité de sauvetage : Disposer d’une capacité de sauvetage (en pause ou pas) afin de rapidement pouvoir basculer des Workspaces et permettre à leurs traitements de s’exécuter
  • Show back & Charge back : Permettre à tous et à tout niveau de visualiser la qualité des développements et leur impact sur la consommation des ressources, exemple avec ma solution de suivi de la qualité des modèles sémantiques : Monitoring the quality of Power BI Semantics Models over time. Il est désormais possible de vérifier via un Notebook la qualité des développements des modèles sémantiques (Best Practice Analyzer Report.ipynb, Model Optimization.ipynb) et des rapports (Report Analysis.ipynb) et ainsi de sensibiliser tout le monde aux bonnes pratiques de développement
  • DataOps : Le déploiement automatisé peut permettre l’automatisation de vérification quant à la qualité des données et des développements tel qu’expliquer dans mon article Le DataOps avec Power BI et Microsoft Fabric
  • Investir dans l’éducation, le partage des connaissances et des meilleures pratiques, la création d’un centre d’excellence, et se tenir au courant des nouvelles fonctionnalités
  • Configuration : Certains paramètres permettent de limiter l’impact sur l’utilisation des CU, comme les paramètres avancés au-dessus des Workspaces pour les sémantiques modèles (Granular control with Analysis Services server properties) ou les limites au niveau du Tenants Settings quant à l’usage de certains Workloads (API for GraphQL, ..) ou certaines fonctionnalités (Export, Scale Out, …) ou au-dessus des Capacités comme l’allocation des ressources aux Spark Pools (Certains paramètres pouvant être délégués). D’autres fonctionnalités en ce sens ont été annoncées telles que le Fabric Surge Protection pour limiter l’impact des activités Background :

Workload Optimization

Nous avons identifié l’objet dans le Workspace à optimiser, je ne rentrerai pas ici dans le détail des optimisations de chacun des types d’objets dans Microsoft Fabric (l’article est je pense déjà suffisamment long !). Mais regardons quelques erreurs récurrentes :

• Si dans une capacité la majeure proportion de consommation des CU est liée à des activités Background sur les Sémantique modèles ou liée à des Dataflows alors je vérifierais les requêtes Power Query, l’usage du Query Folding ou du chargement incrémentiel (Best practices when working with Power Query – Power Query). Il va de soi que de rafraichir un Sémantique modèle toutes les 30 minutes en mode full alors que la donnée sous-jacente n’évolue qu’une fois par an est un gaspillage de ressources
• Pour les Dataflows Gen 2 et en fonction de la source de données l’option de Fast copy peut être testée afin de diminuer le temps ainsi que le coût d’exécution

• Si la majorité des ressources est consommée par les requêtes interactives sur des modèles sémantiques, alors je vérifierai la qualité des modèles, les relations, le RLS, OLS, les Measures DAX, … (Best practice rules to improve your models performance and design). Je vérifierai aussi les rapports qui trop souvent ont trop de visuels…

• Pour les Notebooks je vérifierai l’usage de la haute concurrence (High concurrency mode in Apache Spark compute for Fabric), le paramètre d’Autotune ainsi que la version et les Pools utilisés ou encore le temps d’expiration des sessions (l’expiration de la session par défaut est fixée à 20 minutes pour les sessions interactives Spark)
• Enfin dans certains cas, le choix du Workload n’est tout simplement pas le plus adéquat :
  • Microsoft Fabric Decision Guide: Choose between Warehouse and Lakehouse
  • Fabric decision guide – choose a data store

💡Pour avoir davantage d’information sur les temps d’exécution de certaines activités il est possible d’activer Azure Log Analytics in Power BI ou encore plus récemment Workspace monitoring.

Je pourrais citer quelques autres pistes d’optimisations telles que :

• La recherche de Dark Data, ces données stockées mais jamais utilisées, ou encore pire, traitées, rafraichies, transformées mais jamais utilisées (Getting the size of OneLake data items or folders)
• Sauvegarder suffisamment d’historiques pour les besoins d’analyse ou de conformité mais pas plus
• Maximiser la compression des données (Optimize & Vaccum Delta table maintenance in Microsoft Fabric)
• …

Cloud Sustainability

Alors que nous sommes de plus en plus sensibles à la bonne utilisation des ressources, à l’empreinte carbone des usages, à l’utilisation des énergies renouvelables, au recyclage… Le FinOps peut être vu comme une démarche de sensibilisation au Green IT ♻️. Le principal défi sous-jacent ? Trouver le bon compromis entre le budget et les dépenses attribuées aux services Cloud tout en offrant la performance et l’innovation IT recherchées. Et cela passe par les trois étapes : Informer, Optimiser et Exploiter.

2.4 – Manage the FinOps Practice

Dans ce quatrième et dernier Domaine de la FinOps Fondation, les organisations doivent constamment s’améliorer et appliquer les recommandations FinOps à leurs employés, processus et technologies.

FinOps Practice Operations

Comme le DevOps, le DataOps vise à automatiser la conception et le déploiement vers la production en prenant en compte les challenges humains, méthodologiques et technologiques. Le FinOps, c’est l’alter ego du DataOps pour tout ce qui concerne la supervision financière. Et comme le DataOps, le FinOps puise sa philosophie dans les méthodes agiles, avec en ligne de mire la satisfaction des attentes métiers (ici, les financiers, mais aussi les opérationnelles).

Ainsi pour améliorer la collaboration et réduire les cycles de développement, les erreurs, la sécurité, la gouvernance, … les équipes doivent adopter le Continuous Integration/Continuous Delivery (CI/CD). Vous trouverez dans les liens suivants quelques recommandations : Enterprise content publishing, Introduction to the CI/CD process as part of the ALM cycle in Microsoft Fabric.

Cloud Policy & Governance

La création d’un centre d’excellence (Center of Excellence) pour promouvoir les bonnes pratiques, partager les succès, créer une communauté avec des champions dans les différents départements de l’organisation (Community of practice), définir des responsables de Domaine,…

Afin d’éviter la prolifération des données, des rapports, pensez à exploiter la certification et la promotion (Endorse Fabric).

Vous trouverez un exemple de plan d’adoption à l’adresse suivante (💡 Pourquoi ne pas y ajouter un volet FinOps ?) : Microsoft Fabric adoption roadmap

Intersecting Disciplines

Il est important de coordonner les activités FinOps avec les disciplines interconnectées, les métiers ou encore les Personas alliées (telles que ITAM, ITFM, Durabilité, Sécurité) qui gèrent des responsabilités plus larges et qui doivent s’intégrer dans la stratégie de l’organisation.

 

3 – Conclusion

En résumé, l’adoption des pratiques FinOps est essentielle pour garantir une gestion efficace des coûts et une maximisation de la valeur générée par les technologies Cloud. En intégrant cette méthodologie basée sur l’agilité et la collaboration entre les équipes financières et opérationnelles, les organisations peuvent optimiser leurs usages et la consommation des ressources Cloud en perpétuelle évolution.

Dans cette article, j’ai partagé quelques apprentissages dans l’optimisation de l’usage et de la consommation des ressources du service SaaS Microsoft Fabric mais il y aurait bien d’autres choses à dire sur le sujet, d’ailleurs n’hésitez pas à enrichir cette liste.

Il est essentiel de surveiller régulièrement les coûts et la consommation par rapport à la valeur générée, et de les comparer entre différents domaines ou projets :

L’approche progressive de Crawl, Walk, Run permet aux organisations d’acquérir progressivement une maturité en FinOps, assurant ainsi une optimisation continue et une prise de décision éclairée.

L’engagement dans une démarche FinOps conduit à une utilisation stratégique et responsable de Microsoft Fabric, n’hésitez pas à consulter cette checklist d’optimisation (Optimize cost) et à comparer votre maturité (Microsoft Fabric adoption roadmap maturity levels) ainsi que de vous former (continuellement) FinOps on Azure.

A ce titre, n’hésitez pas à consulter notre livre sur Microsoft Fabric : Microsoft Fabric – De l’analyse à la mise en place d’une plateforme de données unifiée

Et à vous abonner à la chaine YouTube Data Chouette 🦉: https://www.youtube.com/@DataChouette