Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Redéfinir la mutualisation

Les termes « multi-tenancy » et « SaaS » sont souvent étroitement liés. Dans certains cas, les organisations décrivent le SaaS et la mutualisation comme une seule et même chose. Bien que cela puisse sembler naturel, le fait d'assimiler le SaaS à la mutualisation tend à amener les équipes à adopter une vision purement technique du SaaS alors qu'en réalité, le SaaS est davantage un modèle commercial qu'une stratégie d'architecture.

Pour mieux comprendre ce concept, commençons par la vision classique de la mutualisation. Dans cette vision purement axée sur l'infrastructure, la mutualisation est utilisée pour décrire la manière dont les ressources sont partagées par les locataires afin de promouvoir l'agilité et la rentabilité.

Supposons, par exemple, que vous disposiez d'un microservice ou d'une instance Amazon Elastic Compute Cloud (Amazon EC2) utilisée par plusieurs locataires de votre système SaaS. Ce service serait considéré comme fonctionnant dans un modèle multi-tenant, car les locataires partagent l'utilisation de l'infrastructure qui exécute ce service.

Le défi de cette définition est qu'elle associe trop directement la notion technique de mutualisation au SaaS. Cela suppose que la caractéristique déterminante du SaaS est qu'il doit disposer d'une infrastructure partagée et mutualisée. Cette vision du SaaS commence à s'effondrer lorsque nous examinons les différentes manières dont le SaaS est réalisé dans différents environnements.

Le schéma suivant donne une vue d'un système SaaS qui expose certains des défis que pose la définition de la mutualisation.

Vous découvrirez ici le modèle SaaS classique décrit précédemment, avec une série de services applicatifs entourés de services partagés qui vous permettent de gérer et d'exploiter vos locataires collectivement.

Ce qui est nouveau, ce sont les microservices que nous avons inclus. Le diagramme inclut trois exemples de microservices : produit, commande et catalogue. Si vous examinez attentivement le modèle de location de chacun de ces services, vous remarquerez qu'ils utilisent tous des modèles de location légèrement différents.

Le service produit partage toutes ses ressources (calcul et stockage) avec tous les locataires. Cela correspond à la définition classique de la mutualisation. Toutefois, si vous examinez le service de commande, vous constaterez qu'il dispose d'un calcul partagé, mais d'un stockage distinct pour chaque locataire.

Le service de catalogue ajoute une autre variante dans laquelle le calcul est distinct pour chaque locataire (déploiement de microservices distinct pour chaque locataire), mais partage le stockage pour tous les locataires.

Des variations de cette nature sont courantes dans les environnements SaaS. Voisin bruyant, modèles de hiérarchisation, besoins d'isolation : voici quelques-unes des raisons pour lesquelles vous pourriez partager ou cloisonner certaines parties de votre solution SaaS de manière sélective.

Compte tenu de ces variations, et de nombreuses autres possibilités, il devient de plus en plus difficile de déterminer comment utiliser le terme « multi-locataire » pour caractériser cet environnement. Dans l'ensemble, en ce qui concerne le client, il s'agit d'un environnement à locataires multiples. Cependant, si nous utilisons la définition la plus technique, certaines parties de cet environnement sont mutualisées et d'autres ne le sont pas.

C'est pourquoi il devient nécessaire de ne plus utiliser le terme « multi-tenant » pour caractériser les environnements SaaS. Nous pouvons plutôt parler de la manière dont la mutualisation est mise en œuvre au sein de votre application, mais évitez de l'utiliser pour qualifier une solution de SaaS. Si le terme multi-tenant doit être utilisé, il est plus logique de l'utiliser pour décrire l'ensemble de l'environnement SaaS comme étant multi-tenant, sachant que certaines parties de l'architecture peuvent être partagées et d'autres non. Dans l'ensemble, vous exploitez et gérez toujours cet environnement dans le cadre d'un modèle multi-tenant.

Le cas extrême

Pour mieux mettre en évidence cette notion de location, examinons un modèle SaaS dans lequel les locataires ne partagent aucune ressource. Le schéma suivant fournit un exemple d'environnement SaaS utilisé par certains fournisseurs de SaaS.

Dans ce schéma, vous verrez que nous avons toujours notre environnement commun autour de ces locataires. Cependant, chaque locataire est déployé avec un ensemble de ressources dédié. Rien n'est partagé par les locataires dans ce modèle.

Cet exemple remet en question ce que signifie être multilocataire. S'agit-il d'un environnement mutualisé même si aucune des ressources n'est partagée ? Les locataires qui utilisent ce système ont les mêmes attentes que vous pourriez avoir à l'égard d'un environnement SaaS avec des ressources partagées. En fait, ils n'ont peut-être aucune idée de la manière dont leurs ressources sont déployées dans le cadre de l'environnement SaaS.

Même si ces locataires fonctionnent dans une infrastructure cloisonnée, ils sont toujours gérés et exploités collectivement. Ils partagent une expérience unifiée en matière d'intégration, d'identité, de statistiques, de facturation et d'exploitation. De plus, lorsqu'une nouvelle version est publiée, elle est déployée sur tous les locataires. Pour que cela fonctionne, vous ne pouvez pas autoriser une personnalisation ponctuelle pour des locataires individuels.

Cet exemple extrême fournit un bon modèle pour tester la notion de SaaS à locataires multiples. Même s'il ne permet pas de tirer pleinement parti de l'efficacité d'une infrastructure partagée, il s'agit d'un environnement SaaS multi-locataires entièrement valide. Pour certains clients, leur domaine peut imposer à certains clients ou à tous d'utiliser ce modèle. Cela ne signifie pas qu'ils ne sont pas des SaaS. S'ils utilisent ces services partagés et que tous les locataires utilisent la même version, cela reste conforme aux principes fondamentaux du SaaS.

Compte tenu de ces paramètres et de cette définition plus large du SaaS, vous pouvez constater la nécessité de faire évoluer l'utilisation du terme « multi-tenant ». Il est plus logique de désigner tout système SaaS géré et exploité collectivement comme un système multi-tenant. Vous pouvez ensuite utiliser une terminologie plus précise pour décrire la manière dont les ressources sont partagées ou dédiées dans le cadre de la mise en œuvre d'une solution SaaS.