Cet article décrit quatre modèles de déploiement que vous pouvez choisir lors du déploiement de Microsoft Fabric. Découvrez les réflexions, les recommandations et les décisions non réversibles potentielles pour chaque modèle de déploiement.
Les domaines de conception suivants sont décrits pour chaque modèle de déploiement Fabric :
- Gouvernance
- Sécurité
- Administration
- DevOps
- Usage
- Performances et mise à l’échelle
- Gestion de la facturation et des coûts
Niveaux dans un déploiement Fabric
Un déploiement Fabric comporte quatre niveaux : locataire, capacité, espace de travail et élément. Au niveau supérieur se trouve le locataire Fabric. Chaque locataire peut avoir une ou plusieurs capacités, chaque capacité peut contenir un ou plusieurs espaces de travail, et chaque espace de travail peut contenir zéro ou plusieurs éléments Fabric.
La structure ou les objectifs d’une organisation dans les domaines de la sécurité, de la mise à l’échelle, de la gouvernance et du cycle de vie des applications peuvent influencer le choix du modèle de déploiement. Les différents modèles de déploiement offrent une flexibilité variable et mettent l'accent sur des niveaux différents.
Par exemple, une organisation peut utiliser des domaines pour regrouper des espaces de travail dans Fabric. De même, si une organisation doit disposer d'une option centralisée qu'elle peut utiliser pour collaborer et trouver du contenu, un hub de données OneLake dans Fabric offre un point d'accès centralisé et est intégré à d'autres produits couramment utilisé, tels que Microsoft Teams et Excel.
Dans Fabric, une grande organisation composée de divisions situées dans des lieux géographiques distincts peut utiliser les capacités pour contrôler l'emplacement de ses données. Elle peut gérer une division qui opère à partir d'un emplacement géographique différent comme une seule unité en utilisant les domaines Fabric, car les domaines peuvent s'étendre sur des espaces de travail situés dans des régions différentes.
Pour en savoir plus sur les niveaux Fabric et leur rôle dans le choix d’un modèle de déploiement, consultez les concepts et licences Microsoft Fabric.
Comment les modèles de déploiement de Fabric s'alignent-ils ?
Tous les modèles de déploiement Fabric :
- Utilisent des espaces de travail Fabric comme limites pour la mise à l’échelle, la gouvernance et la sécurité.
- Utilisent des domaines Fabric pour la délégation, pour gérer plusieurs espaces de travail qui peuvent appartenir à la même division, ou lorsque les données appartenant à un domaine d’activité s’étendent sur plusieurs espaces de travail. Vous pouvez définir certains paramètres au niveau du locataire pour gérer et gouverner les données au niveau du domaine et utiliser la configuration spécifique au domaine pour ces paramètres.
- Utilisent les capacités Fabric pour mettre à l’échelle les ressources de calcul tout en provisionnant des capacités dédiées par espace de travail lorsque des niveaux de performance spécifiques doivent être respectés.
- S'étendent pour utiliser des fonctionnalités équivalentes à partir d'un cloud Microsoft (Microsoft Azure, Microsoft 365 et autres) lorsqu'une fonctionnalité n'est pas disponible dans Fabric.
- Utilisent un hub de données OneLake pour promouvoir la découverte et l’utilisation des ressources de données.
- Utilisent OneSecurity pour configurer des stratégies de sécurité des données pour les ressources de données.
Scénarios basés sur les exigences métier
Cet article s'appuie sur les scénarios suivants pour décrire comment chaque modèle de déploiement peut répondre aux différentes exigences métiers :
- Scénario 1 : pour les organisations qui souhaitent accélérer (ou ralentir) la mise sur le marché en organisant des équipes qui peuvent collaborer entre elles, avec moins de restrictions sur l'utilisation des données. Dans ce scénario, une organisation peut tirer parti d’un modèle de déploiement monolithique. L’organisation opère et gère un espace de travail unique. Pour en savoir plus, consultez Modèle 1 : déploiement monolithique.
- Scénario 2 : pour les organisations qui souhaitent fournir des environnements isolés à leurs équipes, avec une équipe centrale responsable de la fourniture et de la gestion de l'infrastructure. Ce scénario convient également aux organisations qui souhaitent implémenter le maillage de données. Dans ce scénario, une organisation peut implémenter plusieurs espaces de travail qui utilisent une capacité partagée ou ont des capacités distinctes. Pour en savoir plus, consultez : Modèle 2 : plusieurs espaces de travail soutenus par une capacité Fabric unique et Modèle 3 : plusieurs espaces de travail soutenus par des capacités distinctes.
- Scénario 3 : pour les organisations qui privilégient un modèle entièrement décentralisé donnant aux unités ou aux équipes la liberté de contrôler et de gérer leurs propres plates-formes de données. Dans ce scénario, une organisation peut choisir un modèle de déploiement dans lequel elle utilise des espaces de travail distincts, chacun avec une capacité dédiée ou éventuellement avec plusieurs locataires Fabric. Pour en savoir plus, consultez : Modèle 3 : plusieurs espaces de travail soutenus par des capacités distinctes et Modèle 4 : plusieurs locataires Fabric.
- Scénario 4 : une organisation peut choisir d’adopter une approche hybride dans laquelle elle combine plusieurs modèles pour répondre à ses exigences. Par exemple, une organisation peut configurer un espace de travail unique pour des divisions spécifiques (modèle de déploiement monolithique) tout en utilisant des espaces de travail distincts, dédiés et des capacités distinctes pour d’autres divisions.
Modèle 1 : déploiement monolithique
Ce modèle de déploiement vous permet de provisionner un espace de travail unique pour répondre à tous vos cas d'utilisation. Toutes les divisions travaillent dans le même espace de travail.
Lorsque vous provisionnez une capacité Fabric unique et que vous y attachez un espace de travail unique, les points suivants vrais :
- Tous les éléments Fabric partagent la même capacité provisionnée. La durée d'exécution d'une requête ou d'une tâche varie, car d'autres charges de travail utilisent la même capacité.
- Les unités de capacité maximale (UC) de l'espace de travail sont limitées à la plus grande référence F SKU ou P SKU possible. Pour les expériences d'ingénierie des données, vous pouvez provisionner des pools Spark séparés pour déplacer la capacité de calcul dont Fabric Spark a besoin en dehors des UC provisionnées.
- Les fonctionnalités liées à un espace de travail s'appliquent à toutes les divisions qui le partagent.
- Tous les éléments et données de l’espace de travail se trouvent dans une seule région. Vous ne pouvez pas utiliser ce modèle pour les scénarios incluant plusieurs zones géographiques.
- Les fonctionnalités qui dépendent de plusieurs espaces de travail, comme les pipelines de déploiement et la gestion du cycle de vie, ne sont pas disponibles.
- Les limitations associées à un espace de travail unique s’appliquent.
- Les limitations de capacité associées à une référence SKU spécifique s’appliquent.
Vous pouvez choisir d’implémenter ce modèle de déploiement pour une ou pour plusieurs des raisons suivantes :
- Votre organisation ne présente pas d'exigences techniques complexes, sa base d'utilisateurs est restreinte ou ses modèles sémantiques sont réduits.
- Votre organisation opère dans une seule région.
- La séparation organisationnelle entre les divisions n'est pas votre préoccupation première.
- Votre organisation n'a pas besoin de fonctionnalités liées à l'espace de travail, telles que le partage de référentiels de code avec Git.
- Vous souhaitez implémenter une architecture en médaillon lakehouse. Lorsque votre organisation est limitée à un seul espace de travail, vous pouvez séparer les couches bronze, argent et or en créant des lakehouses distincts au sein de l'espace de travail.
- Les divisions de votre organisation partagent des rôles, et on peut admettre que les utilisateurs de l'espace de travail disposent des mêmes autorisations au niveau de ce dernier. Par exemple, lorsque plusieurs utilisateurs appartenant à des divisions différentes sont administrateurs d'un même espace de travail, ils ont les mêmes droits sur tous les éléments de ce dernier.
- Votre organisation peut tolérer des délais d’exécution variables. Si une organisation ne présente pas d'exigences en matière de garanties de performance (par exemple, un travail doit être terminé dans un délai spécifique), on peut partager une capacité provisionnée unique entre les divisions. Lorsqu’une capacité est partagée, les utilisateurs peuvent exécuter leurs requêtes à tout moment. Le nombre d’unités de capacité disponibles pour exécuter un travail varie en fonction des autres requêtes qui s’exécutent sur la capacité. Il peut en résulter des délais d'exécution variables.
- Votre organisation peut répondre à toutes ses exigences métier (du point de vue de l'UC) en utilisant une seule capacité Fabric.
Le tableau suivant présente des considérations susceptibles de peser sur votre décision d'adopter ce modèle de déploiement :
| Aspect | À propos de l’installation |
|---|---|
| Gouvernance | - Des mandats de gouvernance et des restrictions moindres sont nécessaires pour la plateforme. - Il convient aux petites organisations qui préfèrent une mise sur le marché plus rapide. - Des difficultés peuvent apparaître si les exigences en matière de gouvernance deviennent plus complexes. |
| Sécurité - Plan de données | - Les données peuvent être partagées entre les équipes, de sorte qu'il n'est pas nécessaire d'avoir des restrictions sur les données entre elles. - Les équipes disposent de droits de propriété sur les modèles sémantiques. Elles peuvent lire, éditer et modifier des données dans OneLake. |
| Sécurité - Plan de contrôle | - Tous les utilisateurs peuvent collaborer dans le même espace de travail. - Il n’y a pas de restrictions sur les éléments. Tous les utilisateurs peuvent lire et modifier tous les éléments. |
| Administration | L’organisation dispose : - De coûts d'administration inférieurs - Aucun besoin strict de suivre et de contrôler l'accès et l'utilisation par équipe. - Une surveillance moins stricte de la charge de travail Fabric au sein des équipes. |
| DevOps | DevOps bénéficie des avantages suivants : - Une seule version pour l'ensemble de la plate-forme. - Des pipelines de mise en production moins compliqués. |
| Facilité d’utilisation - Administrateurs | - Les administrateurs peuvent le gérer plus facilement, car ils ont moins d'éléments à gérer. - Il n'est pas nécessaire de réaliser d'autres provisionnements ou de gérer les demandes des équipes pour de nouvelles capacités ou de nouveaux espaces de travail. - Les administrateurs de capacité peuvent être des administrateurs de locataires. Il n’est donc pas nécessaire de créer ou de gérer d’autres groupes ou équipes. |
| Facilité d’utilisation - Autres rôles | - On peut partager l’espace de travail avec d’autres utilisateurs. - La collaboration entre les utilisateurs est encouragée. |
| Niveau de performance | - L’isolation des charges de travail n’est pas obligatoire. - Aucun accord de niveau de service (SLA) strict ne doit être respecté. - La limitation est peu probable. |
| Gestion de la facturation et des coûts | - Une seule équipe peut gérer les coûts. - Il n'est pas nécessaire d'imputer les coûts à différentes équipes. |
Modèle 2 : plusieurs espaces de travail soutenus par une capacité Fabric unique
Ce modèle de déploiement vous permet d'utiliser des espaces de travail distincts. Étant donné qu'une capacité unique est partagée entre plusieurs espaces de travail, les charges de travail qui s'exécutent simultanément à tout moment peuvent affecter les performances des tâches et des requêtes interactives.
Lorsque vous provisionnez une capacité Fabric unique et que vous y attachez plusieurs espaces de travail, les points suivants vrais :
- Tous les éléments Fabric partagent la même capacité provisionnée. La durée d'exécution d'une requête ou d'une tâche varie, car d'autres charges de travail utilisent la même capacité.
- Le nombre maximal d’unités de capacité qu’un espace de travail peut utiliser est limité à la plus grande référence F SKU F ou P SKU possible. Pour les expériences d'ingénierie des données, vous pouvez provisionner des pools Spark séparés pour déplacer la capacité de calcul dont Fabric Spark a besoin en dehors des UC provisionnées.
- Les fonctionnalités liées à un espace de travail s'appliquent à toutes les divisions qui le partagent.
- Tous les éléments et données de l’espace de travail se trouvent dans une seule région. Vous ne pouvez pas utiliser ce modèle pour les scénarios incluant plusieurs zones géographiques.
- Vous pouvez utiliser des fonctionnalités DevOps qui nécessitent des espaces de travail distincts, comme pour les pipelines de déploiement et la gestion du cycle de vie.
- Les limitations associées à un espace de travail unique s’appliquent.
- Les limitations de capacité associées à une référence SKU spécifique s’appliquent.
Vous pouvez choisir d’implémenter ce modèle de déploiement pour une ou pour plusieurs des raisons suivantes :
- Vous voulez une architecture hub-and-spoke dans laquelle votre organisation centralise certains aspects de l'exploitation de l'environnement analytique et en décentralise d'autres.
- Vous souhaitez une décentralisation d'un point de vue opérationnel et de gestion, mais à des degrés divers. Par exemple, vous pouvez choisir de déployer les couches bronze et argent d'une architecture en médaillon dans un espace de travail et la couche or dans un autre. Vous pouvez justifier votre choix par le fait qu'une équipe est responsable des couches bronze et argent et qu'une autre équipe est responsable de l'exploitation et de la gestion de la couche or.
- Votre préoccupation première n'est pas la gestion des performances et l'isolation des charges de travail du point de vue des performances.
- Dans l'optique d'une architecture en médaillon, votre organisation peut créer des espaces de travail distincts pour implémenter les couches bronze, argent et or.
- Votre organisation n’a pas besoin de déployer des charges de travail dans différentes régions géographiques (toutes les données doivent résider dans une région).
- Votre organisation peut avoir besoin de séparer les espaces de travail pour une ou pour plusieurs des raisons suivantes :
- Les membres de l’équipe responsable des charges de travail se trouvent dans différents espaces de travail.
- Vous voulez créer des espaces de travail distincts pour chaque type de charge de travail. Par exemple, vous pouvez créer un espace de travail pour l’ingestion des données (pipelines de données, dataflow Gen2 ou ingénierie des données) et créer un espace de travail distinct pour la consommation via un entrepôt de données. Cette configuration fonctionne bien lorsque des équipes distinctes sont responsables de chacune des charges de travail.
- Vous voulez implémenter une architecture de maillage de données dans laquelle un ou plusieurs espaces de travail sont regroupés dans un domaine Fabric.
- Votre organisation peut choisir de déployer des espaces de travail distincts en fonction de la classification des données.
Le tableau suivant présente des considérations susceptibles de peser sur votre décision de choisir ce modèle de déploiement :
| Aspect | À propos de l’installation |
|---|---|
| Gouvernance | - Des mandats de gouvernance et des restrictions intermédiaires sont nécessaires pour la plateforme. - L'organisation a besoin d'un contrôle plus précis pour gérer les départements, les équipes et les rôles. |
| Sécurité - Plan de données | - Des restrictions de données sont nécessaires et vous devez assurer la protection des données sur la base de contrôles d'accès pour les départements, les équipes et les membres. |
| Sécurité - Plan de contrôle | - Pour éviter toute corruption accidentelle ou toute action d'utilisateurs malveillants, il peut s'avérer nécessaire de contrôler l'accès aux éléments Fabric en fonction du rôle. |
| Administration | - Vous n’avez pas besoin de gérer les capacités, car il s’agit d’un modèle à capacité unique. - Vous pouvez utiliser des espaces de travail pour isoler les services, les équipes et les utilisateurs. |
| DevOps | - Vous pouvez réaliser des versions indépendantes par département, équipe ou charge de travail. - Il est plus facile de répondre aux exigences de développement, de test, d'acceptation et de production (DTAP) pour les équipes lorsque plusieurs espaces de travail sont provisionnés pour chaque environnement de mise en production. |
| Facilité d’utilisation - Administrateurs | - Il n'est pas nécessaire de provisionner plusieurs capacités. - Les administrateurs de locataires gèrent généralement la capacité, vous n'avez donc pas besoin de gérer d'autres groupes ou équipes. |
| Facilité d’utilisation - Autres rôles | - Des espaces de travail sont disponibles pour chaque couche de médaillon. - Les éléments Fabric sont isolés par espace de travail, ce qui permet d’éviter une corruption accidentelle. |
| Niveau de performance | - Il n'est pas nécessaire de respecter des accords de niveau de service stricts. - La limitation est acceptable pendant les périodes de pointe. |
| Gestion de la facturation et des coûts | - Il n'y a pas d'exigence spécifique concernant la rétrofacturation par équipe. - Une équipe centrale prend en charge tous les coûts. - Les équipes d’infrastructure sont propriétaires des capacités Fabric dans l’organisation. |
Modèle 3 : plusieurs espaces de travail soutenus par des capacités distinctes
Ce modèle de déploiement vous permet de séparer les divisions de l'entreprise pour des raisons de gouvernance et de performance.
Lorsque vous provisionnez plusieurs capacités Fabric avec leurs propres espaces de travail, les points suivants sont vrais :
- La référence F SKU ou P SKU la plus grande possible attachée à un espace de travail détermine le nombre maximal d’unités de capacité que ce dernier peut utiliser.
- La décentralisation de l'organisation et de la gestion est assurée par le provisionnement d'espaces de travail distincts.
- Les organisations peuvent se développer au-delà d'une région en fournissant des capacités et des espaces de travail dans différentes régions géographiques.
- Vous pouvez utiliser toutes les capacités Fabric, parce que les unités métier peuvent avoir un ou plusieurs espaces de travail dans des capacités séparées et regroupées par le biais de domaines Fabric.
- Les limitations associées à un espace de travail unique s'appliquent, mais vous pouvez les dépasser en créant de nouveaux espaces de travail.
- Les limitations de capacité associées à une référence SKU spécifique s'appliquent, mais vous pouvez mettre à l'échelle les unités de capacité en provisionnant des capacités distinctes.
- Tous les éléments Fabric de tous les espaces de travail du locataire et leurs statuts de certification peuvent être découverts à l’aide d’un hub de données OneLake.
- Les domaines peuvent regrouper des espaces de travail de sorte qu'une seule unité métier puisse en exploiter et en gérer plusieurs.
- Les raccourcis OneLake réduisent le déplacement des données, ainsi que la facilité d’utilisation des données entre les espaces de travail.
Vous pouvez choisir d’implémenter ce modèle de déploiement pour une ou pour plusieurs des raisons suivantes :
- Votre organisation veut déployer des frameworks architecturaux tels qu'un maillage de données ou une fabrique de données.
- Vous voulez privilégier la flexibilité dans la manière dont vous structurez les capacités et les espaces de travail.
- Vous travaillez dans différentes régions géographiques. Dans ce cas, le provisionnement d'une capacité et d'un espace de travail distincts est le moteur de l'évolution vers ce modèle de déploiement avec plusieurs capacités et plusieurs espaces de travail.
- Vous travaillez à grande échelle et devez dépasser les limites d'une référence SKU à capacité unique ou d'un espace de travail unique.
- Vous disposez de charges de travail qui doivent toujours se terminer dans un délai spécifique ou répondre à un accord de niveau de service spécifique. Vous pouvez provisionner un espace de travail distinct soutenu par une capacité Fabric pour satisfaire aux garanties de performances pour ces charges de travail.
Le tableau suivant présente des considérations susceptibles de peser sur votre décision de choisir ce modèle de déploiement :
| Aspect | À propos de l’installation |
|---|---|
| Gouvernance | - Vous exercez un degré élevé de gouvernance et de gestion, et vous avez besoin d'indépendance pour chaque espace de travail. - Vous pouvez gérer l’utilisation par service ou par division. - Vous pouvez vous conformer aux exigences en matière de résidence des données. - Vous pouvez isoler les données en fonction des exigences réglementaires. |
| Sécurité - Plan de données | - L’accès aux données peut être contrôlé par service, par équipe ou par utilisateurs. - Vous pouvez isoler les données en fonction du type d’élément Fabric. |
| Sécurité - Plan de contrôle | - Pour éviter toute corruption accidentelle ou toute action d'utilisateurs malveillants, vous pouvez contrôler l'accès aux éléments Fabric en fonction du rôle. |
| Administration | - Les fonctionnalités d’administrateur granulaires sont limitées aux services, aux équipes ou aux utilisateurs. - Vous avez accès à des exigences de surveillance détaillées sur l'utilisation ou les modèles de charges de travail. |
| DevOps | - Vous pouvez isoler les environnements DTAP à l’aide de différentes capacités. - Les versions indépendantes sont basées sur un service, une équipe ou une charge de travail. |
| Facilité d’utilisation - Administrateurs | - Vous bénéficiez d’une visibilité granulaire de l’utilisation par service ou par équipe. - Vous avez délégué des droits de capacité à des administrateurs de capacité par département ou équipe, ce qui facilite la mise à l'échelle et la configuration granulaire. |
| Facilité d’utilisation - Autres rôles | - Les espaces de travail sont disponibles par couche et capacité de médaillon. - Les éléments Fabric sont isolés par espace de travail, ce qui permet d’éviter une corruption accidentelle. - Vous disposez d'un plus grand nombre d'options pour éviter la saturation causée par des surcharges de la capacité partagée. |
| Niveau de performance | - Les exigences en matière de performances sont élevées et les charges de travail doivent respecter des accords de niveau de service plus stricts. - Vous avez la possibilité d'augmenter les charges de travail individuelles par département ou par équipe. |
| Gestion de la facturation et des coûts | - Les exigences en matière de facturation croisée peuvent être facilement satisfaites en attribuant des capacités dédiées à une entité organisationnelle (département, équipe ou projet). - La gestion des coûts peut être déléguée aux équipes respectives. |
Modèle 4 : plusieurs locataires Fabric
Lorsque des locataires Fabric distincts sont déployés, toutes les instances de Fabric sont des entités distinctes en ce qui concerne la gouvernance, la gestion, l'administration, l'échelle et le stockage.
Les points suivants sont vrais lorsque vous utilisez plusieurs locataires Fabric :
- Les ressources des locataires sont strictement séparées.
- Les plans de gestion entre locataires sont séparés.
- Les locataires sont des entités distinctes et peuvent avoir leurs propres processus de gouvernance et de gestion, mais vous pouvez les administrer séparément.
- Vous pouvez utiliser des pipelines de données ou des capacités d’ingénierie des données pour partager ou accéder aux données entre les locataires Fabric.
Vous pouvez choisir d’implémenter ce modèle de déploiement pour les raisons suivantes :
- L'organisation peut se retrouver avec plusieurs locataires Fabric à la suite de l'acquisition d'une entreprise.
- L'organisation peut choisir de mettre en place un locataire Fabric spécifiquement pour une unité commerciale ou une petite filiale.
Contributeurs
Cet article est géré par Microsoft. Il a été écrit à l’origine par les contributeurs suivants.
- Holly Kelly | Responsable principale du programme
- Gabi Muenster | Responsable du programme senior
- Sarath Sasidharan | Responsable du programme senior
- Amanjeet Singh | Responsable principal du programme