Overwegingen voor de levenscyclus van tenants in een multitenant-oplossing

  • Artikel

Wanneer u een architectuur met meerdere tenants overweegt, is het belangrijk om rekening te houden met alle verschillende fasen in de levenscyclus van een tenant. Op deze pagina bieden we richtlijnen voor technische besluitvormers over de fasen van de levenscyclus en de belangrijke overwegingen voor elke fase.

Proeftenants

Wanneer u een SaaS-oplossing bouwt, moet u er rekening mee houden dat veel klanten proefversies aanvragen of nodig hebben voordat ze een oplossing aanschaffen.

Proefversies brengen de volgende unieke overwegingen met zich mee:

  • Servicevereisten: Moeten proefversies worden onderworpen aan dezelfde gegevensbeveiligings-, prestatie- en serviceniveauvereisten als de gegevens voor volledige klanten?
  • Infrastructuur: Moet u voor proeftenants dezelfde infrastructuur gebruiken als voor volledige klanten, of moet u een speciale infrastructuur hebben voor proeftenants?
  • Migratie: Als klanten uw service na een proefversie aanschaffen, hoe migreren ze dan de gegevens van hun proeftenants naar hun betaalde tenants?
  • Aanvraagproces: Zijn er limieten voor wie een proefversie kan aanvragen? Hoe kunt u misbruik van uw oplossing voorkomen? Staat u het automatisch maken van proeftenants toe of wordt uw team betrokken bij elke aanvraag?
  • Grenzen: Welke limieten wilt of moet u toepassen op klanten met een proefversie, zoals tijdslimieten, functiebeperkingen of prestatiebeperkingen?

In sommige situaties kan een freemium-prijsmodel een alternatief zijn voor het bieden van proefversies.

Nieuwe tenants onboarden

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

  • Proces: Wordt onboarding een selfservice, geautomatiseerd of handmatig proces?
  • Gegevenslocatie: Heeft de tenant specifieke vereisten voor gegevenslocatie? Zijn er bijvoorbeeld regels voor gegevenssoevereineheid van kracht?
  • Naleving: Moet de tenant voldoen aan nalevingsstandaarden (zoals PCI DSS, HIPAA, enzovoort)?
  • Noodherstel: Heeft de tenant specifieke vereisten voor herstel na noodgevallen, zoals een beoogde hersteltijd (RTO) of een RPO (Recovery Point Objective)? Verschillen deze van de garanties die u aan andere tenants geeft?
  • Informatie: Welke informatie hebt u nodig om de tenant volledig te kunnen onboarden? Moet u bijvoorbeeld de juridische naam van hun organisatie weten? Hebt u hun bedrijfslogo nodig om de toepassing van het merk te voorzien, en zo ja, welke bestandsgrootte en indeling hebt u nodig?
  • Facturering: Biedt het platform verschillende prijsopties en factureringsmodellen?
  • Omgevingen: Zijn voor de tenant preproductieomgevingen vereist? En worden er verwachtingen gesteld over de beschikbaarheid voor die omgeving? Is het tijdelijk (on-demand) of altijd beschikbaar?

Nadat de onboarding van tenants is uitgevoerd, worden ze verplaatst naar de status 'business as usual'. Er zijn echter nog steeds verschillende belangrijke levenscyclus-gebeurtenissen die kunnen optreden, zelfs wanneer ze zich in deze status bevinden.

Infrastructuur van tenants bijwerken

U moet overwegen hoe u updates toepast op de infrastructuur van uw tenants. 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 mogelijk seizoensgebonden bedrijfspatronen hebben of anderszins het verbruiksniveau voor uw oplossing wijzigen.

Als u bijvoorbeeld een oplossing biedt aan detailhandelaren, kunt u verwachten dat bepaalde tijden van het jaar bijzonder druk zullen zijn in sommige geografische regio's en op andere momenten rustig. Overweeg of deze seizoensgebondenheid van invloed is op de manier waarop u uw oplossing ontwerpt en schaalt. Houd er rekening mee dat seizoensgebondenheid van invloed kan zijn op problemen met luidruchtige buren, bijvoorbeeld wanneer een subset van tenants een plotselinge en onverwachte toename van de belasting ervaart die de prestaties van andere tenants vermindert. U kunt overwegen om risicobeperkingen toe te passen, zoals het schalen van de infrastructuur van afzonderlijke tenants, het verplaatsen van tenants tussen implementaties en het inrichten van een voldoende capaciteitsniveau om pieken en dalen in het verkeer af te handelen.

Tenants verplaatsen tussen infrastructuur

Mogelijk moet u om een aantal redenen tenants tussen infrastructuur verplaatsen, waaronder:

  • Herverdeling: U volgt een verticaal gepartitioneerde benadering om uw tenants toe te wijzen aan de infrastructuur en u moet een tenant verplaatsen naar een andere implementatie om uw taken opnieuw te verdelen.
  • Upgrades: Een tenant voert een upgrade uit van de SKU of prijscategorie en ze moeten worden verplaatst naar een toegewezen implementatie met één tenant met een hogere isolatie van andere tenants.
  • Migraties: Een tenant vraagt om de gegevens te verplaatsen naar een toegewezen gegevensarchief.
  • Regio verplaatst: Een tenant vereist dat de gegevens worden verplaatst naar een nieuwe geografische regio. Dit kan gebeuren tijdens de overname van een bedrijf of wanneer wetten of geopolitieke situaties veranderen.

Overweeg hoe u de gegevens van uw tenants verplaatst en aanvragen omleidt naar de nieuwe set infrastructuur die als host fungeert voor hun exemplaar. U moet ook overwegen of het verplaatsen van een tenant kan leiden tot downtime en ervoor zorgen dat tenants zich volledig bewust zijn van het risico.

Tenants samenvoegen en splitsen

Het is verleidelijk om tenants of klanten te beschouwen als statische, onveranderlijke 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 opsplitsen of afstoten.
  • In consumentenscenario's kunnen individuele gebruikers lid worden van een gezin of deze verlaten.

Overweeg of u mogelijkheden moet bieden om het samenvoegen en scheiden van gegevens, gebruikersidentiteiten en resources te beheren. Bedenk ook hoe het eigendom van gegevens van invloed is op de verwerking van samenvoeg- en splitsingsbewerkingen. Denk bijvoorbeeld aan een toepassing voor consumentenfotografie die is gebouwd voor gezinnen om foto's met elkaar te delen. Zijn de foto's eigendom van de afzonderlijke gezinsleden die ze hebben bijgedragen of van het hele gezin? Als gebruikers het gezin verlaten, moeten hun gegevens dan worden verwijderd of in de gegevensset van het gezin blijven? Als gebruikers lid worden van een ander gezin, moeten hun oude foto's dan met hen meegaan?

Tenants offboarden

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:

  • Bewaarperiode: Hoe lang moet u de klantgegevens onderhouden? Zijn er wettelijke vereisten om gegevens na een bepaalde periode te vernietigen?
  • Opnieuw onboarden: Moet u klanten de mogelijkheid bieden om opnieuw onboarding uit te voeren?
  • Herverdeling: Als u een gedeelde infrastructuur uitvoert, moet u dan de toewijzing van tenants aan de infrastructuur opnieuw verdelen?

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 om deactivering gevraagd. 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 bedoeld is als een tijdelijke status. Na een bepaalde periode kunt u er echter voor kiezen om een gedeactiveerde tenant te offboarden.

Medewerkers

Dit artikel wordt onderhouden door Microsoft. Het is oorspronkelijk geschreven door de volgende inzenders.

Hoofdauteur:

Andere inzenders:

Als u niet-openbare LinkedIn-profielen wilt zien, meldt u zich aan bij LinkedIn.

Volgende stappen

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