Plonger plus profondément dans la notion de "multi-location" et partager nos idées sur comment nous la percevons.
Nous entendons fréquemment parler de l'importance de créer une application multi-locataires, surtout dans le contexte du développement d'une application Software as a Service (SaaS).
Il y a une certaine confusion concernant le concept d'une "application multi-locataires" et les différents modèles utilisés pour en développer une. Dans cet article, nous avons examiné de plus près ces termes de manière plus pratique.
L'architecture à locataire unique est un modèle de logiciel ou de cloud computing où chaque client ou locataire dispose d'une instance dédiée d'une application ou d'un service. Si nous regardons l'origine du modèle commercial B2B, cela commence par chaque instance du logiciel ne servant qu'un seul client ou organisation.
L'architecture à locataire unique est couramment utilisée dans des scénarios où la conformité est primordiale ou nécessite des exigences de sécurité spécifiques. Par exemple, des industries comme la finance, la santé et le gouvernement, qui ont des exigences réglementaires strictes, privilégient souvent les solutions à locataire unique pour garantir la conformité.
Cependant, il est important de noter que les architectures à locataire unique peuvent être plus gourmandes en ressources et complexes à gérer par rapport aux architectures multi-locataires, car l'instance de chaque client nécessite sa propre infrastructure et sa propre maintenance. En conséquence, elles peuvent être plus adaptées aux applications avec moins de clients mais plus importants ou lorsque la personnalisation et l'isolation sont essentielles.
La multi-location logicielle est une architecture logicielle dans laquelle une seule instance de logiciel s'exécute sur un serveur et sert plusieurs locataires. Les systèmes conçus de cette manière sont "partagés" (plutôt que "dédiés" ou "isolés"). Un locataire est un groupe d'utilisateurs qui partagent un accès commun avec des privilèges spécifiques à l'instance logicielle. Avec une architecture multi-locataires, une application logicielle est conçue pour fournir à chaque locataire une part dédiée de l'instance - y compris ses données, sa configuration, sa gestion des utilisateurs, ses fonctionnalités individuelles de locataire et ses propriétés non fonctionnelles. -- Wikipédia
Nous avons fourni des définitions d'un point de vue architectural, ce qui permet de distinguer facilement les conceptions multi-locataires et à locataire unique. Cependant, cela penche davantage vers la définition technique. Si nous utilisons ces définitions dans notre environnement de développement réel lors de la conception de modèles de location, cette façon de penser suppose qu'une application multi-locataires doit avoir une infrastructure purement partagée et multi-locataires.
Cependant, les affaires et les produits varient beaucoup et ont de nombreuses exigences au cas par cas, il n'y a donc pas de solution unique pour tous.
Imaginez un scénario où un locataire utilise des ressources provenant d'une infrastructure partagée, mais en raison de besoins commerciaux spécifiques, il nécessite qu'une ou deux parties du système lui soient exclusivement dédiées. Ces parties dédiées pourraient être la base de données, les instances, ou une combinaison d'autres composants, tout en partageant l'infrastructure globale. C'est là qu'intervient l'architecture mixte.
Dans le développement pratique de produits SaaS, il est courant de rencontrer un scénario où un produit est principalement conçu avec un modèle de multi-location générique. Cependant, certains aspects de l'architecture ou des ressources peuvent être orientés vers une approche "locataire unique".
AWS a utilisé l'exemple suivant pour communiquer ce concept : la multi-location est un concept large, et c'est au cas par cas pour combiner et choisir la bonne stratégie pour définir ce que vous voulez réaliser à travers les ressources partagées et l'isolation des données.
En d'autres termes, parfois les gens appellent encore ce modèle "Multi-location", donc dans la définition plus large de la multi-location, cela n'implique pas que tous les composants d'une solution soient partagés. Au lieu de cela, cela implique qu'au moins certains composants d'une solution soient réutilisés par plusieurs locataires.
Comprendre ce terme de manière large peut mieux vous aider à comprendre les besoins de votre client et d'où il vient.
Plutôt que de se concentrer sur un seul modèle architectural, la multi-location reflète la praticité de l'architecture d'un produit SaaS dans le monde réel. Quand nous faisons référence à une application multi-locataires, cela ne signifie pas nécessairement que l'application adhère à un seul modèle architectural ; elle peut utiliser diverses stratégies de location, indiquant qu'au moins certains de ses composants sont partagés.
La question est alors, comment proposer la stratégie de location pour mon produit ? Voici quelques questions importantes à prendre en compte :
Souvenez-vous qu'il n'y a pas de division rigide dans votre produit où vous devez opter pour un modèle exclusivement multi-locataire ou uniquement locataire unique. Votre décision devrait être basée sur la façon dont vous divisez les composants architecturaux de votre produit et les niveaux d'isolation spécifiques requis par vos clients ou votre entreprise. Vous pouvez ensuite appliquer différentes approches en conséquence.
Nous avons parlé de la "nouvelle" définition d'une application multi-locataires, mais qu'en est-il de l'isolation des locataires, des identités, et comment déterminer si vos identités doivent être isolées ou non ? Que signifie pour les identités d'être "isolées" ?
La confusion survient souvent lorsqu'il s'agit de situations où un utilisateur réel a deux identités différentes. Est-il approprié de qualifier cette situation d'"identités isolées" ?
Nous aborderons ces questions dans notre prochaine série d'articles. Restez à l'écoute !