Établir des gammes de produits de distribution d’abonnements courantes
La vente d’abonnements permet aux organisations d’atteindre les principes de conception de démocratisation des abonnements pour les zones d’atterrissage Azure, ce qui est essentiel pour la cohérence de la mise à l’échelle, de la sécurité et de la gouvernance des environnements Azure. La vente d’abonnements aide également les organisations à s’aligner sur les principes d’ingénierie de plateforme. Pour plus d’informations, consultez Adopter un état d’esprit axé sur les produits and Habiliter les développeurs grâce au libre-service avec des garde-fous.
De nombreuses organisations ont du mal à donner à leurs équipes d’application la flexibilité dont elles ont besoin pour fournir efficacement leurs charges de travail et services. L’un des principaux obstacles est l’absence d’une approche standardisée de distribution d’abonnements, ce qui peut entraîner confusion, retard et inefficacité.
Cet article explique comment les équipes de plateforme peuvent établir des gammes de produits de distribution d’abonnements courantes qui répondent aux différents besoins des différentes équipes d’application. L’article décrit les avantages de l’offre de différentes gammes de produits et fournit des exemples de scénarios courants basés sur des déploiements réels de clients. Vous découvrez également pourquoi la distribution d’abonnements n’a pas de conception à « taille unique » et pourquoi vous devez fournir différentes gammes de produits aux équipes d’application.
Le diagramme suivant montre l’organisation des groupes d’administration et des abonnements au sein d’un environnement Azure.
Les instructions suivantes expliquent pourquoi vous pouvez exiger différentes gammes de produits et décrire des exemples de gammes de produits pour les clients qui utilisent des zones d’atterrissage Azure et la distribution d’abonnements.
Tirer parti de différentes gammes de produits
Les abonnements dont les équipes d’application ont besoin pour fournir leurs charges de travail et leurs services existent sous de nombreuses formes. En dehors des équipes d’application, votre organisation peut avoir d’autres exigences qui nécessitent l’utilisation d’un abonnement Azure, comme diverses règles de conformité et de gestion des données ou des modèles d’architecture.
Lorsque vous décidez de l’approche de votre organisation pour concevoir et implémenter la distribution d’abonnements, envisagez de poser les questions suivantes :
Quelles autres ressources l’équipe de plateforme doit-elle vendre dans le cadre du processus de distribution d’abonnements ?
Pour chaque équipe d’application, déployez-vous plusieurs abonnements, par exemple un par environnement, par défaut ?
Pour chaque application, appairez-vous ou connectez-vous le réseau virtuel spoke à vos hubs de connectivité par défaut ?
Comment structurer le contrôle d’accès en fonction du rôle (RBAC) dans chaque abonnement ?
Comment régir et contrôler les ressources et les styles d’architecture, ou archétypes, que vous utilisez dans les abonnements ?
Vous ne pouvez pas répondre aux exigences uniques de chaque équipe d’application et de plateforme avec n’importe quel type d’abonnement ou style d’abonnement que vous vendez. Les équipes de plateforme doivent donner aux équipes d’application la possibilité de choisir parmi plusieurs types et styles d’abonnements, que l’équipe peut vendre par le biais d’un système en libre-service. Ces types d’abonnements sont appelés gammes de produits.
Les organisations qui fournissent uniquement une approche à « taille unique » pour la distribution d’abonnements limitent souvent la flexibilité de leurs clients internes. Par exemple, le manque de flexibilité peut limiter les choix de conception d’architecture d’une équipe d’application et entraîner des compromis en raison de ce qui leur a été vendu.
Par conséquent, les équipes de plateforme doivent fournir différentes gammes de produits afin de répondre aux besoins de leur organisation. Cette flexibilité garantit que les consommateurs peuvent choisir la gamme de produits qui répond le mieux à leurs besoins.
Gérer les environnements d’application
Votre organisation doit gérer les environnements d’application pour les équipes d’application dans le cadre de vos processus et implémentations de distribution d’abonnements. Toutefois, vous devez également fournir une certaine flexibilité afin que les équipes d’application puissent gérer leurs environnements d’application, par exemple dev/test/prod, comme elles le souhaitent quand elles fournissent des applications. Pour plus d’informations, consultez Environnements, abonnements et groupes d’administration.
Certains services Azure fournissent des fonctionnalités natives pour isoler un environnement au sein d’une instance de ressource unique dans un abonnement Azure unique, comme Azure App Service avec sa fonctionnalité d’emplacements de déploiement. Cet exemple force les équipes d’application à utiliser des abonnements distincts ; les équipes ne peuvent ainsi pas tirer parti de l’ensemble complet de services fournis par Azure. Des abonnements distincts peuvent également augmenter les coûts de remise des applications, notamment avec une surcharge opérationnelle et de maintenance.
Concevoir des gammes de produits courantes pour la distribution d’abonnements
Maintenant que vous comprenez que les équipes de plateforme doivent fournir plusieurs types et styles d’abonnement Azure, ou gammes de produits, aux consommateurs de leur plateforme Azure, cette section décrit plusieurs gammes de produits courantes que vous pouvez utiliser dans les secteurs et les pays ou régions.
Votre équipe de plateforme doit utiliser ces gammes de produits de distribution d’abonnements courantes comme base de référence. Votre équipe peut fournir plusieurs options à ses consommateurs, ce qui s’aligne sur le principe d’ingénierie de plateforme consistant à donner priorité aux clients. Cette approche donne aux clients internes la liberté d’utiliser les principes de conception des zones d’atterrissage Azure et les recommandations de zone de conception pour fournir leurs charges de travail et leur service, et fournit également la gouvernance de la plateforme Azure.
Remarque
Utilisez ces exemples comme point de départ. Vous pouvez personnaliser et développer ces gammes de produits pour répondre aux besoins de votre organisation.
Les gammes de produits courantes pour la distribution d’abonnements sont les suivantes :
Connectée au réseau de l’entreprise : charges de travail nécessitant une connectivité de routage IP de couche 3 traditionnelle à d’autres applications et environnements locaux via l’abonnement Connectivité.
En ligne : charges de travail qui se connectent à d’autres applications via des services et architectures de connectivité modernes, comme Azure Private Link, ou une interaction via des API ou des points de terminaison exposés à partir de chaque application.
Plateforme technologique : charges de travail qui créent une plateforme sur laquelle vous pouvez créer d’autres applications. Par exemple, une flotte Azure Kubernetes Service (AKS) de clusters gérés par une équipe de plateforme AKS peut héberger d’autres applications au sein de ses clusters AKS pour le compte d’autres équipes d’application.
Portefeuille d’applications partagé : charges de travail partagées entre les mêmes équipes d’application pour un ensemble commun d’applications étroitement couplées. Vous ne souhaitez pas héberger les applications seules ou avec une charge de travail spécifique.
Bac à sable : zone où les équipes d’application peuvent créer une preuve de concept (PoC) ou un produit minimum viable (MVP) et imposer moins de contrôles, afin que l’équipe puisse promouvoir le développement, l’inventivité et la liberté de créer la meilleure application possible à partir du catalogue de services Azure disponibles.
Gamme de produits connectée au réseau Corp
La gamme de produits connectée au réseau de l’entreprise, aussi appelée gamme de produits interne ou privée, pour la distribution d’abonnements de zone d’atterrissage d’application, fournit une connectivité via des méthodes IP de couche 3 traditionnelles. Vous pouvez utiliser cette gamme de produits pour fournir une connectivité entre les ressources :
Dans la même zone d’atterrissage d’application.
Dans différentes zones d’atterrissage d’application connectées à l’entreprise via un pare-feu Azure ou une appliance virtuelle réseau (NVA).
Localement ou dans différents clouds via Azure ExpressRoute ou des connexions VPN.
Les organisations qui utilisent la distribution d’abonnements incorporent souvent cette gamme de produits, car elle s’aligne étroitement sur la façon dont la plupart des environnements locaux fonctionnent aujourd’hui. Toutefois, vous devez uniquement utiliser la gamme de produits connectée à l’entreprise lorsque cela est nécessaire. Nous vous recommandons de favoriser des approches cloud natives plus modernes, comme la gamme de produits en ligne, lorsque vous le pouvez.
Conseil
Pour plus d’informations sur les différences entre les charges de travail d’entreprise et en ligne, consultez Quel est l’objectif des groupes d’administration Connectivité, Entreprise et En ligne ?.
Le diagramme suivant montre un exemple de gamme de produits de distribution d’abonnements connectée à l’entreprise. Vous pouvez utiliser cette configuration pour un modèle réseau hub-and-spoke pour gérer efficacement le trafic réseau et les stratégies.
Quand utiliser la gamme de produits connectée à l’entreprise
Utilisez la gamme de produits connectée à l’entreprise quand :
Vous souhaitez effectuer des migrations Réhéberger et Refactoriser, et créer des applications basées sur les cinq R de la rationalisation.
Vous souhaitez commencer votre parcours dans Azure et vous connaissez une architecture locale similaire.
Vous souhaitez effectuer une migration lift-and-shift des applications vers Azure.
Vous souhaitez améliorer la sécurité entre les charges de travail en isolant les applications dans leurs propres abonnements de zone d’atterrissage et en passant aux principes de micro-segmentation de confiance zéro sans réorganiser l’application dans l’immédiat pour la rendre entièrement native cloud.
Prenez note de ces autres considérations relatives à la gamme de produits connectée à l’entreprise :
Votre équipe de plateforme peut vendre le réseau virtuel dans l’abonnement de zone d’atterrissage d’application et appairer le réseau virtuel au réseau virtuel du hub régional ou au hub Azure Virtual WAN. Votre équipe peut ensuite utiliser un outil de gestion des adresses IP (IPAM) pour contrôler l’allocation d’adresses IP.
Les équipes de plateforme ne vendent généralement pas de sous-réseaux ni d’autres ressources dans le réseau virtuel. Les équipes de plateforme attribuent plutôt ces activités aux équipes d’application, afin qu’elles puissent concevoir leur mise en réseau d’applications comme elles le souhaitent.
Les équipes de plateforme utilisent une stratégie Azure affectée aux groupes d’administration au-dessus de l’abonnement pour appliquer le comportement souhaité, par exemple les groupes de sécurité réseau standardisés attachés à chaque sous-réseau. L’équipe d’application hérite de cette stratégie Azure et ne peut pas la modifier. Cette approche suit le principe de conception de zone d’atterrissage Azure pour la démocratisation des abonnements.
Gamme de produits en ligne
La gamme de produits en ligne, également appelée gamme de produits externe ou publique, pour la distribution d’abonnements de zone d’atterrissage d’application, ne fournit pas de connectivité via des méthodes IP de couche 3 traditionnelles entre les ressources dans d’autres zones d’atterrissage d’application ou localement via ExpressRoute ou les connexions VPN. Les ressources de la même zone d’atterrissage d’application en ligne peuvent utiliser des réseaux virtuels pour communiquer entre elles via des méthodes IP de couche 3. Toutefois, les réseaux virtuels ne sont généralement pas appairés avec des hubs de connectivité régionaux ou d’autres zones d’atterrissage d’application.
Au lieu de cela, vous pouvez fournir une connectivité via des interfaces publiques entre les ressources :
Dans différentes zones d’atterrissage d’application.
Locale.
Dans des charges de travail qui se trouvent dans différents clouds.
Vous pouvez sécuriser les connexions avec des contrôles réseau, des fonctionnalités d’authentification et des fonctionnalités d’autorisation qui sont exposées par les différentes solutions PaaS (Platform as a Service) que vous utilisez pour créerl’application.
Vous pouvez utiliser le service Private Link et les points de terminaison privés Azure au sein et entre les abonnements de zone d’atterrissage d’application en ligne pour activer et exposer une connectivité privée et basée sur la couche 3 entre les applications. Vous pouvez également utiliser cette approche entre les services PaaS que vous utilisez dans les zones d’atterrissage d’application pour empêcher l’utilisation des interfaces publiques de ces services PaaS, à des fins de sécurité ou de contrôle réglementaire.
Vous pouvez également utiliser le service Private Link avec des points de terminaison privés pour exposer et publier des applications que vous hébergez dans des zones d’atterrissage d’application en ligne pour des zones d’atterrissage d’application connectées à l’entreprise, des emplacements locaux ou d’autres clouds. Vous pouvez placer des points de terminaison privés dans des zones d’atterrissage d’application connectées à l’entreprise ou directement dans des hubs de connectivité, qui accordent ensuite l’accès à ces points de terminaison privés via des méthodes de connectivité de couche 3 traditionnelles, comme le peering de réseaux virtuels, les connexions ExpressRoute ou les connexions VPN.
Considérez la gamme de produits de zone d’atterrissage d’application en ligne comme des îles isolées. Par défaut, les seules ressources qui peuvent accéder aux ressources de l’abonnement sont les ressources que vous déployez dans le même abonnement de zone d’atterrissage d’application en ligne. Comme mentionné précédemment, vous pouvez ensuite utiliser les techniques décrites dans cet article pour étendre la connectivité à d’autres zones d’atterrissage d’application, à des emplacements locaux ou encore à d’autres clouds.
Conseil
Pour plus d’informations sur les différences entre les charges de travail d’entreprise et en ligne, consultez Quel est l’objectif des groupes d’administration Connectivité, Entreprise et En ligne ?.
Le diagramme suivant montre un exemple d’une gamme de produits de distribution d’abonnements en ligne.
Quand utiliser la gamme de produits en ligne
Utilisez la gamme de produits en ligne lorsque vous souhaitez :
Refactoriser, réarchitecter, générer à nouveau ou effectuer des migrations et des builds d’applications, conformément aux cinq R de la rationalisation.
Fournir aux équipes d’application une zone d’atterrissage d’application entièrement démocratisée à utiliser, y compris pour la configuration réseau.
Tirer parti des services et architectures natifs cloud.
Améliorer considérablement l’alignement avec les principes de confiance zéro.
Utiliser la gamme de produits connectée à l’entreprise, quand l’espace d’adressage IP privé n’est pas disponible ou limité.
- Dans ce scénario, vous devez consulter les instructions d’Empêcher l’épuisement IPv4 dans Azure.
La gamme de produits de plateforme technologique
Les équipes qui utilisent des plateformes technologiques, comme Azure VMware Solution ou Azure Virtual Desktop, doivent implémenter la gamme de produits de plateforme technologique. La gamme de produits de plateforme technologique est essentiellement une gamme de produits de distribution d’abonnements qui répond mieux aux exigences très techniques. Vous pouvez utiliser la gamme de produits de plateforme technologique pour héberger et gérer des charges de travail volumineuses et complexes qui hébergent généralement plusieurs applications pour plusieurs autres équipes d’application au sein de votre organisation. Utilisez cette gamme de produits si votre équipe d’application gère uniquement les parties d’application et non les parties de plateforme technologique sous-jacentes.
Conseil
Pour mieux comprendre cette gamme de produits, prenons l’exemple suivant. Une équipe de plateforme technologique, comme une équipe AKS, vise à offrir AKS en tant que service managé à d’autres équipes d’application qui doivent exécuter leurs applications sur la plateforme AKS. L’équipe de plateforme technologique AKS fournit la gestion, la maintenance, la sécurité et la configuration d’AKS. Ainsi, l’équipe d’application entretient uniquement son application et la déploie sur la plateforme.
Vous pouvez inclure les produits suivants dans une gamme de produits de plateforme technologique :
Un environnement App Service, généralement via des plans App Service distincts.
AKS, généralement via des espaces de noms au sein d’un ou plusieurs clusters.
Des machines virtuelles Azure sur des clusters ou des hôtes Azure VMware Solution.
Azure Virtual Desktop, pour fournir des bureaux virtuels ou des applications à l’ensemble de votre organisation.
Vous pouvez inclure ces produits dans des gammes de produits connectées à l’entreprise ou en ligne, en fonction des exigences de la plateforme technologique que votre équipe souhaite fournir en tant que service à d’autres équipes d’application de votre organisation.
Portefeuille d’applications partagé
La gamme de produits de portefeuille d’applications partagé pour la distribution d’abonnements de zone d’atterrissage d’application concerne les charges de travail qui n’ont pas besoin de plusieurs abonnements de zone d’atterrissage d’application distincts pour les applications simples qui peuvent être créées à partir d’un petit nombre de ressources Azure.
Vos équipes et services d’application peuvent utiliser cette gamme de produits pour héberger plusieurs petites applications ou des composants partagés, comme des comptes de stockage ou des serveurs SQL. Les équipes partagent ces composants entre plusieurs de leurs propres applications dans un abonnement uniquement ou un petit nombre d’abonnements.
Important
Une équipe commune possède des abonnements que vous vendez sous cette gamme de produits. Cette équipe gère le portefeuille d’applications associé que vous déployez dans cet abonnement pour cette gamme de produits. N’utilisez pas cette gamme de produits pour les déploiements généraux de charges de travail d’application non liées qui ont des propriétaires de portefeuille d’applications distincts.
Planifiez soigneusement la flexibilité, le contrôle d’accès, la gouvernance et la facilité de maintenance si votre organisation passe à un abonnement unique et utilise des groupes de ressources pour déléguer l’accès.
Si vous envisagez la délégation de groupes de ressources dans un abonnement unique entre plusieurs équipes, envisagez les points suivants avant de prendre une décision finale :
Zone | À propos de l’installation |
---|---|
Propriété commune du portefeuille d’applications liées | - Ayez un propriétaire commun, comme une unité commerciale d’un service, gérez les applications pour simplifier la gestion des modifications afin qu’elle reste dans l’étendue d’approbation de la même entité. - Assurez-vous que les charges de travail suivent une attribution de stratégies cohérente dans l’abonnement, notamment concernant la journalisation, la surveillance et la sécurité. |
Conformité aux normes | - Utilisez IAM et des stratégies Azure pour créer des abonnements pour les charges de travail qui ont des exigences de conformité réglementaire, notamment le National Institute of Standards and Technology (NIST), le Center for Internet Security (CIS), le Payment Card Industry Security Standards Council (PCI SSC), les exigences sectorielles et les exigences régionales. Pour plus d’informations, consultez Adapter les zones d’atterrissage Azure. - Créez des abonnements pour les charges de travail qui utilisent des exigences de confidentialité et de gestion des données pour la gouvernance. Les abonnements individuels réduisent l’accès. |
Azure Policy | Les stratégies Azure peuvent être étendues à des ressources, des groupes de ressources, des abonnements et des groupes d’administration. Attribuez des stratégies Azure à un niveau élevé pour une gouvernance efficace lorsque vous déployez des ressources dans des groupes de ressources. Tenez compte des contraintes suivantes lorsque vous gérez Azure Policy au niveau de l’étendue du groupe de ressources : - Augmente la surcharge de gestion pour la création d’affectations Azure Policy lorsque vous ajoutez de nouveaux groupes de ressources à des abonnements - Augmente la charge de travail lorsque vous gérez les modifications apportées aux affectations de stratégie - Augmente les lacunes de sécurité et de gouvernance lorsque vous n’affectez pas immédiatement des stratégies aux groupes de ressources - Réduit la possibilité de déployer l’état de conformité à des étendues élevées, comme les groupes d’administration et les abonnements |
Limites d’abonnement | - Vérifiez les limites pour vous assurer que les applications n’atteignent pas de limites strictes qui empêchent la croissance. Chaque abonnement a des limites souples et strictes pour les services Azure. - Créez des abonnements distincts pour les applications qui prévoient de grands modèles de croissance afin de répondre aux limites d’abonnement. - Ne partagez pas d’abonnements avec des équipes d’application provenant de différentes unités commerciales ou de différents services pour éviter les problèmes de voisinage bruyant. |
Alignement des services et des fonctionnalités Azure | Vous pouvez déployer des services qui fournissent des primitives de service Azure de base, comme des machines virtuelles, des réseaux virtuels et des services PaaS simples, au sein d’un même groupe de ressources. Toutefois, la complexité des offres composites modernes peut nécessiter que vous déployiez ces services plus complexes en dehors des limites d’un groupe de ressources unique. Utilisez les autres approches d’abonnement démocratisées décrites plus haut dans cet article pour ces scénarios de déploiement. |
Seules les équipes de plateforme peuvent créer des groupes de ressources | Lorsque vous partagez un abonnement entre différentes équipes d’application entre unités commerciales ou services, vous pouvez restreindre la capacité de toute équipe à créer de nouveaux groupes de ressources dans l’abonnement partagé. Cette restriction limite l’expansion du groupe de ressources. Seule l’équipe de plateforme peut créer et contrôler de nouveaux groupes de ressources. Cette approche augmente la complexité des affectations RBAC et place une dépendance accrue sur les équipes de plateforme pour la gestion des déploiements d’applications, ce qui peut entraver l’agilité et l’autonomisation des équipes d’application. |
Vous pouvez placer les abonnements que vous vendez dans la gamme de produits de portefeuille d’applications partagé sous les groupes d’administration d’entreprise ou en ligne. Cette méthode s’aligne sur la hiérarchie recommandée par défaut pour les zones d’atterrissage Azure. Vous pouvez également placer les abonnements sous de nouveaux groupes d’administration, si la hiérarchie des groupes d’administration de votre organisation suit les instructions de Personnaliser l’architecture d’une zone d’atterrissage Azure pour répondre aux besoins.
Le diagramme suivant illustre un exemple d’une gamme de produits de distribution d’abonnements de portefeuille d’applications partagé.
Utilisez la gamme de produits de portefeuille d’applications partagé si :
Votre équipe d’application doit fournir plusieurs petites ressources ou petits composants que leurs applications partagent, mais que les composants ne tiennent pas directement dans les zones d’atterrissage d’application dédiées.
Vous disposez de ressources ou de composants que vous devez partager entre les applications du même service, mais les composants ne tiennent pas directement dans les zones d’atterrissage des applications dédiées.
Les équipes de plateforme technologique souhaitent héberger de grands services partagés gérés, comme AKS, Azure Virtual Desktop et Azure VMware Solution, afin que d’autres équipes d’application puissent utiliser ou héberger leurs applications sur les services.
Bac à sable
Utilisez la gamme de produits de bac à sable pour la distribution d’abonnements de zone d’atterrissage d’application pour vous aider à fournir des zones de test sécurisées, régies au minimum et visibles pour créer des PoC ou des MVP dans Azure.
Pour plus d’informations, consultez Environnements de bac à sable de zone d’atterrissage et Gérer les environnements de développement d’applications dans les zones d’atterrissage Azure.
Les bacs à sable sont souvent limités dans le temps ou limités par le budget, ce qui signifie qu’ils ont une limite de temps ou une limite budgétaire. Dans ces cas, vous devez soit étendre soit supprimer et désactiver le bac à sable.
Si votre organisation ne fournit pas de gamme de produits de bac à sable pour les équipes d’application ou d’autres personnes afin de tester et d’expérimenter des services dans Azure, les équipes peuvent recourir à des configurations informatiques fantômes. Dans ce cas, votre organisation pourrait avoir du mal à fournir des rapports et une visibilité, et à appliquer la gouvernance aux abonnements que les utilisateurs professionnels créent en dehors du contrôle et de la supervision de votre équipe de plateforme.
Votre équipe de plateforme doit fournir un accès facile, de préférence en libre-service, et un accès automatiquement approuvé aux abonnements de bac à sable pour les utilisateurs et les équipes de votre organisation. Fournissez aux utilisateurs et aux équipes l’accès à un environnement que votre équipe de plateforme peut afficher et régir pour empêcher les environnements informatiques fantômes auxquels l’équipe de plateforme ne peut pas accéder hors de son contrôle, ce qui crée des risques.
Les bacs à sable suivent souvent l’approche de configuration réseau des abonnements de gamme de produits en ligne, car vous ne les appairez pas à d’autres réseaux virtuels en dehors de la limite d’abonnement du bac à sable. Les bacs à sable ont également souvent des contrôles supplémentaires pour empêcher la connectivité hybride à des emplacements locaux ou d’autres emplacements. Utilisez ces contrôles empêcher les sources inconnues d’exfiltrer des données de bac à sable vers des emplacements non approuvés. Vous pouvez utiliser une stratégie Azure pour appliquer ces contrôles.
Tout comme le portefeuille d’applications partagé et les gammes de produits de plateforme technologique, vous pouvez également partager la gamme de produits de bac à sable entre équipes du même service avec les mêmes considérations. Ne créez pas d’abonnement de bac à sable unique en vue de le partager entre équipes via des groupes de ressources. Au lieu de cela, créez des abonnements de bac à sable supplémentaires.
Utilisez la gamme de produits de bac à sable si vous devez fournir un abonnement Azure sûr, sécurisé et régi à toute personne de votre organisation qui souhaite expérimenter, ou créer des PoC ou MVP dans Azure. Vous devez gouverner au minimum ces utilisateurs et leur accorder l’accès à tous les services pour empêcher les pratiques informatiques fantômes.
Résumé et points clés à retenir
Cet article décrit les instructions prescriptives pour vous aider à naviguer dans des processus complexes de distribution d’abonnements et à passer à l’implémentation.
Déterminez les exigences de vos futures équipes d’application pour choisir la gamme de produits de distribution d’abonnements qui leur convient le mieux. Identifiez les exigences pour l’ensemble initial de charges de travail que vous créez ou migrez pour hiérarchiser les gammes de produits de distribution d’abonnements que vous souhaitez activer et exposer via une interface en libre-service.
Chaque gamme de produits a un coût d’implémentation et un coût de maintenance. Évaluez le coût à long terme par rapport aux avantages et à l’utilisation attendue à long terme.
Les clients commencent généralement par activer les gammes de produits de distribution d’abonnements suivantes :
Ressources supplémentaires
Pour soutenir votre approche d’ingénierie de plateforme, passez en revue les ressources suivantes lorsque vous concevez et implémentez des gammes de produits et offres de distribution d’abonnements pour votre organisation :
- Vidéo : How many subscriptions should I use in Azure ?
- Zones d’atterrissage de plateforme et d’application
- Stratégie incluses dans les implémentations des informations de référence sur les zones d’atterrissage Azure
- Personnaliser l'architecture d'une zone d'atterrissage Azure pour répondre aux besoins
- Quel est l’objectif des groupes d’administration Connectivité, Corp et Online ?
- Gérer les environnements de développement d'applications dans les zones d'atterrissage Azure
- Principes d’ingénierie de plateforme
Étape suivante
Pour obtenir de meilleurs résultats, vous devez automatiser autant que possible le processus de distributeur d’abonnements. Utilisez les conseils complémentaires sur l’implémentation de l’automatisation du distributeur d’abonnements.