Considérations relatives aux éditeurs de logiciels indépendants (ISV) pour les zones d’atterrissage Azure

Pour de nombreuses organisations, l’architecture conceptuelle de zones d’atterrissage Azure représente la destination de leur parcours d’adoption du cloud. Les zones d’atterrissage décrivent comment créer un environnement Azure avec plusieurs abonnements. Chaque zone d’atterrissage compte pour la mise à l’échelle, la sécurité, la gouvernance, la mise en réseau et l’identité, et repose sur les commentaires et des leçons tirées de nombreux clients.

En tant qu’éditeur de logiciels indépendant (ISV) qui crée et exploite sa solution sur Azure, vous devez vous reporter aux ressources suivantes lorsque vous générez votre environnement Azure :

• Zones d’atterrissage Azure : Fournit des conseils pour votre environnement Azure global.
• Azure Well-Architected Framework : Fournit des conseils architecturaux applicables à toutes les charges de travail.
• Architecture de solutions mutualisées sur Azure : Fournit des conseils architecturaux spécifiques pour les solutions mutualisées sur Azure.

Les zones d’atterrissage Azure vous aident à choisir une direction pour votre environnement Azure global. Toutefois, en tant qu’éditeur de logiciels indépendant, fournisseur SaaS ou start-up, vos besoins d’implémentation spécifiques peuvent différer des scénarios clients plus standard. Voici quelques exemples de scénarios d’implémentation différents :

• Vous créez des logiciels que les clients déploient dans leurs propres abonnements.
• Vous disposez de votre propre plan de contrôle et utilisez des scripts d’automatisation ou des logiciels pour déployer et configurer des ressources Azure pour vos solutions SaaS.
• Vous êtes un petit éditeur de logiciels indépendant ou une start-up et souhaitez commencer avec le coût le plus bas possible, et ne souhaiterez peut-être pas utiliser dès le départ des services comme le Pare-feu Azure et Azure DDoS Protection.
• Vous êtes un grand éditeur de logiciels indépendant SaaS et envisagez de fractionner votre application SaaS sur plusieurs abonnements à des fins de mise à l’échelle. Vous souhaitez également regrouper les abonnements afin qu’ils correspondent à vos environnements de développement, de test, de préproduction et de production.
• Le modèle d’exploitation de votre organisation sépare les rôles de votre équipe informatique d’entreprise et de votre équipe de produit SaaS. L’équipe informatique de votre organisation peut gérer des ressources comme Microsoft Office 365 et Microsoft Teams, et votre équipe de produit SaaS peut être responsable de la création et de l’exploitation de votre produit SaaS (y compris ses composants de plateforme centrale et d’identité).

Modèles de déploiement d’ISV

Les solutions ISV s’intègrent souvent à l’un de ces trois modèles de déploiement : SaaS pur, déployé par le client ou SaaS à double déploiement. Cette section décrit les différentes considérations de chaque modèle pour les zones d’atterrissage Azure.

SaaS pur

Dans le modèle SaaS pur, votre logiciel est entièrement déployé uniquement dans vos abonnements Azure. Les clients finaux consomment votre logiciel sans le déployer dans leurs propres abonnements Azure. Dans le diagramme suivant, les utilisateurs utilisent une application SaaS pure fournie par un éditeur de logiciels indépendant :

Parmi les exemples de logiciels SaaS purs, citons la messagerie en tant que service, Kafka en tant que service, l’entrepôt de données cloud en tant que service et de nombreuses offres SaaS de la Place de marché Azure.

Si vous êtes un petit éditeur de logiciels indépendant SaaS, vous n’avez peut-être pas besoin d’utiliser plusieurs abonnements Azure pour déployer vos ressources dans l’immédiat. Toutefois, à mesure que vous grandissez, les limites d’abonnement d’Azure pourraient affecter votre capacité à évoluer au sein d’un seul abonnement. Passez en revue les Principes de conception de la zone d’atterrissage à l’échelle de l’entreprise, en particulier la démocratisation des abonnements, et familiarisez-vous avec les Approches de la mutualisation afin de planifier votre croissance future.

Les éditeurs de logiciels indépendants qui créent des solutions SaaS pures doivent envisager les questions suivantes :

• Toutes les ressources Azure qui composent notre solution SaaS doivent-elles se trouver dans un abonnement Azure, ou être réparties sur plusieurs abonnements ?
• Devons-nous héberger chaque client dans son propre abonnement Azure dédié, ou pouvons-nous créer des ressources dans un ou plusieurs abonnements partagés ?
• Comment appliquer le modèle d’empreinte de déploiement (unité d’échelle) à tous les niveaux de notre solution ?
• Comment pouvons-nous utiliser l’organisation des ressources Azure dans des solutions mutualisées pour nous empêcher de rencontrer des difficultés de mise à l’échelle et les limites d’abonnement d’Azure ?

Déploiement par le client

Dans le modèle de déploiement par le client, vos clients finaux achètent des logiciels auprès de vous, puis les déploient dans leurs propres abonnements Azure. Ils peuvent lancer le déploiement à partir de la Place de marché Azure, ou le faire manuellement en suivant les instructions et en utilisant des scripts que vous fournissez.

Dans le diagramme suivant, un éditeur de logiciels indépendant fournit un package logiciel ou un produit du catalogue de la Place de marché Azure, et les utilisateurs déploient cette ressource dans leurs propres abonnements Azure en même temps que leurs autres charges de travail :

L’élément Autre charge de travail du client dans le diagramme peut représenter la propre charge de travail d’un client ou un autre produit ISV que le client a déployé dans son abonnement Azure. Les clients déploient fréquemment plusieurs produits provenant de différents éditeurs de logiciels indépendants dans leurs abonnements Azure. Ils combinent ces produits individuels pour créer des solutions. Par exemple, un client peut déployer un produit de base de données à partir d’un éditeur de logiciels indépendant, une appliance virtuelle réseau d’un autre éditeur et une application web d’un troisième éditeur.

Parmi les exemples de produits ISV déployés par le client, citons les nombreuses images de machine virtuelle (comme les appliances virtuelles réseau et de stockage) et les applications Azure de la Place de marché Azure.

Pour certaines solutions déployées par le client, une organisation peut fournir la gestion et les mises à jour de la solution déployée dans les abonnements Azure de leur clients finaux à l’aide d’Azure Lighthouse ou d’applications managées Azure. Les éditeurs de logiciels indépendants, les intégrateurs de solutions et les fournisseurs de services managés peuvent tous utiliser cette stratégie lorsqu’elle répond à leurs besoins particuliers.

Les solutions ISV déployées par le client sont considérées comme une charge de travail d’application standard du point de vue des zones d’atterrissage Azure. Prenez en compte les conseils pour les zones d’atterrissage Azure lorsque vous concevez votre produit pour travailler avec les principes de conception des zones d’atterrissage Azure que vos clients Azure adoptent.

Il est particulièrement important pour vous d’avoir une bonne compréhension des concepts de la zone d’atterrissage Azure lorsque vous migrez les charges de travail de vos clients existants vers Azure.

Les éditeurs de logiciels indépendants qui créent des solutions déployées par le client doivent envisager les questions suivantes :

• Un client doit-il déployer notre solution dans son propre abonnement dédié ou dans un abonnement existant qui contient des charges de travail associées ?
• Comment les clients doivent-ils établir une connectivité réseau entre les charges de travail existantes (à l’intérieur et à l’extérieur d’Azure) et notre solution ?
• Notre solution prend-elle en charge des mécanismes d’authentification de Microsoft Entra ID, ou nécessite-t-elle d’autres protocoles comme LDAP ou Kerberos ?
• Comment réduire ou éliminer les violations d’Azure Policy, comme celles provoquées par des conflits entre nos modèles de solution et les stratégies Azure d’un client ?

Les stratégies Azure des clients qui peuvent provoquer des violations Azure Policy incluent des exemples comme « Tous les sous-réseaux doivent avoir un groupe de sécurité réseau » et « Aucune adresse IP publique ne peut être attachée aux interfaces réseau dans la zone d’atterrissage de l’entreprise ». Gardez à l’esprit ces stratégies à l’origine de conflits potentielles à mesure que vous planifiez votre déploiement.

SaaS à double déploiement

Certaines solutions SaaS interagissent avec ou utilisent des ressources déployées dans les abonnements Azure des clients. Ce modèle de déploiement est parfois appelé SaaS à double déploiement ou hybride SaaS. Dans le diagramme suivant, un éditeur de logiciels indépendant fournit une solution SaaS hébergée qui interagit avec les ressources déployées dans l’abonnement Azure d’un client final :

Un exemple réel de SaaS à double déploiement est Microsoft Power BI, un service SaaS qui peut éventuellement utiliser une passerelle de données locale Power BI déployée sur une machine virtuelle dans l’abonnement Azure d’un client.

Voici d’autres exemples de scénarios de SaaS à double déploiement :

• Votre organisation crée Virtual Desktop Manager, un produit qui fournit une interface de console SaaS pour contrôler les ressources Azure Virtual Desktop dans l’abonnement Azure de chaque client.
• Votre organisation fournit une console SaaS pour l’analytique des données et crée et supprime dynamiquement des machines virtuelles de nœud de calcul dans l’abonnement Azure de chaque client.

En tant qu’éditeur de logiciels indépendant à double déploiement, vous devez vous reporter à la zone d’atterrissage Azure pour obtenir des conseils dans deux domaines : structurer votre propre environnement Azure pour héberger votre service SaaS et assurer une interaction correcte entre vos déploiements dans les abonnements Azure des clients et les zones d’atterrissage de vos clients.

Les éditeurs de logiciels indépendants qui créent des solutions SaaS à double déploiement doivent envisager les questions suivantes :

• Avons-nous examiné toutes les considérations relatives à la création de solutions SaaS pures et déployées par le client ?
• Quels composants de notre solution doivent être hébergés dans nos abonnements Azure et quels composants doivent être déployés par le client ?
• Comment garantir la sécurité de l’approvisionnement et des interactions avec les ressources déployées dans les abonnements Azure de nos clients ?

Principes et implémentations de la conception de zone d’atterrissage Azure

Les principes de conception de la zone d’atterrissage Azure recommandent de s’aligner sur les fonctionnalités de plateforme natives Azure, comme Log Analytics, Azure Monitor et Pare-feu Azure. Les instructions relatives à la zone d’atterrissage fournissent également des options d’implémentation de zone d’atterrissage Azure spécifiques.

En tant qu’éditeur de logiciels indépendant, vous pouvez décider d’implémenter vos propres environnements de zone d’atterrissage. Vous devrez peut-être utiliser votre propre automatisation pour déployer des ressources Azure sur plusieurs abonnements. Vous pouvez également continuer à utiliser des outils que vous utilisez déjà pour la journalisation, la surveillance et d’autres services de couche plateforme.

Si vous implémentez vos propres environnements de zone d’atterrissage, nous vous recommandons d’utiliser les conseils de zone d’atterrissage Azure et les exemples d’implémentation pour référence, et d’aligner votre approche avec des conceptions de zone d’atterrissage Azure éprouvées.

Locataires Microsoft Entra

Chaque zone d’atterrissage Azure et sa hiérarchie de groupes d’administration sont enracinées dans un seul locataire Microsoft Entra. Cela signifie que la première décision que vous devez prendre est de choisir le locataire Microsoft Entra à utiliser comme source d’identités pour la gestion de vos ressources Azure. Les identités dans Microsoft Entra ID sont des utilisateurs, des groupes et des principaux de service.

Les conseils pour les zones d’atterrissage Azure et les locataires Microsoft Entra recommandent vivement d’utiliser un seul locataire Microsoft Entra, et il s’agit de l’approche appropriée dans la plupart des situations. Toutefois, en tant qu’éditeur de logiciels indépendant SaaS, vous pouvez avoir de bonnes raisons d’utiliser deux locataires.

Pour certains éditeurs de logiciels indépendants SaaS, une équipe gère les ressources d’entreprise et une autre exploite la solution SaaS. Cette séparation peut être en place pour des raisons opérationnelles ou pour se conformer aux exigences réglementaires. Votre équipe informatique d’entreprise n’est peut-être pas autorisée à gérer les abonnements et ressources SaaS, ses membres ne peuvent donc pas être administrateurs du locataire Microsoft Entra. Si ce scénario s’applique à vous, utilisez deux locataires Microsoft Entra distincts : un pour les ressources informatiques d’entreprise comme Office 365, et un pour les ressources Azure qui composent votre solution SaaS.

Chaque locataire Microsoft Entra doit avoir son propre nom de domaine. Si votre organisation utilise deux locataires, vous pouvez choisir un nom comme contoso.com pour votre locataire Microsoft Entra d’entreprise et contoso-saas-ops.com pour votre locataire Microsoft Entra SaaS, comme illustré dans le diagramme suivant.

Évitez d’utiliser des locataires Microsoft Entra distincts pour les environnements de préproduction et de production. Au lieu de créer deux locataires comme contoso-saas-ops-preprod.com et contoso-saas-ops-prod.com avec des abonnements Azure distincts sous chacun d’eux, créez un seul locataire Microsoft Entra. Vous pouvez utiliser des groupes d’administration et Azure RBAC pour régir l’accès aux abonnements et aux ressources sous ce seul locataire.

Pour plus d'informations sur l'utilisation de plusieurs locataires Microsoft Entra, voir Zones d'atterrissage Azure et plusieurs locataires Microsoft Entra et Isolation des ressources avec plusieurs locataires.

Groupes d’administration

L’architecture conceptuelle de la zone d’atterrissage Azure recommande d’utiliser une hiérarchie de groupe d’administration spécifique. Toutefois, les éditeurs de logiciels indépendants peuvent avoir des exigences différentes des autres organisations. Cette section décrit certaines façons dont votre organisation ISV peut choisir d’adopter des pratiques différentes de celles recommandées par l’architecture conceptuelle de la zone d’atterrissage.

Groupe d’administration de niveau supérieur

Votre hiérarchie de groupe d’administration est imbriquée sous le groupe d’administration Groupe racine de locataire créé par Azure. Vous n’utilisez pas directement le Groupe racine de locataire.

Une organisation standard qui dispose d’une équipe informatique d’entreprise centralisée et gère sa plateforme et ses services partagés (comme la journalisation, la mise en réseau, l’identité et la sécurité) crée généralement un groupe d’administration de niveau supérieur sous le Groupe racine de locataire créé par Azure et déploie le reste de ses groupes d’administration en dessous. Ce groupe d’administration de niveau supérieur est généralement nommé après l’organisation elle-même (par exemple Contoso).

En tant qu’ISV SaaS, vous avez peut-être un produit SaaS ou quelques produits ou applications métier SaaS distincts. Même si vous devez généralement utiliser le même locataire Microsoft Entra pour gérer les ressources Azure de tous vos produits (comme indiqué dans la section Locataires Microsoft Entra), dans certains scénarios, vous pouvez choisir de déployer plusieurs hiérarchies de groupes d’administration.

Réfléchissez à la mesure dans laquelle vos produits sont indépendants les uns des autres, et demandez-vous :

• Nos produits utilisent-ils tous les mêmes plateformes pour DevOps, l’identité, la sécurité, la connectivité et la journalisation ?
• Ces services partagés sont-ils gérés par une seule équipe centrale ?

Si vous avez répondu Oui à ces deux questions, créez un seul groupe d’administration Produit SaaS de niveau supérieur sous le Groupe racine de locataire.

Si vous avez répondu Non et que chacun de vos produits SaaS est géré et exploité par des équipes de plateforme distinctes, envisagez de créer un groupe d’administration de niveau supérieur distinct pour chaque produit, comme les deux groupes d’administration de niveau supérieur SaaS Product-01 et SaaS Product-02.

Cette approche de gestion est similaire à l’approche de test pour les zones d’atterrissage à l’échelle de l’entreprise. Toutefois, au lieu de créer Contoso et Contoso-Canary sous le Groupe racine de locataire, dans cette approche, l’exemple d’entreprise crée les groupes d’administration de niveau supérieur Contoso-SaaS-Product-01, Contoso-SaaS-Product-02 et Contoso-SaaS-Product-03 de haut niveau sous celui-ci. Ce scénario est illustré dans le diagramme suivant :

Groupe d’administration de plateforme

Dans la hiérarchie de l’organisation des ressources de zone d’atterrissage Azure, le groupe d’administration Plateforme contient tous les abonnements Azure qui hébergent les composants et les services partagés utilisés par les charges de travail dans les abonnements de zone d’atterrissage. Les exemples de composants déployés dans les abonnements de plateforme et de services partagés incluent l’infrastructure de journalisation centralisée (comme les espaces de travail Log Analytics), DevOps, la sécurité, les outils d’automatisation, les ressources réseau centralisées (comme les plans Réseau virtuel hub et Protection DDos) et les services de plan de contrôle d’un éditeur de logiciels indépendant.

Le groupe d’administration Plateforme est fréquemment partitionné dans les groupes enfants Identité, Administration et Connectivité pour fournir une séparation pratique des rôles et des stratégies pour les clients d’entreprise.

Dans votre organisation, vous pouvez avoir une seule équipe qui gère tous les composants de plateforme partagés, comme l’identité, la mise en réseau et la gestion. Si c’est le cas, et si vous ne prévoyez pas de séparer cette gestion entre plusieurs équipes, envisagez d’utiliser un groupe d’administration Plateforme unique.

Si vous avez plutôt des équipes distinctes qui gèrent différentes parties de votre plateforme centralisée, vous devez déployer des niveaux supplémentaires dans la hiérarchie des groupes d’administration sous le groupe d’administration Plateforme. Cela vous permet d’attribuer des stratégies distinctes pour chaque partie de votre plateforme centralisée.

Le diagramme suivant illustre deux implémentations potentielles du groupe d’administration Plateforme. L’option A présente un scénario plus complet, où le groupe d’administration Plateforme contient trois groupes d’administration enfants : Gestion et DevOps, Identité et sécurité et Connectivité. Chaque groupe d’administration enfant contient un abonnement avec les ressources pertinentes. L’option B montre un scénario plus simple, où le groupe d’administration Plateforme contient un abonnement de plateforme unique.

Groupe d’administration des zones d’atterrissage

Le groupe d’administration Zones d’atterrissage contient les abonnements Azure qui hébergent les sous-systèmes et charges de travail réels de votre solution SaaS.

Ce groupe d’administration contient un ou plusieurs groupes d’administration enfants. Chacun des groupes d’administration enfants sous Zones d’atterrissage représente une charge de travail ou un Archétype de sous-système, avec des exigences cohérentes de stratégie et d’accès qui doivent s’appliquer à tous les abonnements. Les raisons de l’utilisation de plusieurs archétypes sont les suivantes :

• Conformité : Si un sous-système de votre produit SaaS doit être conforme à PCI-DSS, envisagez de créer un groupe d’administration enfant d’archétype PCI DSS sous Zones d’atterrissage. Tous les abonnements Azure qui contiennent des ressources dans l’étendue de la conformité PCI-DSS doivent être placés dans ce groupe d’administration.
• Niveaux : Envisagez de créer des archétypes de zone d’atterrissage distincts pour les clients de niveau Dédié de votre solution SaaS et les clients de niveau Gratuit . Chacun des groupes d’administration enfants contient des paramètres Azure Policy différents. Par exemple, les stratégies du niveau gratuit peuvent restreindre les déploiements pour activer uniquement des références SKU de machine virtuelle spécifiques, et les stratégies du niveau dédié peuvent nécessiter le déploiement de ressources dans des régions spécifiques.

Groupes d’administration spécifiques à l’environnement

Les éditeurs de logiciels indépendants SaaS organisent souvent leurs environnements cloud en modélisant leurs environnements de cycle de vie de développement logiciel dans une séquence. Cela nécessite généralement le déploiement préalable dans un environnement de Développement, puis dans un environnement de Test, dans un environnement Intermédiaire, et enfin dans un environnement de Production.

Une différence courante entre les environnements est leur ensemble de règles RBAC Azure, comme qui peut accéder à chaque groupe d’abonnements. Par exemple, les équipes DevOps, SaaSOps, de développement et de test peuvent toutes avoir différents niveaux d’accès à différents environnements.

Les éditeurs de logiciels indépendants SaaS doivent parfois regrouper plusieurs abonnements qui représentent des étendues ou partitions du même sous-système, de la même application ou de la même charge de travail. Vous devrez peut-être appliquer des stratégies ou des attributions de rôles à des groupes d’abonnements de manière sensiblement différente du groupe d’administration archétype. Dans ce cas, envisagez de créer des groupes d’administration enfants qui correspondent à chaque environnement sous le groupe d’administration archétype.

Les diagrammes suivants illustrent deux options potentielles. L’option A présente un scénario avec des abonnements distincts pour chaque environnement, mais aucun groupe d’administration spécifique à l’environnement. L’option B présente un scénario ISV SaaS avec des groupes d’administration spécifiques à l’environnement sous le groupe d’administration Empreinte régulière. Chaque groupe d’administration spécifique à l’environnement contient plusieurs abonnements. Au fil du temps, l’éditeur de logiciels indépendant met à l’échelle ses ressources Azure dans chaque environnement sur un nombre croissant d’abonnements avec un ensemble commun de stratégies et d’attributions de rôles.

Sélectionnez chaque onglet pour voir les deux diagrammes.

Groupes d’administration Désaffectés et Bacs à sable

Les conseils d’organisation des ressources pour les zones d’atterrissage Azure recommandent d’inclure des groupes d’administration Désaffectés et des Bacs à sable directement sous votre groupe d’administration de niveau supérieur.

Le groupe d’administration Désaffectés est un lieu d’attente pour les abonnements Azure qui sont désactivés et finiront par être supprimés. Vous pouvez déplacer un abonnement qui n’est plus utilisé dans ce groupe d’administration pour le suivre jusqu’à ce que toutes les ressources de l’abonnement soient supprimées définitivement.

Le groupe d’administration Bacs à sable contient généralement des abonnements Azure utilisés à des fins d’exploration et qui ont des stratégies souples, ou qui n’ont aucune stratégie. Par exemple, vous pouvez fournir aux développeurs individuels leurs propres abonnements pour le développement et le test. Vous pouvez éviter d’appliquer les stratégies normales et la gouvernance à ces abonnements en les plaçant dans le groupe d’administration Bacs à sable. Cela augmente l’agilité des développeurs et leur permet d’expérimenter facilement Azure.

Le diagramme suivant illustre deux options potentielles. L’option A n’inclut pas les groupes d’administration Désaffectés et Bacs à sable, tandis que l’option B le fait.

Exemple de zones d’atterrissage d’ISV

Cette section inclut deux exemples de structures de zone d’atterrissage Azure pour un ISV SaaS. Sélectionnez chaque onglet pour comparer les deux exemples de zones d’atterrissage.

Étapes suivantes

• Si vous créez une solution mutualisée, apprenez-en davantage sur l’Architecture de solutions multilocataires sur Azure.
• Découvrez ce qu’est une zone d’atterrissage Azure.
• Découvrez les Zones de conception des zones d’atterrissage Azure.