Pourquoi choisir une architecture multi tenant ?

S’il existe différents types de cloud (public, privé, hybride), on distingue également plusieurs catégories d’architectures, dont le multi-tenant fait partie.

Pour le comprendre, il faut d’abord définir le terme “tenant”, que l’on peut traduire par “locataire” en français. Dans la plupart des cas, ce locataire est un client (une entreprise) composé de plusieurs utilisateurs (les collaborateurs).

Ainsi, dans une infrastructure multi-tenant (ou multi-tiers), une même instance d’une application logicielle est utilisée par plusieurs clients isolés les uns des autres. Les logiciels dotés d’une telle architecture disposent d’une installation technique unique, partagée par tous les utilisateurs.

Le mode multi-tenant est caractéristique des applications SaaS, par opposition au modèle on-premise, dans lequel chaque entreprise installe sa version du logiciel sur son serveur. Il se distingue aussi de l’architecture single-tenant, où chaque client est l’unique utilisateur de son logiciel et dispose de sa propre base de données et de son propre serveur d’application.

L’isolation des données et des environnements d’exécution y joue un rôle clé. À ce titre, plusieurs approches sont possibles pour séparer les données des différents locataires.

Cette approche consiste à stocker les données des clients dans des bases de données différentes. Elle simplifie l’extension du modèle de données de l’application pour répondre à des besoins spécifiques, offre un niveau de sécurité élevé et permet une restauration rapide de la data d’un “tenant” en cas de panne.

Ici, plusieurs locataires sont hébergés dans une même base de données. Chacun d’entre eux possède un ensemble de tables, regroupées dans un schéma créé spécifiquement pour le client.

Flexible et facile à mettre en œuvre, cette approche offre toutefois des garanties de sécurité moins élevées, car le système n’est pas complètement isolé. De plus, la restauration des données d’un locataire peut s’avérer plus complexe qu’avec des bases de données distinctes.

Dans cette approche, tous les clients utilisent la même base de données et le même schéma. Elle génère plusieurs contraintes supplémentaires : risque de bugs liés au chevauchement des enregistrements, coûts de test plus élevés, baisse de performance dû à l’hébergement de tous les enregistrements dans une même table…

De manière générale, le modèle multi-tenant offre plusieurs avantages vis-à-vis des autres types d’architectures.

Ce modèle simplifie l’ajout de nouveaux clients et réduit le travail manuel nécessaire à la mise en place de la solution. Cela se traduit par une augmentation non négligeable du time-to-value, c’est-à-dire la rapidité avec laquelle les clients peuvent bénéficier de la valeur apportée par l’application.

L’usage d’une infrastructure commune se traduit par une baisse des coûts, car les ressources sont partagées entre les différents clients. C’est pourquoi les tarifs des solutions SaaS multi-tenant sont généralement plus attractifs.

De plus, l’architecture multi-tiers permet de réduire le coût total de possession : un utilisateur supplémentaire ne coûte rien ou presque. À l’inverse, dans un système single-tenant, l’ajout d’un nouveau client représente souvent un coût très élevé, qui comprend l’acquisition du nouveau matériel, mais aussi les frais liés à l’installation, à la configuration, à la maintenance ou encore aux mises à niveau.

Une application multi-tenant est beaucoup plus pratique et rapide à maintenir, puisqu’elle repose sur une infrastructure unique. Lorsqu’une modification est apportée à un fichier, elle profite immédiatement à tous les clients. En outre, l’éditeur peut gérer efficacement de nombreux clients à partir d’une seule interface.

En cas de montée en charge, une architecture multi-tenant permet d’allouer facilement des ressources supplémentaires à une application en cours d’exécution.

Autrement dit, si un logiciel nécessite un certain nombre de serveurs pour gérer une charge supplémentaire et que l’utilisateur fait face à un pic de trafic, il est possible d’ajouter plus de capacités en quelques secondes seulement.

L’architecture multi-tenant simplifie considérablement le processus de mise à jour.

En effet, puisqu’elle repose sur une infrastructure unique, les mises à jour sont moins contraignantes et peuvent être effectuées plus régulièrement. Il suffit de les appliquer une seule fois pour que l’ensemble des utilisateurs en profite.

À chaque changement de version, le logiciel est automatiquement modifié. Les clients n’ont donc pas besoin de réaliser une mise à jour longue et fastidieuse sur leur propre serveur.

Enfin, les logiciels dotés d’une architecture multi-tenant facilitent l’utilisation d’outils d’analyse, tels que les tableaux de bord et les rapports, pour l’ensemble des clients.

Le multi-tenant ne doit pas être confondu avec l’architecture multi-instance, dans laquelle chaque client exécute sa propre instance de l’application, avec sa propre base de données.

Elle garantit une isolation totale des données client, car chaque locataire peut accéder à sa data séparément des autres. Cela se traduit par un haut niveau de sécurité et de confidentialité pour les entreprises utilisatrices. La disponibilité globale de l’infrastructure est également très élevée : en cas de panne d’une instance, le problème n’affectera qu’un seul client.

De plus, ce modèle permet d’augmenter rapidement les ressources d’un client, car seule son infrastructure doit être modifiée. Il est donc possible de lui allouer des capacités supplémentaires en fonction de ses besoins, avec une mise à l’échelle simplifiée. Les possibilités de personnalisation, avec, par exemple, l’ajout de fonctionnalités dédiées, sont aussi très nombreuses.

Néanmoins, l’architecture multi-instance est plus complexe à déployer et à maintenir, étant donné que chaque client possède sa propre infrastructure dédiée. Chacune d’entre elles doit être déployée, maintenue et mise à jour séparément. En comparaison, la mise en place d’une architecture multi-tenant est bien plus aisée.

Enfin, le multi-instance génère des coûts plus élevés, car ils ne sont pas partagés. Ainsi, la création et la configuration d’une application ou d’une base de données s’avèrent moins rentables.