Qu’est-ce que l’hébergement multiclient et quel est son impact sur les applications SaaS ? –
L’architecture mutualisée décrit une architecture logicielle dans laquelle une seule installation physique peut fournir plusieurs installations logiques. Chaque installation logique dessert une base d’utilisateurs dédiée appelée « locataire ».
La multi-location est le plus souvent observée dans le contexte des services cloud SaaS. Les organisations qui s’inscrivent à un service deviennent des « locataires ». Le locataire encapsule la configuration au niveau de l’organisation et prend généralement en charge plusieurs comptes d’utilisateurs finaux. Lorsqu’un utilisateur se connecte, il voit la vue personnalisée du service de son organisation.
Sommaire
Pourquoi utiliser la multi-location ?
La principale alternative à la multi-location est la location unique. Dans ce modèle, chaque locataire reçoit sa propre installation autonome du système. En pratique, cela signifie qu’une infrastructure de serveur dédié doit être configurée pour chaque locataire.
La multi-location existe uniquement au sein de votre application. Chaque locataire partage la même infrastructure de serveur. Cela simplifie la configuration de nouveaux locataires car vous n’avez pas besoin de provisionner de ressources supplémentaires. Les coûts d’exploitation d’un service multi-locataire peuvent donc être inférieurs à ceux d’une implémentation comparable à un seul locataire.
Une infrastructure partagée signifie également une plus grande efficacité opérationnelle. Il se peut que vous ayez un locataire qui utilise le service peu fréquemment. Avec une plate-forme à locataire unique, vous auriez toujours à provisionner une installation dédiée, même si elle resterait inactive la plupart du temps.
Avec une architecture multi-locataires, vous gérez un ensemble de systèmes. Vous pouvez anticiper la charge globale globale et n’avez pas besoin de garder les systèmes parqués au cas où un locataire se connecterait. Les ressources sont réparties entre les utilisateurs actifs. Le revers de la médaille est qu’un locataire particulièrement occupé pourrait avoir un impact négatif sur les autres, entraînant des problèmes de performances.
La multi-location peut être beaucoup plus facile à maintenir au fil du temps. Vous disposez d’une installation de votre service, ce qui signifie un ensemble de migrations. La multilocation s’harmonise bien avec les flux de travail de développement de logiciels modernes entraînés par une intégration continue et des déploiements rapides. L’itération sur un système à locataire unique signifie que vous devez créer des scripts d’orchestration pour mettre à niveau tous vos environnements de locataire individuellement.
Encore une fois, il y a deux côtés à cela : la location unique présente un avantage significatif lorsque vous souhaitez un déploiement progressif. L’isolement par locataire simplifie les versions incrémentielles où seule une minorité de votre base d’utilisateurs voit une nouvelle fonctionnalité dès le premier jour.
La location unique vous aide également à répondre aux demandes individuelles des clients. Un locataire peut souhaiter rester un peu plus longtemps sur une ancienne version de la plate-forme, ce qui donne à ses utilisateurs plus de temps pour se préparer au changement. Il n’est pas nécessaire que tout le monde déménage ensemble lorsque les locataires peuvent être migrés individuellement.
L’architecture mutualisée fonctionne mieux lorsque chaque organisation a les mêmes exigences générales. Dans ce scénario, tous les locataires bénéficient de chaque modification apportée. Le fournisseur bénéficie d’un délai de lancement réduit et d’une efficacité opérationnelle améliorée, mais perd un certain degré d’isolement des locataires.
Inconvénients de la multi-location
Outre les problèmes décrits ci-dessus, l’hébergement mutualisé introduit des considérations importantes dans chaque application. En tête de liste se trouve la sécurité, qui pourrait être plus facilement compromise dans un service multi-locataire.
La location unique vous permet de mettre des protections solides autour des données de chaque locataire. Dans un environnement multi-locataire, les données de tout le monde existeront au sein de la même infrastructure. Cela signifie qu’un attaquant peut cibler un emplacement centralisé.
La multi-location peut être plus exigeante pour les développeurs. Chaque opération au sein de votre service doit être étendue manuellement au locataire actif. Les tables de base de données stockant les ressources hébergées devront inclure un tenant_id ou similaire, permettant à chaque enregistrement d’être lié à son locataire.
Dans une application à locataire unique, où chaque locataire obtient sa propre installation autonome, la requête de base de données suivante peut être acceptable :
SELECT * FROM orders;Dans un environnement multi-locataire, vous devrez ajuster cela :
SELECT * FROM orders WHERE tenant_id = 1;Une seule requête de base de données défectueuse pourrait divulguer les informations sensibles de vos autres locataires.
La sauvegarde d’un service multi-locataire est généralement simple. Vous n’avez qu’une seule installation d’application à gérer. Cependant, des défis surviennent dans la restauration. Il est plus difficile de restaurer de manière sélective les données d’un locataire, car toutes les données existent dans un seul vidage. Fournir à un locataire son archive de données soulève des préoccupations similaires : vous aurez besoin d’un mécanisme personnalisé pour extraire ses enregistrements de l’infrastructure partagée.
Location hybride ?
Certaines applications évoluent vers la « location hybride ». Ce concept allie le meilleur des deux modèles. La location hybride s’harmonise bien avec les systèmes construits à l’aide de microservices. Certains services seront à locataire unique tandis que d’autres utiliseront une forme de multi-location.
Cela peut vous aider à améliorer encore l’efficacité de votre architecture. Vous souhaiterez peut-être une approche mutualisée des fonctions globales, telles que l’authentification et les intégrations tierces. Les données générées par les utilisateurs de votre service pourraient ensuite être stockées séparément, à l’aide de plusieurs instances d’un service à locataire unique.
L’utilisation d’une combinaison de services à locataire unique et à locataires multiples vous offre plus de flexibilité. Vous pouvez accélérer le lancement de nouvelles fonctionnalités en utilisant l’approche qui fonctionne le mieux pour chacune d’entre elles. La location hybride peut offrir une plus grande valeur globale en offrant un équilibre plus optimal entre la facilité de développement, la sécurité, le coût et la maintenance.
Il y a des points de friction, en particulier autour de la complexité et de la distribution. Séparer artificiellement votre application en services autonomes à locataire unique et à locataires multiples n’est pas la bonne façon d’aborder la location hybride. Il a tendance à mieux fonctionner dans les systèmes qui possèdent déjà des composants clairement distincts destinés à l’utilisateur.
Accès locataire
Votre service devra probablement stocker des données globales qui n’appartiennent à aucun locataire en particulier. La liste des locataires enregistrés en est un exemple.
Dans un système à locataire unique, vous pourriez avoir une installation dédiée de « superutilisateur » de votre service. Avec une approche multi-locataire, vous pouvez simplement avoir un tenants table dans votre base de données.
Lorsqu’un utilisateur accède à votre service, vous devez savoir à quel locataire il appartient. Un moyen courant d’identifier les locataires est la détection de sous-domaine :
tenant1.example.com tenant2.example.com
Certains sites utilisent des chemins d’URL (example.com/tenant1) ou laisser les locataires apporter leur propre nom de domaine. D’autres exposeront un point d’entrée unique (example.com), puis définissez des cookies d’identification de locataire ou des en-têtes HTTP après la connexion d’un utilisateur.
Vous devez également gérer les utilisateurs qui appartiennent à plusieurs locataires. De nombreux services vous permettent désormais de vous connecter avec des identifiants partagés. Les enregistrements d’utilisateurs sont stockés globalement – en dehors du système hébergé – et sont liés aux locataires par des relations de base de données. Cela ne sera pas toujours approprié pour votre système : si vous fournissez des sous-domaines dédiés ou si vous prenez en charge des domaines fournis par le locataire, il peut être indésirable de laisser l’utilisateur « changer d’organisation ».
Résumé
La « location » fait référence à la façon dont une application gère les données de plusieurs bases d’utilisateurs distinctes. Chaque locataire dispose de son propre environnement d’exploitation ; comment cela est provisionné dépend du modèle de location.
Les services à locataire unique sont simples mais inefficaces. Les services multi-locataires minimisent les besoins de maintenance mais nécessitent plus de réflexion sur la conception. La location hybride est un modèle émergent qui utilise des microservices pour combiner les deux approches.
Il n’y a pas de règle incontournable pour vous aider à déterminer l’approche à utiliser. Évaluez les performances de chaque modèle sur les attributs qui comptent le plus pour vous. Si vous recherchez une isolation renforcée et que vous souhaitez personnaliser considérablement votre service par locataire, la location unique peut être la meilleure solution. À l’inverse, si vous savez que vous aurez un grand nombre de locataires, optez pour la multi-location mais gardez la sécurité au premier plan de votre esprit.
