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 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 vooral belangrijk om duidelijk te zijn over uw updatebeleid, omdat sommige van uw tenants misschien 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.

Dit artikel bevat richtlijnen voor technische besluitvormers over benaderingen voor het bijwerken van tenantsoftware en de betrokken afwegingen.

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 mogelijk hebben wanneer hun oplossing kan worden bijgewerkt. Deze verwachtingen of vereisten kunnen formeel aan u worden meegedeeld in contracten of serviceovereenkomsten, of ze kunnen informeel zijn.

• Onderhoudsvensters: Begrijp of uw klanten service-gedefinieerde of zelfgedefinieerde onderhoudsvensters verwachten. Ze moeten mogelijk communiceren met hun gebruikers over mogelijke storingen. Ze kunnen ook verwachten dat ze belangrijke aspecten van uw service testen nadat de update is voltooid.

• Regelgeving: Geef aan of klanten zorgen hebben over regelgeving die extra goedkeuring vereisen voordat updates kunnen worden toegepast. Als u bijvoorbeeld een gezondheidsoplossing met IoT-onderdelen opgeeft, moet u mogelijk goedkeuring krijgen van de Fda (Food and Drug Administration) van de Verenigde Staten 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 problemen identificeert die updates veroorzaken. 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 activeert.

Uw behoeften

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

• Controle die u bereid bent te 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 oplossing bouwt die gericht is op de consument, is het onwaarschijnlijk dat u controle geeft over de manier waarop u uw oplossing upgradet of uitvoert.

• Versies: Hoeveel versies van uw oplossing kunt u redelijk in één keer onderhouden? Als u een bug of beveiligingsprobleem vindt en een hotfix moet toepassen, moet u deze mogelijk toepassen op alle versies die momenteel in gebruik zijn.

• 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 terugdraaiacties naar eerdere versies ondersteunen? Wilt u deze mogelijkheid inschakelen?

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 de drukste dag van de week is, kunt u overwegen of u updates van maandag net zo eenvoudig kunt uitstellen zonder dat dit van invloed is op uw oplossing.

Een benadering die goed kan werken, is het implementeren van updates op tenant-per-tenantbasis met behulp van een van de implementatiestrategieën. Informeer uw klanten over geplande updates. Toestaan dat klanten zich tijdelijk maar niet permanent afmelden. Zet een redelijke limiet op wanneer u wilt dat de update wordt toegepast.

Overweeg 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 om tenants in staat te stellen hun eigen updates te starten gedurende een periode die ze kiezen. Nogmaals, u moet een deadline opgeven, waarna u de update namens hen toepast.

Ongeacht wat u doet, moet u ervoor zorgen dat u een proces hebt om de gezondheid van uw tenants te bewaken, met name voor en na het toepassen van updates. Kritieke productie-incidenten, ook wel live-site-incidenten genoemd, vinden vaak plaats na wijzigingen in code of configuratie. Als gevolg hiervan is het belangrijk om proactief te controleren op en te reageren op eventuele problemen om het vertrouwen van klanten te behouden. Zie Incidentbeheer voor SaaS-workloads in Azure voor meer informatie.

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.

Houd rekening met 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 deze 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. Uw updatestrategie is sterk afhankelijk van 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. U moet weten welke versie van infrastructuur, software of functie elke tenant gebruikt, waarvoor ze in aanmerking komen om naar te migreren en elke tijdgerelateerde gegevens die aan die statussen zijn gekoppeld. Het bijhouden van deze informatie is vaak een van de verantwoordelijkheden van een controlelaag.

Patroon voor implementatiestempels

Veel multitenant-toepassingen zijn geschikt voor het Deployment Stamps-patroon. In dit patroon implementeert u meerdere exemplaren van uw toepassing en andere onderdelen. 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 op 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 scenario's 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 Configuration te gebruiken.

Implementatieringen

Met uitrolringen kunt u updates geleidelijk uitrollen naar een reeks tenants of implementatiemerken. U kunt een subset van tenants toewijzen aan elke ring in de implementatiereeks.

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

• Kanarie: Een canary-ring bevat uw eigen testtenants en klanten die updates willen ontvangen zodra ze beschikbaar zijn. Iedereen binnen de canary ring moet begrijpen dat ze frequentere updates kunnen ontvangen. Deze updates hebben mogelijk niet zo uitgebreid een validatieproces doorlopen als updates in andere ringen.

• Vroege 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.

Bijdragers

Microsoft onderhoudt dit artikel. De volgende inzenders hebben dit artikel geschreven.

Hoofdauteur:

• John Downs | Principal Software Engineer, Azure Patterns & Practices

Andere Inzenders:

• Chad Kittel | Principal Software Engineer, Azure Patterns & Practices
• Daniel Scott-Raynsford | Partner Technologie Strategist
• Arsen Vladimirskiy | Hoofdklantingenieur, FastTrack voor Azure

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

Volgende stap

Leer hoe je verzoeken aan tenants toewijst in een multitenant-oplossing.