Delen via

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 overwegen dat veel klanten proefversies aanvragen of vereisen voordat ze een oplossing aanschaffen.

Experimenten brengen de volgende unieke overwegingen met zich mee:

  • Servicevereisten: Moeten proefversies voldoen aan dezelfde vereisten voor gegevensbeveiliging, prestaties en serviceniveau als de gegevens voor volledige klanten?
  • Infrastructuur: Moet u dezelfde infrastructuur gebruiken voor proeftenants als voor volledige klanten, of moet u een toegewezen infrastructuur voor proeftenants hebben?
  • Migratie: Als klanten na een proefabonnement uw service aanschaffen, hoe migreren ze 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 neemt uw team deel aan elke aanvraag?
  • Limieten: Welke limieten wilt u of wilt plaatsen voor proefklanten, zoals tijdslimieten, functiebeperkingen of beperkingen met betrekking tot prestaties?

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 de volgende vragen:

  • Proces: Is onboarding een selfservice-, geautomatiseerde of handmatige procedure?
  • Gegevenslocatie: Heeft de tenant specifieke vereisten voor gegevenslocatie? Zijn er bijvoorbeeld regels voor gegevenssoevereine van kracht?
  • Naleving: Moet de tenant voldoen aan alle nalevingsstandaarden (zoals PCI DSS, HIPAA, enzovoort)?
  • Herstel na noodgevallen: 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 verstrekt?
  • Informatie: Welke informatie hebt u nodig om de tenant volledig te kunnen onboarden? Moet u bijvoorbeeld de juridische naam van de organisatie weten? Hebt u hun bedrijfslogo nodig om de toepassing te voorzien van een merk en zo ja, welke bestandsgrootte en indeling hebt u nodig?
  • Facturering: Biedt het platform verschillende prijsopties en factureringsmodellen?
  • Omgevingen: Vereist de tenant preproductieomgevingen? En zijn er verwachtingen over beschikbaarheid voor die omgeving? Is het tijdelijk (op aanvraag) of altijd beschikbaar?

Nadat tenants zijn onboarding uitgevoerd, verplaatsen ze zich naar een 'bedrijfsstatus zoals gebruikelijk'. 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. Verschillende tenants kunnen updates op verschillende tijdstippen hebben toegepast.

Zie Updates voor andere overwegingen over het bijwerken van implementaties van tenants.

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 voor retailers biedt, kunt u verwachten dat bepaalde tijden van het jaar bijzonder druk zijn in sommige geografische regio's en op andere momenten rustig zijn. Overweeg of deze seizoensgebondenheid van invloed is op de manier waarop u uw oplossing ontwerpt en schaalt. Houd er rekening mee hoe seizoensgebondenheid van invloed kan zijn op problemen met ruis, zoals wanneer een subset van tenants een plotselinge en onverwachte toename van de belasting ondervindt die de prestaties van andere tenants vermindert. 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 een voldoende capaciteitsniveau voor het afhandelen van pieken en dalen in het verkeer.

Tenants verplaatsen tussen infrastructuur

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

  • 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 belasting opnieuw te verdelen.
  • Upgrades: Een tenant werkt hun SKU of prijscategorie bij en ze moeten worden verplaatst naar een specifieke 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: voor een tenant moeten de gegevens worden verplaatst naar een nieuwe geografische regio. Deze vereiste kan optreden tijdens het verwerven van een bedrijf of wanneer wetten of geopolitieke situaties veranderen.

Overweeg hoe u de gegevens van uw tenants verplaatst en hoe u 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 volledig op de hoogte 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. Voorbeeld:

  • In bedrijfsscenario's kunnen bedrijven worden verkregen of samengevoegd, inclusief bedrijven in verschillende geografische regio's.
  • In bedrijfsscenario's kunnen bedrijven splitsen of afsplitsen.
  • In consumentenscenario's kunnen individuele gebruikers deelnemen aan of verlaten van gezinnen.

Overweeg of u mogelijkheden moet bieden voor het beheren van de samenvoeging en scheiding van gegevens, gebruikersidentiteiten en resources. Overweeg 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 individuele gezinsleden die hen hebben bijgedragen of door het gezin als geheel? Als gebruikers het gezin verlaten, moeten hun gegevens worden verwijderd of in de gegevensset van het gezin blijven staan? Als gebruikers lid worden van een andere familie, moeten hun oude foto's met hen meegaan?

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:

  • Bewaarperiode: Hoe lang moet u de klantgegevens onderhouden? Zijn er wettelijke vereisten om gegevens na een bepaalde periode te vernietigen?
  • Reonboarding: Moet u klanten de mogelijkheid bieden om opnieuw aan boord te gaan? Zijn hun gegevens nog steeds beschikbaar als ze opnieuw deelnemen binnen de gegevensretentieperiode?
  • Herverdeling: Als u een gedeelde infrastructuur uitvoert, moet u de toewijzing van tenants aan 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. Voorbeeld:

  • De klant heeft deactivering aangevraagd. In een consumentensysteem kan een klant zich afmelden.
  • De klant kan niet worden gefactureerd en u moet het abonnement deactiveren.

Deactivering is gescheiden van offboarding omdat het bedoeld is om een tijdelijke status te zijn. Na een bepaalde periode kunt u er echter voor kiezen om een gedeactiveerde tenant uit te schakelen.

Medewerkers

Dit artikel wordt onderhouden door Microsoft. De tekst 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.