Architectuurbenaderingen voor een multitenant-oplossing

Azure

Er zijn veel verschillende manieren waarop u multitenant-oplossingen in Azure kunt ontwerpen en bouwen. Aan het ene uiteinde kunt u elke resource in uw oplossing delen met al uw tenants. Aan de andere kant 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 meestal echter geen kosteneffectiviteit en het kan lastig worden om uw resources te beheren. Er zijn ook verschillende benaderingen die tussen deze uitersten passen en ze hebben allemaal compromissen zoals schaal, isolatie, kostenefficiëntie, prestaties, implementatiecomplexiteit en beheerbaarheid.

In deze sectie bespreken we de belangrijkste categorieën Van Azure-services waaruit een oplossing bestaat, zoals compute, opslag en gegevens, netwerken, implementatie, identiteit, berichten, kunstmatige intelligentie en machine learning en IoT. Voor elke categorie beschrijven we de belangrijkste patronen en benaderingen die u kunt overwegen wanneer u een multitenant-oplossing ontwerpt, en enkele antipatronen die u moet vermijden.

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 bevatten of aan één tenant zijn toegewezen.

Diagram met het patroon Implementatiestempels. Elke tenant heeft een eigen stempel met een database.

Wanneer u stempels met één tenant gebruikt, is het patroon Implementatiestempels meestal eenvoudig te implementeren, omdat elke stempel waarschijnlijk niet op de hoogte is van andere, dus er hoeven geen multitenancylogica of -mogelijkheden in de toepassingslaag te worden ingebouwd. Wanneer elke tenant een eigen toegewezen stempel heeft, biedt dit patroon de hoogste mate van isolatie en wordt het probleem met luidruchtige buren opgelost. Het biedt ook de mogelijkheid om tenants te configureren of aan te passen aan hun eigen vereisten, bijvoorbeeld om zich te bevinden in een specifieke geopolitieke regio of om specifieke vereisten voor hoge beschikbaarheid te hebben.

Bij het gebruik van multitenantstempels moeten andere patronen worden overwogen om multitenancy binnen de stempel te beheren. Het probleem met de ruis kan nog steeds van toepassing zijn. Door het patroon Implementatiestempels te gebruiken, kunt u echter blijven schalen naarmate uw oplossing groeit.

Het grootste probleem met het patroon Implementatiestempels, wanneer het wordt gebruikt voor één tenant, zijn meestal de kosten van de infrastructuur. Wanneer u stempels met één tenant gebruikt, moet elke zegel een eigen afzonderlijke infrastructuur hebben, die niet wordt gedeeld met andere tenants. U moet er ook voor zorgen dat de resources die zijn geïmplementeerd voor een zegel 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 compenseert.

Zegels met één tenant werken vaak goed wanneer u een klein aantal tenants hebt. Naarmate uw aantal huurders groeit, is het mogelijk, maar steeds moeilijker om een vloot van postzegels te beheren (zie deze casestudy als voorbeeld). U kunt ook het patroon Implementatiestempels toepassen om een reeks multitenantstempels te maken, die voordelen kunnen 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 door declaratieve infrastructuur als code te gebruiken, zoals Bicep-, ARM-sjablonen of Terraform-sjablonen. U kunt ook aangepaste code maken om elke stempel te implementeren en te beheren, bijvoorbeeld met behulp van Azure SDK's.

Doelgroep

De artikelen in deze sectie zijn bedoeld om nuttig te zijn voor oplossingsarchitecten en hoofdontwikkelaars van multitenant-toepassingen, waaronder onafhankelijke softwareleveranciers (ISV's) en start-ups die SaaS-oplossingen ontwikkelen. Veel van de richtlijnen in deze sectie zijn algemeen en zijn van toepassing op meerdere Azure-services binnen een categorie.

Volgende stappen

We raden u aan de methoden voor resource-organisatie in een multitenant-oplossing te bekijken voordat u de richtlijnen over specifieke categorieën van Azure-services bekijkt.