Approches architecturales pour les plans de contrôle dans les solutions multilocataires
Les plans de contrôle constituent une partie importante du logiciel en tant que service (SaaS) et des solutions multilocataires, en particulier pour aider à gérer une solution à grande échelle. En règle générale, il existe deux composants principaux qui composent un plan de contrôle :
- Le catalogue de locataires, qui stocke des informations importantes sur vos locataires, telles que :
- Configuration du tenant.
- Références SKU déployées pour les ressources de locataire.
- Auxquels empreintes de déploiement les locataires sont alloués.
- Processus de gestion des modifications apportées à l’environnement, qui sont déclenchées par les événements de cycle de vie du locataire. Par exemple, l’intégration du locataire, le débarquement du locataire et toute maintenance régulière requise.
Un plan de contrôle est lui-même une application. Vous devez réfléchir soigneusement à votre plan de contrôle et le concevoir avec la même rigueur et soin que vous utilisez avec n’importe quelle autre partie de votre solution. Pour plus d’informations sur ce qu’est un plan de contrôle, pourquoi vous devez l’utiliser et les considérations relatives à sa conception, consultez Considérations relatives aux plans de contrôle multilocataires.
Cet article décrit certaines approches que vous pouvez envisager pour concevoir et créer un plan de contrôle. La liste des approches décrites ici n’est pas complète. Bien que les approches soient toutes valides, il existe d’autres architectures valides.
Approches et modèles à prendre en compte
Le tableau suivant résume les différences entre certaines des approches que vous pouvez envisager pour un plan de contrôle. Les approches manuelles, à faible code et personnalisées sont comparées.
Considération | Manuel | Faible quantité de code | Personnalisée |
---|---|---|---|
Surcharge opérationnelle | Élevée | Faible-Moyenne. | Faible |
Fréquence des événements de cycle de vie pour laquelle l’approche convient | Rare | Occasionnellement-souvent | Souvent |
Temps et complexité à implémenter | Faible | Moyenne | Élevé |
Responsabilités de maintenance du plan de contrôle | Faible | Moyenne | Élevé |
Testabilité | Faible | Moyenne | Élevé |
Risque d’incohérences | Élevée | Moyenne-basse | Faible |
Processus manuels
Il n’est pas toujours essentiel de créer un plan de contrôle entièrement automatisé, en particulier lorsque vous démarrez et n’avez qu’un petit nombre de locataires.
Vous pouvez conserver votre catalogue de locataires dans un emplacement centralisé, comme dans un classeur Excel ou un fichier JSON stocké dans un emplacement auquel votre équipe peut accéder. Quel que soit le format, il est judicieux de stocker les informations de manière structurée afin que vous puissiez facilement utiliser les données par programmation.
Remarque
Un plan de contrôle manuel est un excellent moyen de commencer à gérer votre application multilocataire, mais il convient uniquement à un petit nombre de locataires (moins de 5 à 10). La surcharge administrative et le risque d’incohérences augmentent avec chaque locataire que vous intégrez manuellement. Vous ne devez utiliser cette approche que si vous n’avez que quelques locataires et que vous n’avez pas besoin d’intégration automatisée ou en libre-service.
Pour les processus tels que l’intégration des locataires et les activités de maintenance :
- Créez des scripts ou des pipelines automatisés dans la mesure du possible, même si vous les exécutez manuellement. En utilisant des scripts ou des pipelines, vous vérifiez que les étapes s’exécutent de manière cohérente pour chaque locataire.
- Pour les tâches que vous ne pouvez pas écrire initialement, documentez le processus de manière approfondie et explicite. Documentez la manière et les raisons. Si quelqu’un finit par automatiser la tâche à l’avenir, il devrait avoir une bonne compréhension des deux.
Le diagramme suivant illustre une façon d’utiliser des processus manuels pour un plan de contrôle initial :
Téléchargez un fichier Visio de cette architecture.
Avantages d’une approche manuelle
- Léger : la documentation, les scripts et les pipelines sont faciles à développer et à modifier. Cela les rend appropriés lorsque vous découvrez vos processus, car vous pouvez rapidement les itérer et les faire évoluer.
- Faible coût : la maintenance et l’exécution d’une approche manuelle sont peu coûteuses.
- Valide votre processus : même si vous envisagez d’utiliser une approche plus automatisée, commencer par une approche manuelle comme preuve de concept est un bon moyen de valider votre stratégie de maintenance avant d’investir du temps dans le développement d’une automatisation plus robuste.
Inconvénients d’une approche manuelle
- Manque de contrôle : cette approche suppose que tous les intervenants font du bon travail. Quelqu’un peut s’écarter des processus prescrits, accidentellement ou intentionnellement. Chaque variation du processus augmente le risque d’incohérence dans votre environnement, ce qui rend la gestion continue beaucoup plus difficile.
- Défis liés au contrôle d’accès : lorsque vous utilisez cette approche, vous devez généralement accorder un accès étendu et hautement permissif à toute personne qui exploite votre solution, ce qui rend difficile de suivre les meilleures pratiques en matière de segmentation des accès.
- Scalabilité : le travail nécessaire pour exécuter des processus manuels augmente avec le nombre de locataires que vous devez gérer.
- Testabilité : les processus manuels sont difficiles à valider et à tester.
Quand envisager de s’éloigner d’une approche manuelle
- Lorsque votre équipe ne peut pas suivre la quantité de travail nécessaire pour gérer l’application. Par exemple, lorsque votre nombre de locataires augmente au-delà d’un point critique, qui pour la plupart des équipes est compris entre 5 et 10 locataires.
- Lorsque vous prévoyez une croissance des locataires au-delà d’un nombre critique de locataires et que vous devez préparer le travail impliqué dans l’administration de ce nombre de locataires.
- Lorsque vous devez atténuer le risque d’incohérences. Par exemple, vous pouvez observer certaines erreurs qui se produisent parce que quelqu’un ne suit pas correctement les processus, ou parce qu’il y a trop d’ambiguïté dans les processus. Le risque d’incohérence augmente généralement à mesure que de nouveaux locataires sont intégrés manuellement et que votre équipe grandit.
Plan de contrôle à code faible
Un plan de contrôle low-code ou no-code est construit sur une plateforme conçue pour automatiser les processus métier et suivre les informations. Il existe de nombreuses plateformes qui permettent de réaliser ces tâches sans écrire de code personnalisé.
Microsoft Power Platform est un exemple de l’une de ces plateformes. Si vous utilisez Power Platform, vous pouvez conserver votre catalogue de locataires dans Dynamics 365, Dataverse ou Microsoft 365. Vous pouvez également envisager de conserver le même catalogue de locataires que vous utilisez pour vos processus manuels, si vous ne souhaitez pas vous engager pleinement dans l’automatisation dès le départ.
Pour l’intégration et la maintenance des locataires, vous pouvez utiliser Power Automate pour exécuter des flux de travail qui gèrent les locataires, configurent les locataires, déclenchent des pipelines ou des appels API, etc. Vous pouvez utiliser Power Automate pour surveiller les modifications apportées à votre catalogue de locataires, si les données sont accessibles à Power Automate. Si vous utilisez un catalogue de locataires manuel, les flux de travail Power Automate peuvent également être déclenchés manuellement. Vous pouvez décider d’inclure des étapes d’approbation manuelle dans vos flux de travail si vous avez besoin d’une personne de votre équipe pour vérifier quelque chose ou effectuer des étapes supplémentaires qui ne peuvent pas être entièrement automatisées.
Cette approche permet également de fournir une inscription en libre-service à vos clients en permettant à votre application web d’ajouter directement des enregistrements à votre catalogue de locataires sans intervention humaine.
Le diagramme suivant illustre la façon dont vous pouvez créer un plan de contrôle avec l’inscription en libre-service à l’aide de Microsoft Power Platform :
Téléchargez un fichier Visio de cette architecture.
Avantages d’une approche à faible code
- Lightweight : Il est souvent rapide et peu coûteux de créer un ensemble de flux de travail low-code et de les connecter aux systèmes environnants.
- Utilise les outils de plateforme : vous pouvez utiliser des fonctionnalités de plateforme natives pour stocker des données, créer des portails d’administration pour que votre équipe l’utilise et surveiller les flux de travail à mesure qu’ils s’exécutent. En utilisant les fonctionnalités natives de la plateforme, vous évitez de construire beaucoup de composants vous-même.
- Personnalisable : si vous avez besoin d’une personnalisation supplémentaire, vous pouvez généralement augmenter vos flux de travail avec du code et des processus personnalisés. Par exemple, vous pouvez utiliser Power Automate pour déclencher un flux de travail de déploiement dans GitHub Actions, ou vous pouvez appeler Azure Functions pour exécuter votre propre code. Cela aide également à faciliter une mise en œuvre progressive.
- Faible surcharge : les services à faible code sont généralement entièrement gérés. Vous n’avez donc pas besoin de gérer l’infrastructure.
Inconvénients d’une approche à faible code
- Expertise requise : pour utiliser des plateformes à faible code pour créer des processus et utiliser efficacement ces plateformes, vous avez généralement besoin de connaissances propriétaires. De nombreuses organisations utilisent déjà ces outils, de sorte que votre équipe a peut-être déjà l’expertise requise, mais peut-être pas. Vous devez déterminer si vous devez former votre équipe afin d’utiliser efficacement ces plateformes.
- Gestion : il peut être difficile de gérer la gestion de grandes quantités de configuration à faible code.
- Testabilité : réfléchissez à la manière de tester et de promouvoir les modifications apportées à votre plan de contrôle. Dans une plateforme managée, la création d’un processus DevOps classique pour le test et la promotion des modifications est plus difficile, car les modifications sont normalement apportées par le biais de la configuration, et non par le biais du code.
- Conception : réfléchissez soigneusement à la façon de répondre aux exigences non fonctionnelles telles que la sécurité et la fiabilité. Ces exigences sont souvent gérées pour vous sur une plateforme à faible code.
Quand envisager de s’éloigner d’une approche à faible code
- Par la suite, vos exigences peuvent devenir si complexes que vous ne pouvez pas les incorporer sensiblement dans une solution à faible code. Lorsque vous devez contourner les limitations des outils pour répondre à vos besoins, il est probablement judicieux de s’éloigner d’une solution managée et de s’orienter vers un plan de contrôle personnalisé.
Plan de contrôle personnalisé
Vous pouvez également envisager de créer votre propre plan de contrôle entièrement personnalisé. Cette option offre la plus grande flexibilité et puissance, mais elle nécessite également le plus de travail. Le catalogue de locataires est généralement stocké dans une base de données. Dans ce cas, vous ne travaillez pas directement avec le catalogue, mais vous le gérez via une interface administrative, qui peut être une application personnalisée ou un système comme l’application CRM (Customer Relationship Management) de votre organisation.
Vous créez généralement un ensemble de composants de plan de contrôle conçus autour de toutes les fonctions d’administration de votre locataire. Ces composants peuvent inclure un portail d’administration ou une autre interface utilisateur, une API et des composants de traitement en arrière-plan. Si vous devez effectuer des opérations telles que déployer du code ou une infrastructure lorsque des événements de cycle de vie de locataire se produisent, les pipelines de déploiement peuvent également constituer votre plan de contrôle.
Vérifiez que tout traitement de longue durée utilise les outils appropriés. Par exemple, vous pouvez utiliser Durable Functions ou Azure Logic Apps pour les composants qui orchestrent l’intégration ou les déploiements de locataires, ou pour les composants qui doivent communiquer avec des systèmes externes.
Comme l’approche à faible code, cette approche vous permet de fournir une inscription en libre-service à vos clients en permettant à votre application web d’ajouter directement des enregistrements à votre catalogue de locataires sans intervention humaine.
Le diagramme suivant montre une façon de créer un plan de contrôle personnalisé de base qui fournit l’inscription en libre-service :
Téléchargez un fichier Visio de cette architecture.
Avantages d’une approche personnalisée
- Flexibilité et personnalisation complètes : vous avez un contrôle total sur ce que fait votre plan de contrôle et pouvez le modifier si vos besoins changent.
- Testabilité : vous pouvez utiliser un cycle de vie de développement logiciel standard (SDLC) pour votre application de plan de contrôle et implémenter des approches normales pour les tests et les déploiements, comme vous le feriez pour vos applications principales.
Inconvénients d’une approche personnalisée
- Responsabilités de maintenance : cette approche nécessite une surcharge de maintenance plus importante, car vous devez tout créer vous-même. Un plan de contrôle est aussi important que toute autre partie de votre application. Vous devez faire très attention à développer, tester et exploiter votre plan de contrôle pour vous assurer qu’il est fiable et sécurisé.
Approches hybrides
Vous pouvez également envisager d’utiliser une approche hybride. Vous pouvez utiliser une combinaison de systèmes manuels et automatisés, ou vous pouvez utiliser une plateforme managée comme Microsoft Power Platform et l’augmenter avec des applications personnalisées. Envisagez de mettre en œuvre une approche hybride si vous avez besoin de la personnalisation d’un plan de contrôle personnalisé mais que vous ne souhaitez pas nécessairement construire et maintenir un système entièrement personnalisé. N’oubliez pas que, à un moment donné, vos personnalisations automatisées sur vos processus manuels ou votre plateforme managée peuvent devenir aussi complexes qu’un système entièrement personnalisé. Le point de basculement est différent pour chaque organisation, mais si votre approche hybride est lourde à maintenir, vous devriez envisager de passer à un système entièrement personnalisé.
Implémentation progressive
Même si vous savez que vous souhaitez automatiser votre plan de contrôle, vous n’avez pas nécessairement besoin de commencer par cette approche. Une approche courante lors des premières phases de création de votre application consiste à commencer par un plan de contrôle manuel. À mesure que votre application progresse et intègre davantage de locataires, vous devez commencer à identifier les zones de goulot d’étranglement et à les automatiser si nécessaire, en passant à une approche hybride. À mesure que vous automatisez davantage, vous pouvez éventuellement avoir un plan de contrôle entièrement automatisé.
Antimodèles à éviter
- S’appuyer sur des processus manuels depuis trop longtemps. Bien qu’il soit raisonnable d’utiliser des processus manuels lorsque vous démarrez ou lorsque vous avez un faible nombre de locataires et que vous avez besoin d’une gestion assez légère, vous devez planifier la mise à l’échelle vers une solution automatisée à mesure que vous grandissez. Si vous devez embaucher des membres supplémentaires pour répondre à la demande de vos processus manuels, c’est un bon signe que vous devriez commencer à automatiser certaines parties de votre plan de contrôle.
- Utilisation d’outils inappropriés pour les flux de travail de longue durée. Par exemple, évitez d’utiliser des fonctions Azure standard, des appels d’API synchrones ou d’autres outils qui ont une limite de temps d’exécution pour effectuer des opérations de longue durée comme les déploiements Azure Resource Manager ou les orchestrations à plusieurs étapes. Utilisez plutôt des outils comme Azure Logic Apps, Durable Functions, et d’autres outils pouvant exécuter des flux de travail ou des séquences d’opérations de longue durée. Pour plus d’informations, consultez Fiabilité et performances d’Azure Functions et Modèle de réponse aux demandes asynchrones.
Contributeurs
Cet article est géré par Microsoft. Il a été écrit à l’origine par les contributeurs suivants.
Principaux auteurs :
- John Downs | Ingénieur logiciel principal
- Landon Pierce | Customer Engineer
Autres contributeurs :
- Mick Alberts | Rédacteur technique
- Bohdan Cherchyk | Ingénieur client senior
- Arsen Vladimirskiy | Principal Customer Engineer