Considérations relatives à la mise à jour d’une solution multilocataire

L’amélioration et l’évolution continues constituent l’un des avantages de la technologie cloud. En tant que fournisseur de services, vous devez appliquer des mises à jour à votre solution : vous pourriez avoir besoin d’apporter des modifications à votre code d’application, à votre infrastructure Azure, à vos schémas de base de données ou à tout autre composant. Il est important de planifier la mise à jour de vos environnements. Dans une solution multilocataire, il est particulièrement important de bien comprendre votre stratégie de mise à jour, car certains de vos locataires peuvent être réticents à autoriser les modifications dans leurs environnements ou ils peuvent avoir des exigences qui limitent les conditions dans lesquelles vous pouvez mettre à jour leur service.

Lorsque vous planifiez une stratégie de mise à jour de votre solution, vous devez :

• Identifier les exigences de vos locataires.
• Clarifier vos propres exigences pour exploiter votre service.
• Trouver un équilibre que vos locataires et vous-même pouvez accepter.
• Communiquer clairement votre stratégie à vos locataires et à d’autres parties prenantes.

Dans cet article, nous fournissons des conseils pour les décideurs techniques concernant les approches envisageables pour mettre à jour les logiciels des locataires, ainsi que les compromis impliqués.

Exigences de vos clients

Les clients ont souvent des exigences explicites ou implicites qui peuvent affecter la manière dont votre système est mis à jour. Envisagez les aspects suivants pour dresser un tableau des points de préoccupation que les clients pourraient soulever :

• Attentes et exigences : Découvrez les attentes ou les exigences que les clients pourraient avoir concernant le moment où leur solution peut être mise à jour. Elles peuvent vous être communiquées formellement dans des contrats commerciaux ou des contrats de niveau de service, ou elles peuvent être informelles.
• Fenêtres de maintenance : Comprenez si vos clients s’attendent à des fenêtres de maintenance définies par le service ou même définies par eux-mêmes. Ils pourraient avoir besoin de communiquer à leurs utilisateurs d’éventuelles interruptions, ou ils pourraient devoir tester des aspects importants de votre service une fois la mise à jour terminée.
• Réglementations : Clarifiez si les clients ont des préoccupations réglementaires nécessitant une approbation supplémentaire avant que les mises à jour puissent être appliquées. Par exemple, si vous fournissez une solution de santé comportant des composants IoT et que vous souhaitez appliquer une mise à jour, vous devrez peut-être obtenir l’approbation de l’administration compétente (la Food and Drug Administration, FDA, aux États-Unis).
• Sensibilité : Comprenez si certains de vos clients sont particulièrement sensibles ou réticents à l’application des mises à jour. Si c’est le cas, essayez de comprendre pourquoi. Par exemple, s’ils gèrent un magasin physique ou un site web de vente au détail, ils peuvent souhaiter éviter les mises à jour aux alentours du Black Friday, car les risques sont plus élevés que les avantages potentiels.
• Historique : Passez en revue votre propre historique de réussite de mise à jour sans impact pour vos clients. Vous devez adopter les bonnes pratiques de DevOps, de test, de déploiement et de surveillance afin de réduire la probabilité d’interruptions et de veiller à identifier rapidement tout problème introduit par les mises à jour. Si vos clients savent que vous pouvez mettre à jour leurs environnements en douceur, ils sont moins susceptibles de s’y opposer.
• Restauration : Envisagez si les clients souhaitent revenir en arrière sur les mises à jour en cas de changement disruptif, et qui déclencherait une telle demande de retour en arrière.

Vos exigences

Vous devez également considérer les questions suivantes de votre propre point de vue :

• Contrôle que vous êtes prêt à fournir : Est-il raisonnable pour vos clients de contrôler le moment où les mises à jour sont appliquées ? Si vous créez une solution utilisée par des clients d’une grande entreprise, la réponse peut être oui. Cependant, si vous construisez une solution axée sur le consommateur, il est peu probable que vous donniez un quelconque contrôle sur la façon dont vous mettez à niveau ou exploitez votre solution.
• Versions : Combien de versions de votre solution pouvez-vous raisonnablement gérer en une fois ? N’oubliez pas que si vous trouvez un bogue et que vous devez le corriger, vous devrez peut-être appliquer le correctif à toutes les versions utilisées.
• Conséquences des anciennes versions : Quel est l’impact si vous laissez les clients utiliser une version trop ancienne ? Si vous publiez de nouvelles fonctionnalités régulièrement, les anciennes versions deviendront-elles rapidement obsolètes ? En outre, selon votre stratégie de mise à niveau et les types de modifications, vous devrez peut-être mettre à jour des infrastructures distinctes pour chaque version de votre solution. La gestion du support des versions antérieures peut engendrer des coûts opérationnels et financiers au fil du temps.
• Restauration : Votre stratégie de déploiement peut-elle prendre en charge les restaurations vers les versions précédentes ? Est-ce quelque chose que vous souhaitez activer ?

Trouver un juste équilibre

Si vous laissez la cadence des mises à jour de vos services à l’entière discrétion de vos locataires, ceux-ci peuvent choisir de ne jamais les installer. Il est important que vous vous autorisiez à mettre à jour votre solution tout en tenant compte des préoccupations ou des contraintes raisonnables de vos clients. Par exemple, si un client est particulièrement sensible aux mises à jour du vendredi car c’est son jour le plus chargé de la semaine, pouvez-vous tout aussi bien reporter les mises à jour au lundi sans que cela ait d’incidence sur votre solution ?

Il peut être judicieux de déployer les mises à jour locataire par locataire en recourant à l’une des approches décrites ci-dessous. Prévenez votre client des mises à jour planifiées. Permettez aux clients de refuser la mise à jour temporairement, mais pas définitivement ; fixez une limite raisonnable au moment où vous exigerez l’application de la mise à jour.

Envisagez également de vous donner la possibilité de déployer des correctifs de sécurité, ou d’autres correctifs critiques, avec un préavis minimal ou nul. Assurez-vous que les locataires comprennent cette pratique et son importance pour la protection de leurs données.

Une autre approche consiste à autoriser les locataires à lancer leurs propres mises à jour, à un moment de leur choix. Là encore, vous devez indiquer une date limite au-delà de laquelle vous installerez la mise à jour en son nom.

Quoi que vous fassiez, assurez-vous de disposer d’un processus pour surveiller l’intégrité de vos locataires, en particulier avant et après l’application des mises à jour. Souvent, les incidents de production critiques (également appelés incidents de site actif) se produisent après les mises à jour du code ou de la configuration. Par conséquent, il est important d’effectuer une surveillance proactive et de répondre à tous les problèmes afin de conserver la confiance des clients. Pour plus d’informations sur la surveillance, veuillez consulter la section Recommandations pour la conception et la création d’un système de surveillance.

Communiquer avec vos clients

Une communication claire est essentielle pour gagner la confiance de vos clients. Il est important d’expliquer les avantages des mises à jour régulières, notamment les nouvelles fonctionnalités, les correctifs de bogues, la résolution des vulnérabilités de sécurité et les améliorations des performances. L’un des avantages d’une solution moderne hébergée dans le cloud est la livraison continue des fonctionnalités et des mises à jour.

Posez-vous les questions suivantes :

• Informerez-vous les clients des prochaines mises à jour ?
• Si vous le faites, demanderez-vous implicitement l’autorisation en fournissant un processus de refus, et quelles seront les limites du refus ?
• Disposez-vous d’une fenêtre de maintenance planifiée que vous utilisez lorsque vous appliquez des mises à jour ?
• Que se passe-t-il si vous avez une mise à jour d’urgence, comme un correctif de sécurité critique ? Pouvez-vous forcer l’application des mises à jour dans ces situations ?
• Si vous ne pouvez pas informer le client de manière proactive des mises à jour à venir, pouvez-vous fournir des notifications rétrospectives ? Par exemple, pouvez-vous mettre à jour une page de votre site web avec la liste des mises à jour que vous avez appliquées ?
• Combien de versions distinctes de votre système conserverez-vous en production ?

Communiquer avec l’équipe du support technique

Il est important que votre propre équipe de support ait une visibilité complète sur les mises à jour appliquées à l’infrastructure de chaque locataire. Les représentants du support technique doivent être en mesure de répondre aisément aux questions suivantes :

• Des mises à jour ont-elles été récemment appliquées à l’infrastructure d’un locataire ou à des composants partagés ?
• Quelle était la nature de ces mises à jour ?
• Quelle était la version précédente ?
• À quelle fréquence les mises à jour sont-elles appliquées à ce locataire ?

Si l’un de vos clients rencontre un problème en raison d’une mise à jour, vous devez vous assurer que votre équipe du support technique dispose des informations nécessaires pour comprendre ce qui a changé.

Stratégies de déploiement du support des mises à jour

Réfléchissez à la façon dont vous allez déployer les mises à jour de votre infrastructure. Cela est fortement influencé par le modèle de location que vous utilisez. Trois approches courantes pour le déploiement des mises à jour sont les empreintes de déploiement, les indicateurs de fonctionnalité et les anneaux de déploiement. Vous pouvez adopter ces approches indépendamment, ou les combiner pour répondre à des exigences plus complexes.

Dans tous les cas, assurez-vous de disposer d’une visibilité et de rapports suffisants afin de savoir sur quelle version de l’infrastructure, du logiciel ou de la fonctionnalité se trouve chaque locataire, vers quelle version il peut migrer, et toutes les données temporelles associées à ces états.

Modèle d’empreintes de déploiement

De nombreuses applications multilocataires conviennent parfaitement au modèle d’empreintes de déploiement, dans lequel vous déployez plusieurs exemplaires de votre application et d’autres composants. En fonction de vos exigences en matière d’isolation, vous pouvez déployer une empreinte pour chaque locataire ou des empreintes partagés qui exécutent les charges de travail de plusieurs locataires.

Les empreintes constituent un excellent moyen de fournir un isolement entre les locataires. Elles vous offrent également une certaine flexibilité pour votre processus de mise à jour, car vous pouvez déployer les mises à jour progressivement entre les empreintes sans affecter les autres.

Indicateurs de fonctionnalités

Les indicateurs de fonctionnalité vous permettent d’ajouter une fonctionnalité à votre solution, tout en exposant cette fonctionnalité uniquement à un sous-ensemble de vos clients ou locataires.

Envisagez d’utiliser des indicateurs de fonctionnalité si l’une de ces situations s’applique :

• Vous déployez régulièrement des mises à jour, mais vous souhaitez éviter d’exposer de nouvelles fonctionnalités tant qu’elles ne sont pas entièrement implémentées.
• Vous souhaitez éviter d’appliquer des modifications de comportement avant qu’un client ne les ait acceptées.

Vous pouvez intégrer le support des indicateurs de fonctionnalités dans votre application en écrivant vous-même le code ou en utilisant un service tel que Azure App Configuration.

Anneaux de déploiement

Les anneaux de déploiement vous permettent de déployer progressivement des mises à jour sur un ensemble de locataires ou d’empreintes de déploiement. Vous pouvez affecter un sous-ensemble de locataires à chaque anneau.

Vous pouvez déterminer le nombre d’anneaux à créer et ce que chaque anneau signifie pour votre propre solution. En règle générale, les organisations utilisent les anneaux suivants :

• Canary : Un anneau Canary comprend vos propres locataires de test et les clients qui souhaitent recevoir des mises à jour dès qu’elles sont disponibles, étant entendu qu’ils peuvent recevoir des mises à jour plus fréquentes et que ces mises à jour peuvent ne pas avoir été soumises à un processus de validation aussi complet que dans les autres cas.
• Utilisateurs précoces : Un anneau d’utilisateurs précoces inclut des locataires qui sont légèrement plus vulnérables au risque, mais qui sont toujours prêts à recevoir des mises à jour régulières.
• Utilisateurs : La plupart de vos locataires appartiendront à l’anneau des utilisateurs, qui reçoit des mises à jour moins fréquentes et plus testées.

Versions d’API

Si votre service expose une API externe, tenez compte du fait que toute mise à jour que vous appliquez peut affecter l’intégration des clients ou des à votre plateforme. En particulier, vous devez être conscient des changements cassants apportés à vos API. Envisagez d’utiliser une stratégie de contrôle de version des API afin d’atténuer le risque de mises à jour de votre API.

Contributeurs

Cet article est géré par Microsoft. Il a été écrit à l’origine par les contributeurs suivants.

Auteur principal :

• John Downs | Ingénieur logiciel principal

Autres contributeurs :

• Chad Kittel | Ingénieur logiciel principal
• Daniel Scott-Raynsford | Stratégiste de la technologie partenaire
• Arsen Vladimirskiy | Ingénieur client principal, FastTrack for Azure

Pour afficher les profils LinkedIn non publics, connectez-vous à LinkedIn.

Étape suivante

Envisagez à quel moment vous mapperiez des demandes à des locataires dans une solution multilocataire.