Delen via

Overwegingen voor het bijwerken van een multitenant-oplossing

  • Artikel

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 toepassingscode, uw Azure-infrastructuur, uw databaseschema's of een ander onderdeel. Het is belangrijk om te plannen hoe u uw omgevingen bijwerkt. In een multitenant-oplossing is het met name belangrijk om duidelijk te zijn over uw updatebeleid, omdat sommige tenants mogelijk niet bereid zijn wijzigingen in hun omgevingen toe te staan, of dat ze vereisten hebben die de voorwaarden beperken waaronder u hun service kunt bijwerken.

Wanneer u een strategie plant om uw oplossing bij te werken, moet u het volgende doen:

  • Identificeer de vereisten van uw tenants.
  • Maak uw eigen vereisten duidelijk om uw service te bedienen.
  • Zoek een saldo dat zowel u als uw tenants kunnen accepteren.
  • Communiceer uw strategie duidelijk met uw tenants en andere belanghebbenden.

In dit artikel bieden we richtlijnen voor technische besluitvormers over de benaderingen die u kunt overwegen om de software van uw tenants bij te werken en de betrokken compromissen.

Vereisten van uw klanten

Klanten hebben vaak expliciete of impliciete vereisten die van invloed kunnen zijn op hoe uw systeem wordt bijgewerkt. Houd rekening met de volgende aspecten om een beeld te vormen van eventuele punten van zorg die klanten kunnen veroorzaken:

  • Verwachtingen en vereisten: ontdek eventuele verwachtingen of vereisten die klanten kunnen hebben wanneer hun oplossing kan worden bijgewerkt. Deze kunnen formeel aan u worden meegedeeld in contracten of serviceovereenkomsten, of informeel.
  • Onderhoudsvensters: begrijp of uw klanten service-gedefinieerde of zelfs zelfgedefinieerde onderhoudsvensters verwachten. Ze moeten mogelijk communiceren met hun gebruikers over mogelijke storingen, of ze moeten mogelijk belangrijke aspecten van uw service testen nadat de update is voltooid.
  • Voorschriften: Geef aan of klanten zorgen hebben over regelgeving waarvoor aanvullende goedkeuring is vereist voordat updates kunnen worden toegepast. Als u bijvoorbeeld een gezondheidsoplossing met IoT-onderdelen opgeeft, moet u mogelijk goedkeuring krijgen van de Verenigde Staten Food and Drug Administration (FDA) voordat u een update toepast.
  • Gevoeligheid: begrijp of een van uw klanten bijzonder gevoelig of bestand is tegen het toepassen van updates. Als dat zo is, probeer dan te begrijpen waarom. Als ze bijvoorbeeld een fysieke winkel of een retailwebsite uitvoeren, willen ze mogelijk updates rond Black Friday vermijden, omdat de risico's hoger zijn dan potentiële voordelen.
  • Geschiedenis: Controleer uw eigen trackrecord van het voltooien van updates zonder dat dit gevolgen heeft voor uw klanten. U moet goede DevOps-, test-, implementatie- en bewakingsprocedures volgen om de kans op storingen te verminderen en ervoor te zorgen dat u snel eventuele problemen identificeert die door updates worden geïntroduceerd. Als uw klanten weten dat u hun omgevingen soepel kunt bijwerken, is de kans kleiner dat ze bezwaar maken.
  • Terugdraaien: Overweeg of klanten updates willen terugdraaien als er sprake is van een wijziging die fouten veroorzaakt en wie een dergelijke terugdraaiaanvraag zou activeren.

Uw vereisten

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

  • Controle die u wilt bieden: 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 de consument gerichte oplossing bouwt, is het onwaarschijnlijk dat u controle krijgt over de manier waarop u uw oplossing bijwerken of uitvoert.
  • Versies: Hoeveel versies van uw oplossing kunt u redelijk in één keer onderhouden? Houd er rekening mee dat als u een bug vindt en deze moet oplossen, u de hotfix mogelijk moet toepassen op alle versies die worden gebruikt.
  • Gevolgen van oude versies: Wat is de impact van het laten vallen van klanten te ver achter de huidige versie? Als u regelmatig nieuwe functies vrijgeeft, worden oude versies 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 onderhoudt.
  • Terugdraaien: Kan uw implementatiestrategie terugdraaien naar eerdere versies ondersteunen? Is dit iets wat u wilt inschakelen?

Notitie

Overweeg of u uw oplossing offline moet halen voor updates of onderhoud. Over het algemeen worden storingsvensters gezien als een verouderde praktijk, en moderne DevOps-procedures en cloudtechnologieën kunt u downtime voorkomen tijdens updates en onderhoud. U moet echter ontwerpen voor implementaties zonder downtime, dus het is belangrijk om rekening te houden met uw updateproces wanneer u uw oplossingsarchitectuur plant.

Zelfs als u geen storingen plant tijdens het updateproces, kunt u nog steeds overwegen een regelmatig onderhoudsvenster te definiëren. Een venster kan u helpen om te communiceren met uw klanten dat er wijzigingen optreden tijdens specifieke tijden.

Zie Downtime elimineren via service-updates met versiebeheer voor meer informatie over het bereiken van implementaties zonder downtime.

Een balans zoeken

Als u de frequentie van uw service-updates volledig naar eigen goeddunken laat, kunnen ze ervoor kiezen om nooit bij te werken. Het is belangrijk om uzelf in staat te stellen uw oplossing bij te werken, terwijl u rekening houdt met redelijke problemen of beperkingen die uw klanten mogelijk hebben. Als een klant bijvoorbeeld bijzonder gevoelig is voor updates op een vrijdag, omdat dat hun drukste dag van de week is, kunt u net zo eenvoudig updates uitstellen naar maandag, zonder dat dit van invloed is op uw oplossing?

Een benadering die goed kan werken, is door updates per tenant uit te rollen met behulp van een van de hieronder beschreven benaderingen. Uw klant op de hoogte stellen van geplande updates. Toestaan dat klanten zich tijdelijk afmelden, maar niet voor altijd; zet een redelijke limiet op wanneer u wilt dat de update wordt toegepast.

Overweeg ook om uzelf de mogelijkheid te bieden om beveiligingspatches of andere kritieke hotfixes te implementeren, met minimale of geen voorafgaande kennisgeving. Zorg ervoor dat tenants deze praktijk en het belang ervan begrijpen bij het beveiligen van hun gegevens.

Een andere benadering kan zijn dat tenants hun eigen updates kunnen initiëren, op een moment van hun keuze. Nogmaals, u moet een deadline opgeven, waarna u de update namens hen toepast.

Waarschuwing

Wees voorzichtig met het inschakelen van tenants om hun eigen updates te initiëren. Dit is complex om te implementeren en vereist aanzienlijke ontwikkelings- en testinspanningen om te leveren en te onderhouden.

Wat u ook doet, zorg ervoor dat u een proces hebt om de status van uw tenants te controleren, met name voordat en nadat updates worden toegepast. Kritieke productie-incidenten (ook wel live-site-incidenten genoemd) vinden vaak plaats na updates voor code of configuratie. Daarom is het belangrijk dat u proactief controleert op en reageert op eventuele problemen om het vertrouwen van klanten te behouden. Zie Aanbevelingen voor het ontwerpen en maken van een bewakingssysteem 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, oplossingen voor fouten, het oplossen van beveiligingsproblemen en prestatieverbeteringen. Een van de voordelen van een moderne, in de cloud gehoste oplossing is de continue levering van functies en updates.

Denk na over de volgende vragen:

  • Informeert u klanten over toekomstige updates?
  • Als u dat doet, vraagt u impliciet toestemming aan door een opt-outproces op te geven en wat zijn de limieten voor afmelden?
  • Hebt u een gepland onderhoudsvenster dat u gebruikt wanneer u updates toepast?
  • Wat gebeurt er als u een noodupdate hebt, zoals een kritieke beveiligingspatch? Kunt u updates in die situaties afdwingen?
  • Als u klanten niet proactief op de hoogte kunt stellen van toekomstige updates, kunt u retrospectiefmeldingen geven? Kunt u bijvoorbeeld een pagina op uw website bijwerken met de lijst met updates die u hebt toegepast?
  • Hoeveel afzonderlijke versies van uw systeem onderhoudt u in productie?

Communiceren met uw klantondersteuningsteam

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

  • Zijn updates onlangs toegepast op de infrastructuur van een tenant of op gedeelde onderdelen?
  • Wat was de aard van die 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 de informatie heeft die nodig is om te begrijpen wat er is gewijzigd.

Implementatiestrategieën ter ondersteuning van updates

Overweeg hoe u updates implementeert in uw infrastructuur. Dit wordt sterk beïnvloed door het tenancymodel dat u gebruikt. Drie algemene benaderingen voor het implementeren van updates zijn implementatiestempels, functievlagmen en implementatieringen. U kunt deze benaderingen onafhankelijk gebruiken of u kunt deze combineren om te voldoen aan complexere vereisten.

Zorg er in alle gevallen voor dat u voldoende rapportage en zichtbaarheid hebt, zodat u weet welke versie van infrastructuur, software of functie elke tenant heeft, waarnaar ze in aanmerking komen om te migreren naar en eventuele tijdgerelateerde gegevens die aan deze statussen zijn gekoppeld.

Patroon Implementatiestempels

Veel 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 stempel implementeren voor elke tenant of gedeelde stempels waarop workloads van meerdere tenants worden uitgevoerd.

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

Functievlaggen

Met functievlagmen kunt u functionaliteit toevoegen aan uw oplossing, terwijl u deze functionaliteit alleen beschikbaar maakt voor een subset van uw klanten of tenants.

Overweeg het gebruik van functievlagmen als een van deze situaties op u van toepassing is:

  • U implementeert regelmatig updates, maar u wilt voorkomen dat er nieuwe functionaliteit wordt weergegeven totdat deze volledig is geïmplementeerd.
  • U wilt voorkomen dat wijzigingen in gedrag worden toegepast totdat een klant zich aanmeldt.

U kunt ondersteuning voor functievlagken insluiten in uw toepassing door zelf code te schrijven of door een service zoals Azure-app Configuratie te gebruiken.

Implementatieringen

Met implementatieringen kunt u updates geleidelijk implementeren in een set tenants of implementatiestempels. U kunt een subset tenants toewijzen aan elke ring.

U kunt bepalen hoeveel ringen u moet maken en wat elke ring betekent voor uw eigen oplossing. Organisaties gebruiken meestal de volgende ringen:

  • Canary: Een canary-ring bevat uw eigen testtenants en klanten die updates willen hebben zodra ze beschikbaar zijn, met het inzicht dat ze vaker updates kunnen ontvangen en dat updates mogelijk niet zo uitgebreid zijn geweest als in de andere zaken.
  • Early adopter: Een early adopter-ring bevat tenants die iets meer risico-averse zijn, maar die nog steeds bereid zijn om regelmatige updates te ontvangen.
  • Gebruikers: 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 updates die u toepast, van invloed kunnen zijn op de manier waarop klanten of partners integreren met uw platform. In het bijzonder moet u zich bewust zijn van belangrijke wijzigingen in uw API's. Overweeg het gebruik van een API-versiebeheerstrategie om het risico op updates voor uw API te beperken.

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 stap

Overweeg wanneer u aanvragen aan tenants toewijst in een multitenant-oplossing.