Il existe de nombreuses façons de concevoir et créer des solutions mutualisées dans Azure. D’un côté, vous pouvez partager chaque ressource de votre solution parmi tous vos locataires. D’un autre côté, vous pouvez déployer des ressources isolées pour chaque locataire. Il peut sembler simple de déployer des ressources distinctes pour chaque locataire et cela peut fonctionner pour un petit nombre de locataires. Toutefois, cela n’est généralement pas optimisé financièrement et risque de compliquer la gestion de vos ressources. Il existe également différentes approches entre ces extrêmes, qui impliquent toutes des compromis entre mise à l’échelle, isolation, rentabilité, performances, complexité d’implémentation et facilité de gestion.
Cette section couvre les principales catégories de services Azure qui constituent une solution, à savoir le calcul, le stockage et les données, les réseaux, le déploiement, l’identité, lamessagerie, l’intelligence artificielle et l’apprentissage automatique, et l’IoT. Pour chaque catégorie, elle décrit les modèles et approches clés que vous pouvez envisager lorsque vous concevez une solution mutualisée, ainsi que des anti-modèles à éviter.
Modèle d’empreintes de déploiement
Le modèle Empreintes de déploiement est fréquemment utilisé dans des solutions mutualisées. Il implique le déploiement d’une infrastructure dédiée pour un locataire ou un groupe de locataires. Une même empreinte peut servir plusieurs locataires ou être dédiée à un seul locataire.
Lorsque vous utilisez des empreintes à un seul locataire, le modèle Empreintes de déploiement est généralement facile à implémenter, car chaque empreinte est susceptible d'ignorer l'existence des autres. Par conséquent, aucune logique ou fonctionnalité multi-locataire ne doit être intégrée dans la couche Application. Lorsque chaque locataire dispose de sa propre empreinte dédiée, ce modèle offre le degré d'isolation le plus élevé et atténue le problème des voisins bruyants. Il permet également de configurer ou de personnaliser les locataires en fonction de leurs propres besoins, par exemple pour qu'ils soient situés dans une région géopolitique spécifique ou qu'ils aient des exigences particulières en matière de haute disponibilité.
Lorsque vous utilisez des empreintes multi-locataires, d'autres modèles doivent être pris en compte pour gérer l'architecture multi-locataire au sein de l'empreinte, et le problème des voisins bruyants peut toujours se poser. Toutefois, le modèle Empreintes de déploiement vous permet de poursuivre la mise à l’échelle à mesure que votre solution croît.
Le plus gros problème posé par le modèle Empreintes de déploiement, lorsqu'il est utilisé pour servir un seul locataire, est souvent le coût de l'infrastructure. Chaque tampon doit avoir son propre ensemble distinct d’infrastructure et l’infrastructure n’est pas partagée avec d’autres locataires. Vous devez également vous assurer que les ressources déployées pour une empreinte sont suffisantes pour répondre à la charge de travail maximale de ce locataire. Assurez-vous que votre modèle de tarification compense le coût du déploiement de l'infrastructure du locataire.
Les empreintes à un seul locataire sont idéales lorsque vous n'avez qu'un petit nombre de locataires. Mais à mesure que le nombre de locataires augmente, il devient difficile de gérer la flotte d'empreintes pour un locataire unique, même si cela reste possible (à titre d'exemple, consultez cette étude de cas). Vous pouvez également appliquer le modèle Empreintes de déploiement pour créer des empreintes multi-locataires, ce qui peut présenter des avantages en termes de partage des ressources et des coûts.
Pour implémenter le modèle Empreintes de déploiement, il est important d'utiliser des approches de déploiement automatisé. En fonction de votre stratégie de déploiement, vous pouvez envisager de gérer vos empreintes au sein de vos pipelines de déploiement, en utilisant une infrastructure déclarative en tant que code, comme des fichiers Bicep ou les modèles Terraform. Vous pouvez également envisager de créer un code personnalisé pour déployer et gérer chaque empreinte, par exemple en utilisant des kits de développement logiciel (SDK) Azure.
Public concerné
Les articles de cette section doivent s’avérer utiles aux architectes de solutions et aux principaux développeurs d’applications multilocataires, notamment les éditeurs de logiciels indépendants (ISV) et les start-ups qui développent des solutions SaaS. La plupart des conseils fournis dans cette section sont génériques et s’appliquent à plusieurs services Azure au sein d’une catégorie.
Étapes suivantes
Nous vous recommandons de passer en revue les approches de l’organisation des ressources dans une solution multi-locataire avant de passer en revue les conseils relatifs à des catégories spécifiques de services Azure.