Approches architecturales pour une solution mutualisée

Vous pouvez concevoir et créer des solutions mutualisées dans Azure de plusieurs façons. 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 peut fonctionner pour quelques locataires. Toutefois, il manque généralement d’efficacité des coûts et rend la gestion des ressources difficile. Plusieurs approches se situent entre ces extrêmes. Chaque approche nécessite des compromis entre l’échelle, l’isolation, l’efficacité des coûts, les performances, la complexité de l’implémentation et la facilité de gestion.

Cette section décrit les approches des principales catégories de services Azure qui comprennent une solution, notamment le calcul, le stockage et les données, la mise en réseau, le déploiement, l’identité, la messagerie, l’IA et le Machine Learning et l’Internet des objets (IoT). Pour chaque catégorie, il inclut des antimodèles pour éviter et des modèles clés et des approches à prendre en compte lorsque vous concevez une solution multilocataire.

Modèle d’empreintes de déploiement

Les solutions mutualisées utilisent souvent le modèle « Deployment Stamps ». Ce modèle déploie une infrastructure dédiée pour un locataire ou un groupe de locataires. Un tampon unique peut servir plusieurs locataires ou un seul locataire.

Le diagramme comporte trois locataires, les locataires A, B et C. Les locataires A et B pointent vers l'instance de déploiement 1, qui contient un serveur web et une base de données pour les deux locataires. Le locataire C pointe vers la marque de déploiement 2, qui contient un serveur web dédié et une base de données dédiée.

Les tampons à locataire unique facilitent l’implémentation du modèle Tampons de déploiement. Chaque tampon fonctionne indépendamment et ne nécessite pas de logique ou de fonctionnalités multilocataires dans la couche d'application. Ce modèle fournit le niveau d’isolation le plus élevé et permet d’éviter le problème de voisin bruyant. Il fournit également une configuration ou une personnalisation pour les locataires en fonction des exigences spécifiques, telles qu’une région géopolitique cible ou des besoins de haute disponibilité.

Les tampons multilocataires nécessitent des modèles supplémentaires pour gérer l’architecture multilocataire au sein du tampon, et le problème de voisin bruyant peut toujours se produire. Toutefois, le modèle Tampons de déploiement prend en charge la mise à l’échelle continue à mesure que votre solution augmente.

L’inconvénient principal de l’utilisation du modèle Tampons de déploiement pour un seul locataire est le coût de l’infrastructure. Chaque tampon nécessite sa propre infrastructure dédiée, qui ne peut pas être partagée avec d’autres locataires. Vous devez également provisionner des ressources pour gérer la charge de travail maximale du locataire. Assurez-vous que votre modèle de tarification a pour effet de compenser le coût du déploiement de l’infrastructure du locataire.

Les systèmes à un locataire fonctionnent souvent bien avec quelques locataires. À mesure que votre nombre de locataires augmente, la gestion d’une flotte de timbres à locataire unique devient plus difficile. Pour obtenir un exemple d’étude de cas, consultez Exécuter un million de bases de données sur Azure SQL pour un fournisseur volumineux. Vous pouvez également appliquer le modèle Tampons de déploiement pour créer des tampons à plusieurs locataires. Cette approche prend en charge le partage de ressources et réduit les coûts d’infrastructure.

Pour implémenter le modèle Tampons de déploiement, utilisez des approches de déploiement automatisées. Selon votre stratégie de déploiement, vous pouvez gérer vos tampons au sein de vos pipelines de déploiement à l’aide d’une infrastructure déclarative en tant que code, comme des fichiers Bicep ou des modèles Terraform. Vous pouvez également créer du code personnalisé pour déployer et gérer chaque tampon à l’aide de Kits de développement logiciel (SDK) Azure ou d’un autre outil.

Public prévu

Les articles de cette section visent à aider les architectes de solutions et les développeurs d’applications mutualisées, y compris les fournisseurs indépendants de logiciels et les startups qui développent des solutions SaaS (Software en tant que Service). La plupart des conseils de cette section s’appliquent largement à plusieurs services Azure dans une catégorie.

Ressource associée

• Avant de passer en revue les instructions Azure spécifiques au service, passez en revue les approches de l’organisation des ressources dans une solution mutualisée.