Er zijn veel verschillende manieren waarop u multitenant-oplossingen in Azure kunt ontwerpen en bouwen. U kunt elke resource in uw oplossing tot het uiterste delen tussen al uw tenants. In het andere uiterste kunt u geïsoleerde resources implementeren voor elke tenant. Het lijkt misschien eenvoudig om afzonderlijke resources voor elke tenant te implementeren en het kan werken voor een klein aantal tenants. Het biedt echter doorgaans geen kostenefficiëntie en het kan lastig worden om uw resources te beheren. Er zijn ook verschillende benaderingen die tussen deze extremen passen en ze vereisen allemaal compromissen tussen schaal, isolatie, kostenefficiëntie, prestaties, implementatiecomplexiteit en beheerbaarheid.
In deze sectie bespreken we de belangrijkste categorieën Azure-services die bestaan uit een oplossing, waaronder rekenkracht, opslag en gegevens, netwerken, implementatie, identiteit, berichten, kunstmatige intelligentie en machine learning en IoT. Voor elke categorie geven we een overzicht van de belangrijkste patronen en benaderingen die u kunt overwegen wanneer u een multitenant-oplossing ontwerpt en sommige antipatronen om te voorkomen.
Patroon Implementatiestempels
Het patroon Implementatiestempels wordt vaak gebruikt in multitenant-oplossingen. Het omvat het implementeren van een toegewezen infrastructuur voor een tenant of voor een groep tenants. Eén stempel kan meerdere tenants dienen of kunnen worden toegewezen aan één tenant.
Wanneer u stempels met één tenant gebruikt, is het patroon Implementatiestempels meestal eenvoudig te implementeren, omdat elke zegel waarschijnlijk geen andere is, dus er hoeven geen multitenancylogica of mogelijkheden te worden ingebouwd in de toepassingslaag. Wanneer elke tenant een eigen toegewezen stempel heeft, biedt dit patroon de hoogste mate van isolatie en vermindert dit het probleem met Noisy Neighbor. Het biedt ook de mogelijkheid voor tenants die moeten worden geconfigureerd of aangepast aan hun eigen vereisten, zoals in een specifieke geopolitieke regio of om specifieke vereisten voor hoge beschikbaarheid te hebben.
Wanneer u multitenant-stempels gebruikt, moeten andere patronen worden overwogen om multitenancy binnen de stempel te beheren en kan het probleem met noisy neighbor nog steeds van toepassing zijn. Met behulp van het patroon Implementatiestempels kunt u echter blijven schalen naarmate uw oplossing groeit.
Het grootste probleem met het patroon Implementatiestempels, wanneer deze wordt gebruikt om één tenant te bedienen, is meestal de kosten van de infrastructuur. Elke zegel moet een eigen afzonderlijke set infrastructuur hebben en de infrastructuur wordt niet gedeeld met andere tenants. U moet er ook voor zorgen dat de resources die zijn geïmplementeerd voor een stempel voldoende zijn om te voldoen aan de piekbelasting voor de workload van die tenant. Zorg ervoor dat uw prijsmodel de implementatiekosten voor de infrastructuur van de tenant verschoven.
Stempels met één tenant werken vaak goed wanneer u een klein aantal tenants hebt. Naarmate uw aantal tenants groeit, is het mogelijk, maar steeds moeilijker om een vloot met stempels met één tenant te beheren (zie deze casestudy als voorbeeld). U kunt ook het patroon Implementatiestempels toepassen om multitenant-stempels te maken, wat voordelen kan bieden voor het delen van resources en kosten.
Als u het patroon Implementatiestempels wilt implementeren, is het belangrijk om geautomatiseerde implementatiemethoden te gebruiken. Afhankelijk van uw implementatiestrategie kunt u overwegen om uw stempels binnen uw implementatiepijplijnen te beheren met behulp van declaratieve infrastructuur als code, zoals Bicep-bestanden of Terraform-sjablonen. U kunt ook aangepaste code bouwen om elke zegel te implementeren en te beheren, zoals met behulp van Azure SDK's.
Doelgroep
De artikelen in deze sectie zijn bedoeld om nuttig te zijn voor oplossingsarchitecten en leadontwikkelaars van multitenant-toepassingen, waaronder onafhankelijke softwareleveranciers (ISV's) en startups die SaaS-oplossingen ontwikkelen. Veel van de richtlijnen in deze sectie zijn algemeen en van toepassing op meerdere Azure-services binnen een categorie.
Volgende stappen
We raden u aan de benaderingen voor resourceorganisatie in een multitenant-oplossing te bekijken voordat u de richtlijnen over specifieke categorieën Azure-services bekijkt.