Overwegingen voor de levenscyclus van tenants in een oplossing met meerdere tenants

Wanneer u een architectuur met meerdere tenants overweegt, is het belangrijk om alle verschillende fasen in de levenscyclus van een tenant te overwegen.

Proeften tenants

Houd er bij SaaS-oplossingen rekening mee dat veel klanten proefversies aanvragen of vereisen voordat ze een oplossing aanschaffen. Proefversies brengen de volgende unieke overwegingen met zich mee:

• Moeten voor de proefgegevens dezelfde vereisten gelden voor gegevensbeveiliging, prestaties en serviceniveau als voor de gegevens voor volledige klanten?
• Moet u dezelfde infrastructuur gebruiken voor proeften tenants als voor volledige klanten, of moet u een speciale infrastructuur voor proeften tenants hebben?
• Als klanten uw service na een proefversie aanschaffen, hoe migreren ze dan de gegevens van hun proeften tenants naar hun betaalde tenants?
• Gelden er limieten voor wie een proefversie kan aanvragen? Hoe kunt u misbruik van uw oplossing voorkomen?
• Welke limieten wilt of moet u instellen voor klanten met een proefversie, zoals tijdslimieten, functiebeperkingen of beperkingen met betrekking tot prestaties?

Nieuwe tenants onboarden

Houd rekening met het volgende bij het onboarden van een nieuwe tenant:

• Is onboarding een selfservice, geautomatiseerd of handmatig proces?
• Heeft de klant specifieke vereisten voor gegevensstatus? Zijn er bijvoorbeeld voorschriften voor gegevenssoevereiniteit van kracht?
• Moet de klant voldoen aan nalevingsstandaarden (zoals PCI DSS, HIPAA, en meer)?
• Heeft de klant specifieke vereisten voor herstel na noodherstel, zoals een RTO (Recovery Time Objective) of een RPO (Recovery Point Objective)? Verschillen deze van de garanties die u andere klanten biedt?
• Welke informatie hebt u nodig om de klant volledig te kunnen onboarden?
• Biedt het platform verschillende prijsopties en factureringsmodellen?
• Heeft de klant preproductieomgevingen nodig? En zijn er verwachtingen over de beschikbaarheid van die omgeving? Is het tijdelijk (op aanvraag) of altijd beschikbaar?

Zodra de onboarding van tenants is afgelopen, schakelen ze over naar de modus 'Business as usual'. Er kunnen echter nog steeds verschillende belangrijke levenscyclusgebeurtenissen plaatsvinden, zelfs wanneer ze zich in deze modus voordoen.

De infrastructuur van tenants bijwerken

U moet overwegen hoe u updates op de infrastructuren van uw tenants kunt toepassen. Voor verschillende tenants kunnen updates op verschillende tijdstippen worden toegepast. Zie Updates voor andere overwegingen over het bijwerken van de implementaties van tenants.

De infrastructuur van tenants schalen

Overweeg of uw tenants seizoensgebonden bedrijfspatronen hebben of het verbruiksniveau voor uw oplossing op een andere manier wijzigen. Als u bijvoorbeeld een oplossing biedt aan detailhandelaren, verwacht u dat het op bepaalde tijdstippen van het jaar in bepaalde geografische regio's bijzonder druk is en op andere momenten rustig. Overweeg of dit van invloed is op de manier waarop u uw oplossing ontwerpt en schaalt, en houd rekening met ruisproblemen wanneer een subset van tenants onverwacht wordt geschaald en de prestaties voor andere tenants beïnvloedt. U kunt overwegen om oplossingen toe te passen, zoals het schalen van de infrastructuur van afzonderlijke tenants, het verplaatsen van tenants tussen implementaties en het inrichten van voldoende capaciteit om pieken en dalen in het verkeer af te handelen.

Tenants tussen infrastructuren verplaatsen

Mogelijk moet u om verschillende redenen tenants tussen infrastructuren verplaatsen, waaronder de volgende:

• U partitioneert uw klanten verticaal en kiest ervoor om uw tenants opnieuw te verdelen over uw infrastructuren of implementaties.
• Klanten upgraden een SKU of prijscategorie en ze moeten worden verplaatst naar een specifieke implementatie met één tenant met een hogere isolatie van andere tenants.
• Klanten vragen hun gegevens te worden verplaatst naar een toegewezen gegevensopslag.
• Klanten vereisen dat hun gegevens worden verplaatst naar een nieuwe geografische regio. Dit kan gebeuren tijdens bedrijfsovernames of wanneer wetten of geopolitieke situaties veranderen.

Denk na over hoe u de gegevens van uw tenants verplaatst en aanvragen omleiden naar de nieuwe set infrastructuur die als host voor de instantie van deze tenants wordt gebruikt. U moet ook overwegen of het verplaatsen van een tenant downtime tot gevolg heeft en ervoor zorgen dat tenants hiervan op de hoogte zijn.

Tenants samenvoegen en splitsen

Het is verleidelijk om tenants of klanten te zien als statische, ongewijzigde entiteiten. In werkelijkheid is dit echter vaak niet waar. Bijvoorbeeld:

• In bedrijfsscenario's kunnen bedrijven worden overgenomen of samengevoegd, inclusief bedrijven die zich in verschillende geografische regio's bevinden.
• Op dezelfde manier kunnen bedrijven in bedrijfsscenario's splitsen of van de hand gaan.
• In consumentenscenario's kunnen afzonderlijke gebruikers lid worden van een familie of deze verlaten.

Overweeg of u mogelijkheden moet bieden voor het beheren van de samenvoeging en scheiding van gegevens, gebruikersidentiteiten en resources. Bedenk ook hoe het eigendom van gegevens van invloed is op uw verwerking van samenvoegings- en splitsbewerkingen. Denk bijvoorbeeld aan een consumententoepassing die is gebouwd voor families om foto's met elkaar te delen. Zijn de foto's het eigendom van de afzonderlijke familieleden die ze hebben bijgedragen, of door de familie als geheel? Als gebruikers de familie verlaten, moeten hun gegevens dan worden verwijderd of in de gegevensset van de familie blijven? Als gebruikers lid worden van een andere familie, moeten hun oude foto's dan mee?

Offboard-tenants

Het is ook onvermijdelijk dat tenants af en toe uit uw oplossing moeten worden verwijderd. In een multitenant-oplossing brengt dit enkele belangrijke overwegingen met zich mee, waaronder de volgende:

• Hoe lang moet u de klantgegevens onderhouden? Zijn er juridische vereisten voor het vernietigen van gegevens na een bepaalde periode?
• Moet u klanten de mogelijkheid bieden om de onboarding opnieuw uit te kunnen vinden?
• Als u een gedeelde infrastructuur hebt, moet u dan de toewijzing van tenants aan infrastructuur opnieuw in balans brengen?

Tenants deactiveren en opnieuw activeren

Er zijn situaties waarin het account van een klant mogelijk moet worden gedeactiveerd of opnieuw moet worden geactiveerd. Bijvoorbeeld:

• De klant heeft deactivering aangevraagd. In een consumentensysteem kan een klant ervoor kiezen om zich af te melden.
• De klant kan niet worden gefactureerd en u moet het abonnement deactiveren.

Deactivering staat los van offboarding omdat het is bedoeld als een tijdelijke status. Na een bepaalde periode kunt u er echter voor kiezen om een gedeactiveerde tenant te offboarden.

Volgende stappen

Houd rekening met de prijsmodellen die u voor uw oplossing gaat gebruiken.