Wanneer u een architectuur met meerdere tenants overweegt, zijn er verschillende beslissingen die u moet nemen en elementen die u moet overwegen.
In een architectuur met meerdere tenants deelt u enkele of alle resources tussen tenants. Dit proces betekent dat een multitenant-architectuur u kosten en operationele efficiëntie kan bieden. Multitenancy introduceert echter complexiteiten. U moet uzelf de volgende vragen stellen:
- Hoe definieert u wat een tenant is voor uw specifieke oplossing? Komt een tenant overeen met een klant, een gebruiker of een groep gebruikers, zoals een team of een gezin?
- Hoe implementeert u uw infrastructuur ter ondersteuning van multitenancy en hoeveel isolatie hebt u tussen tenants?
- Welke commerciële prijsmodellen bieden uw oplossing en hoe zijn uw prijsmodellen van invloed op uw multitenancyvereisten?
- Welk serviceniveau moet u aan uw tenants bieden, in verschillende dimensies, zoals prestaties, tolerantie, beveiliging en nalevingsvereisten, zoals gegevenslocatie?
- Hoe wilt u uw bedrijf of oplossing laten groeien? Wordt deze geschaald naar het aantal tenants dat u verwacht?
- Hebben uw tenants ongebruikelijke of speciale vereisten? Heeft uw grootste klant bijvoorbeeld hogere prestaties of sterkere garanties nodig dan anderen?
- Hoe bewaakt, beheert, automatiseert, schaalt en beheert u uw Azure-omgeving en hoe heeft multitenancy invloed op uw beheerstrategie?
- Welke onderdelen van uw oplossing verwerken onboarding en beheer van tenants en hoe moeten deze onderdelen worden ontworpen?
Wat uw architectuur ook is, het is essentieel dat u een duidelijk inzicht hebt in de vereisten van uw klanten of tenants. Als u verkooptoezeggingen hebt gedaan aan klanten of als u contractuele verplichtingen of nalevingsvereisten hebt om aan te voldoen, moet u weten wat deze vereisten zijn wanneer u uw oplossing ontwerpt. Maar ook uw klanten kunnen impliciete verwachtingen hebben over hoe dingen moeten werken of hoe u zich moet gedragen, wat van invloed kan zijn op de manier waarop u een multitenant-oplossing ontwerpt.
Stel dat u een multitenant-oplossing bouwt die u verkoopt aan bedrijven in de financiële dienstverlening. Uw klanten hebben zeer strikte beveiligingsvereisten en ze hebben u nodig om een uitgebreide lijst op te geven van elke domeinnaam die door uw oplossing wordt gebruikt, zodat ze deze kunnen toevoegen aan de acceptatielijst van hun firewall. Deze vereiste is van invloed op de Azure-services die u gebruikt en het isolatieniveau dat u moet bieden tussen uw tenants. Ze vereisen ook dat hun oplossing een minimumniveau van tolerantie heeft. Er zijn mogelijk veel vergelijkbare verwachtingen, zowel expliciet als impliciet, die u in uw hele oplossing moet overwegen.
In deze sectie beschrijven we een aantal overwegingen die u moet geven, de vereisten die u moet uitlokken en enkele van de compromissen die u moet maken, wanneer u een multitenant-architectuur plant.
Doelgroep
De artikelen in deze sectie zijn met name relevant voor technische besluitvormers, zoals chief technology officers (CPO's) en architecten, evenals productmanagers. De doelgroep omvat ook onafhankelijke softwareleveranciers (ISV's) en startups die SaaS-oplossingen ontwikkelen. Bovendien moet iedereen die werkt met multitenant-architecturen enige bekendheid hebben met deze principes en compromissen.
Volgende stappen
Overweeg verschillende tenancymodellen voor uw oplossing.