Partager via

Considérations relatives au cycle de vie d’un locataire dans une solution multilocataire

  • Article

Lorsque vous envisagez une architecture multilocataire, il est important de prendre en compte les différentes étapes du cycle de vie d’un locataire. Dans cette page, nous fournissons des conseils pour les décideurs techniques sur les phases du cycle de vie et les points importants à prendre en compte pour chaque phase.

Locataires d’évaluation gratuite

Lorsque vous créez une solution SaaS, il faut savoir que de nombreux clients demandent ou exigent des évaluations gratuites avant de s’engager à acheter une solution.

Les versions d’évaluation gratuite impliquent les considérations suivantes :

  • Exigences de service : Les évaluations doivent-elles être soumises aux mêmes exigences en matière de sécurité des données, de performances et de niveau de service que les données pour les clients complets ?
  • Infrastructure : Devez-vous utiliser la même infrastructure pour les locataires d’évaluation que pour les clients complets, ou devez-vous avoir une infrastructure dédiée pour les locataires d’évaluation ?
  • Migration : Si les clients achètent votre service après une évaluation, comment migrer les données de leurs locataires d’évaluation vers leurs locataires payants ?
  • Processus de demande : Y a-t-il des limites quant aux personnes qui peuvent demander une évaluation ? Comment pouvez-vous empêcher les abus de votre solution ? Autorisez-vous la création automatisée de locataires d’évaluation, ou votre équipe participe-t-elle à chaque demande ?
  • Limites : Quelles limites voulez-vous ou devez-vous imposer aux clients en période d’évaluation, comme des limites de temps, des restrictions de fonctionnalités ou des limitations de performances ?

Dans certaines situations, un modèle de tarification freemium peut être une alternative aux versions d’évaluation.

Intégration de nouveaux locataires

Lors de l’intégration d’un nouveau locataire, tenez compte des éléments suivants :

  • Processus : L’intégration sera-t-elle un processus en libre-service, automatisé ou manuel ?
  • Résidence des données : Le locataire a-t-il des exigences spécifiques en matière de résidence des données ? Par exemple, existe-t-il des réglementations en matière de souveraineté des données en vigueur ?
  • Conformité : Le locataire doit-il respecter des normes de conformité (par exemple PCI DSS, HIPAA, etc.) ?
  • Reprise d’activité après sinistre : Le locataire a-t-il des exigences spécifiques en matière de reprise d’activité, telles qu’un objectif de temps de récupération (RTO) ou un objectif de point de récupération (RPO) ? Sont-elles différentes des garanties que vous fournissez à d’autres locataires ?
  • Informations : Quelles sont les informations dont vous avez besoin pour intégrer entièrement le locataire ? Par exemple, avez-vous besoin de connaître le nom légal de son organisation ? Avez-vous besoin du logo de l’entreprise pour personnaliser l’application, et si c’est le cas, de quelle taille de fichier et de quel format avez-vous besoin ?
  • Facturation : La plateforme fournit-elle des options de tarification et des modèles de facturation différents ?
  • Environnements : Le locataire a-t-il besoin d’environnements de pré-production ? Et existe-t-il des attentes sur la disponibilité de cet environnement ? Est-il temporaire (à la demande) ou toujours disponible ?

Une fois intégrés, les locataires passent à l’état « business as usual ». Cependant, plusieurs événements importants du cycle de vie peuvent encore se produire même lorsque les locataires sont dans cet état.

Mettre à jour l’infrastructure des locataires

Vous devez réfléchir à la façon dont vous appliquez les mises à jour à l’infrastructure de vos locataires. Les mises à jour peuvent être appliquées à des moments différents selon les locataires.

Consultez Mises à jour pour d’autres éléments de réflexion sur la mise à jour des déploiements de locataires.

Mettre à l’échelle l’infrastructure des locataires

Tenez compte du fait que vos locataires peuvent avoir des activités saisonnières ou changer le niveau de consommation de votre solution.

Par exemple, si vous fournissez une solution aux détaillants, vous vous attendez à ce que certaines périodes de l’année soient particulièrement chargées dans certaines régions géographiques, et calmes à d’autres moments. Déterminez si cette saisonnalité affecte la façon dont vous concevez et mettez à l’échelle votre solution. Soyez conscient de la façon dont la saisonnalité peut affecter les problèmes de voisinage bruyant, par exemple lorsqu’un sous-ensemble de locataires rencontre une augmentation soudaine et inattendue de la charge qui réduit les performances d’autres locataires. Vous pouvez envisager d’appliquer des mesures d’atténuation, qui peuvent inclure la mise à l’échelle de l’infrastructure des locataires individuels, le déplacement des locataires entre les déploiements et la fourniture d’un niveau de capacité suffisant pour gérer les pics et les creux de trafic.

Déplacer des locataires au sein de l’infrastructure

Vous pouvez avoir besoin de déplacer des locataires au sein de l’infrastructure pour un certain nombre de raisons, notamment les suivantes :

  • Rééquilibrage : Vous suivez une approche partitionnée verticalement pour mapper vos locataires à l’infrastructure, et vous devez déplacer un locataire vers un autre déploiement afin de rééquilibrer votre charge.
  • Mises à niveau : Un locataire met à niveau sa référence SKU ou son niveau tarifaire, et il doit être déplacé vers un déploiement dédié à locataire unique, avec une plus grande isolation des autres locataires.
  • Migrations : Un locataire demande que ses données soient déplacées vers un magasin de données dédié.
  • Déplacement de région : Un locataire exige que ses données soient déplacées vers une nouvelle région géographique. Cela peut se produire lors d’une acquisition d’entreprise, ou lors de changements législatifs ou géopolitiques.

Réfléchissez à la manière dont vous déplacez les données de vos locataires, ainsi qu’à la manière dont vous redirigez les requêtes vers le nouvel ensemble d’infrastructures qui héberge leur instance. Vous devez également vous demander si le déplacement d’un locataire entraînera un temps d’arrêt, et veiller à ce que les locataires soient pleinement conscients du risque.

Fusionner et fractionner les locataires

Il est tentant de considérer les locataires ou les clients comme des entités statiques et immuables. Toutefois, dans la réalité, ce n’est souvent pas le cas. Par exemple :

  • Dans les scénarios d’entreprise, les sociétés peuvent être acquises ou fusionnées, notamment les sociétés situées dans des régions géographiques différentes.
  • De même, dans les scénarios d’entreprise, les sociétés peuvent se scinder ou se désinvestir.
  • Dans les scénarios grand public, les utilisateurs individuels peuvent se joindre à des familles ou les quitter.

Déterminez si vous devez fournir des fonctionnalités permettant de gérer la fusion et la séparation des données, des identités des utilisateurs et des ressources. En outre, réfléchissez à la façon dont la propriété des données affecte votre gestion des opérations de fusion et de fractionnement. Prenons l’exemple d’une application de photographie grand public conçue pour permettre aux familles de partager des photos entre elles. Les photos sont-elles la propriété des membres individuels de la famille qui les ont fournies ou de la famille dans son ensemble ? Si des utilisateurs quittent la famille, leurs données doivent-elles être supprimées ou rester dans le jeu de données de la famille ? Si des utilisateurs rejoignent une autre famille, les anciennes photos doivent-elles être déplacées ?

Retirer des abonnés

Il est également inévitable que des locataires doivent parfois être retirés de votre solution. Dans une solution multilocataire, cela entraîne des considérations importantes, notamment les suivantes :

  • Période de rétention : Quelle doit être la durée de conservation des données client ? Existe-t-il des obligations légales de destruction des données après une certaine période ?
  • Réintégration : Devez-vous proposer aux clients la capacité à être réintégrés ?
  • Ré-équilibrage : Si vous exécutez une infrastructure partagée, avez-vous besoin de rééquilibrer l’allocation des locataires à l’infrastructure ?

Désactiver et réactiver des abonnés

Dans certaines situations, il peut être nécessaire de désactiver ou de réactiver le compte d’un client. Par exemple :

  • Le client a demandé une désactivation. Dans un système de contrôle serveur consommateur, un client peut choisir de se désabonner.
  • Le client ne peut pas être facturé et vous devez désactiver l’abonnement.

La désactivation est distincte du retrait dans le sens où s’agit d’un état temporaire. Toutefois, au bout d’un certain temps, vous pouvez décider de retirer un abonné désactivé.

Contributeurs

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

Auteur principal :

  • John Downs | Ingénieur client principal, FastTrack for Azure

Autres contributeurs :

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

Étapes suivantes

Tenez compte des modèles de tarification que vous allez utiliser pour votre solution.