Overwegingen voor het bijwerken van een multitenant-oplossing

Een van de voordelen van cloudtechnologie is continue verbetering en evolutie. Als serviceprovider moet u updates toepassen op uw oplossing: mogelijk moet u wijzigingen aanbrengen in uw Azure-infrastructuur, uw code/toepassingen, uw databaseschema's of een ander onderdeel. Het is belangrijk om te plannen hoe u uw omgevingen bij werkt. In een oplossing met meerdere tenants is het met name belangrijk om duidelijk te zijn over uw updatebeleid, omdat sommige tenants mogelijk niet bereid zijn om wijzigingen in hun omgevingen toe te staan of omdat ze vereisten hebben die de tijden beperken waarop u hun service kunt bijwerken. U moet de vereisten van uw tenants identificeren, uw eigen vereisten voor het gebruik van uw service verduidelijken, een balans vinden die voor iedereen werkt en dit vervolgens duidelijk communiceren.

De vereisten van uw klanten

Denk na over de volgende vragen:

• Hebben uw klanten verwachtingen of vereisten over wanneer ze kunnen worden bijgewerkt? Deze kunnen formeel aan u worden gecommuniceerd in contracten of serviceovereenkomsten, of ze kunnen informeel zijn.
• Verwachten uw klanten service-gedefinieerde of zelfs zelf gedefinieerde onderhoudsvensters? Ze moeten mogelijk met hun eigen klanten communiceren over mogelijke uitval.
• Hebben uw klanten problemen met regelgeving die extra goedkeuring vereisen voordat updates kunnen worden toegepast? Als u bijvoorbeeld een statusoplossing biedt die IoT-onderdelen bevat, moet u mogelijk goedkeuring krijgen van de Verenigde Staten Food and Drug Administration (WAS) voordat u een update kunt toepassen.
• Is een van uw klanten bijzonder gevoelig of bestand tegen het toepassen van updates? Probeer te begrijpen waarom. Als ze bijvoorbeeld een fysieke winkel of een retailwebsite uitvoeren, willen ze mogelijk updates rondom Black Friday, omdat de risico's groter zijn dan mogelijke voordelen.
• Wat is uw trackrecord van het voltooien van updates zonder dat dit van invloed is op uw klanten? U moet goede DevOps-, test-, implementatie- en bewakingsprocedures volgen om de kans op uitval te verminderen en ervoor te zorgen dat u snel problemen identificeert die updates introduceren. Als uw klanten weten dat u hun omgevingen probleemloos kunt bijwerken, zullen ze minder snel objecten maken.
• Willen klanten updates terugdraaien als er sprake is van een wijziging die een wijziging in de weg staat?

Uw vereisten

U moet ook rekening houden met de volgende vragen vanuit uw eigen perspectief:

• Is het redelijk dat uw klanten controle hebben over wanneer updates worden toegepast? Als u een oplossing bouwt die wordt gebruikt door grote zakelijke klanten, kan het antwoord ja zijn. Als u echter een op consumenten gerichte oplossing bouwt, is het onwaarschijnlijk dat u controle geeft over hoe u uw oplossing upgradet of werkt.
• Hoeveel versies van uw oplossing kunt u redelijk in één keer onderhouden? Als u een fout vindt en deze wilt hotfixen, moet u de hotfix mogelijk toepassen op alle versies die worden gebruikt.
• Wat zijn de gevolgen van het te ver achterblijven van de huidige versie van klanten? Als u regelmatig nieuwe functies uit brengt, worden oude versies dan snel verouderd? Afhankelijk van uw upgradestrategie en de typen wijzigingen moet u mogelijk afzonderlijke infrastructuren onderhouden voor elke versie van uw oplossing. Er kunnen dus zowel operationele als financiële kosten zijn, omdat u ondersteuning voor oudere versies behoudt.
• Kan uw implementatiestrategie ondersteuning bieden voor terugdraaien naar eerdere versies? Wilt u dit inschakelen?

Een saldo zoeken

Als u de snelheid van uw service-updates volledig aan de discretie van uw tenants over laat, kunnen ze ervoor kiezen om nooit bij te werken. Het is belangrijk dat u uw oplossing kunt bijwerken, terwijl u rekening moet houden met eventuele redelijke zorgen of beperkingen die uw klanten hebben. Als een klant bijvoorbeeld bijzonder gevoelig is voor updates op een vrijdag (omdat dit de drukste dag van de week is), kunt u updates dan net zo eenvoudig uitstellen naar maandagen, zonder dat dit van invloed is op uw oplossing?

Een benadering die goed kan werken, is het uitrollen van updates per tenant, met behulp van een van de hieronder beschreven benaderingen. Geef uw klant op de hoogte van geplande updates. Klanten toestaan om zich tijdelijk uit te kiezen, maar niet voor altijd; een redelijke limiet in te stellen op het moment dat de update moet worden toegepast.

Overweeg ook om uzelf de mogelijkheid te bieden beveiligingspatches of andere kritieke hotfixes te implementeren, met minimale of geen kennisgeving vooraf.

Een andere benadering kan zijn om tenants in staat te stellen hun eigen updates te initiëren op een tijdstip van hun keuze. Ook hier moet u een deadline verstrekken, waarna u de update namens hen kunt toepassen.

Wat u ook doet, zorg ervoor dat u een proces hebt om de status van uw tenants te bewaken, met name voordat en nadat updates zijn toegepast. Vaak vinden kritieke productie-incidenten (ook wel live-site-incidenten genoemd) plaats na updates van code of configuratie. Daarom is het belangrijk dat u proactief op problemen controleert en reageert om het vertrouwen van de klant te behouden. Zie Bewaking voor DevOps voor meer informatie over bewaking

Communiceren met uw klanten

Duidelijke communicatie is essentieel voor het opbouwen van het vertrouwen van uw klanten. Het is belangrijk om de voordelen van regelmatige updates uit te leggen, waaronder nieuwe functies, opgeloste fouten, het oplossen van beveiligingsproblemen en prestatieverbeteringen. Een van de voordelen van een moderne cloudoplossing is de continue levering van functies en updates.

Denk na over de volgende vragen:

• Wilt u klanten op de hoogte stellen van toekomstige updates?
• Als u dit doet, vraagt u dan impliciet toestemming aan door een opt-outproces op te geven?
• Hebt u een gepland onderhoudsvenster dat u gebruikt bij het toepassen van updates?
• Wat gebeurt er als u een noodupdate hebt, zoals een kritieke beveiligingspatch? Kunt u updates in dergelijke situaties forcen?
• Als u de klant niet proactief op de hoogte kunt stellen van toekomstige updates, kunt u dan achteraf meldingen geven? Kunt u bijvoorbeeld een pagina op uw website bijwerken met de lijst met updates die u hebt toegepast?

Communiceren met uw klantondersteuningsteam

Het is belangrijk dat uw eigen ondersteuningsteam volledig inzicht heeft in updates die op elke tenant zijn toegepast. Medewerkers van de klantondersteuning moeten de volgende vragen eenvoudig kunnen beantwoorden:

• Zijn er onlangs updates toegepast op de infrastructuur van een tenant?
• Wat was de aard van deze updates?
• Wat was de vorige versie?
• Hoe vaak worden updates toegepast op deze tenant?

Als een van uw klanten een probleem heeft vanwege een update, moet u ervoor zorgen dat uw klantondersteuningsteam over de benodigde informatie beschikt om te begrijpen wat er is gewijzigd.

Implementatiestrategieën ter ondersteuning van updates

Denk na over hoe u updates implementeert in uw infrastructuur. Dit wordt sterk beïnvloed door het tenancymodel dat u gebruikt. Drie veelgebruikte methoden voor het implementeren van updates zijn implementatiestempels, functievlaggen en implementatieringen.

Zorg er in alle gevallen voor dat u voldoende rapportage/zichtbaarheid hebt, zodat u weet welke versie van de infrastructuur, software of functie elke tenant heeft, waar ze in aanmerking komen voor migratie naar en eventuele tijdgerelateerde gegevens die aan deze staten zijn gekoppeld.

Implementatiestempels

Sommige multitenant-toepassingen zijn geschikt voor het patroon Implementatiestempels,waarin u meerdere exemplaren van uw toepassing en andere onderdelen implementeert. Afhankelijk van uw isolatievereisten kunt u een zegel implementeren voor elke tenant of gedeelde stempels die de workloads van meerdere tenants uitvoeren.

Stempels zijn een uitstekende manier om isolatie tussen tenants te bieden. Ze bieden u ook flexibiliteit voor uw updateproces, omdat u updates progressief kunt uitrollen over stempels, zonder dat dit van invloed is op anderen.

Functievlaggen

Met functievlaggen kunt u functionaliteit toevoegen aan uw oplossing, terwijl u alleen een subset van uw klanten of tenants beschikbaar maakt. U kunt functievlaggen gebruiken als u regelmatig updates implementeert, maar geen nieuwe functionaliteit wilt weergeven, of als u wilt voorkomen dat er wijzigingen in het gedrag worden toegepast totdat een klant zich heeft gekozen.

U kunt ondersteuning voor functievlaggetjes insluiten in uw toepassing door zelf code te schrijven of door een service zoals Azure App Configuration.

Implementatieringen

Met implementatieringen kunt u updates progressief implementeren in een set tenants of implementatiestempels. U kunt een subset van tenants toewijzen aan elke ring. Een canary-ring bevat uw eigen testten tenants en klanten die updates willen zodra ze beschikbaar zijn, met de kennis dat ze mogelijk vaker updates ontvangen en dat updates mogelijk niet zo uitgebreid zijn uitgevoerd als in de andere zaken. Een early adopter-ring bevat tenants die iets risicovoller zijn, maar die nog steeds zijn voorbereid op regelmatige updates. De meeste tenants behoren tot de gebruikersring, die minder frequente en meer geteste updates ontvangt.

API-versies

Als uw service een externe API beschikbaar maakt, moet u er rekening mee houden dat eventuele updates die u wilt toepassen van invloed kunnen zijn op de manier waarop klanten of partners integreren met uw platform. Met name moet u zich bewust zijn van belangrijke wijzigingen in uw API's. Overweeg het gebruik van een API-versiestrategie om het risico van updates voor uw API te beperken.

Volgende stappen

• Overweeg wanneer u aanvragen aan tenants zou toe te wijsen in een multitenant-oplossing.
• Bekijk de Controlelijst voor DevOps in Azure Well-Architected Framework.