En tant que fournisseur de solutions SaaS, certaines questions techniques ont un impact stratégique important sur votre métier. Celle de l’architecture multi-tenant ou single-tenant fait clairement partie de cette problématique. Le sujet est notamment de plus en plus d’actualité en raison de la popularité des infrastructures et autres plateformes à la demande disponibles chez les fournisseurs Cloud.
Dois-je fournir ma solution à travers des environnements dédiés pour chacun de mes clients ? Ou dois-je prendre la direction d’une plateforme plus importante mais pouvant accueillir l’ensemble de mes clients ?
Question simple, réponse complexe, engageante et stratégique pour votre business. Vous devrez choisir une direction et il ne sera pas simple d’en changer par la suite, à l’inverse de ce que vous avez l’habitude d’appliquer sur vos projets via les méthodes agiles ou DevOps.
Tout d’abord, sachez qu’il est fréquent de faire référence à “multi-instance” lorsque l’on souhaite évoquer le single-tenant puisque pour héberger l’ensemble de vos clients vous devrez posséder une multitude d’instances (le titre aurait pu être multi-instance VS multi-tenant). Pour information, “Tenant” signifie locataire, soit une métaphore supplémentaire (gateway, data lake, DMZ, etc) pour s’approprier ou vulgariser un sujet un peu abstrait.
L’application single-tenant fournit ses services à un seul client. Par conséquent, chaque client devra disposer de sa propre application, souvent dans un environnement dédié: chaque locataire dans sa propre maison. Vu comme ça, le schéma est idéal puisqu’il offre une séparation importante entre les applications. Le client est rassuré car il sait que ses données ne côtoient pas celles d’autres clients. Il possède sa propre base de données ainsi que son serveur d’application. D’ailleurs, dans ce schéma, en tant que fournisseur de solutions SaaS, vous disposez d’un contrôle plus simple sur l’activité de vos clients (nombre d’utilisateurs, charges, bande passante, etc). Voici les grandes caractéristiques de cette architecture :
Sécurité : Les informations de vos clients vivent chacune dans leur propre entrepôt de données. Les serveurs applicatifs respectent aussi cette isolation. Il n’y a, à priori, aucun risque pour que l’application remonte malencontreusement les informations d’un autre client. Il y a dans cette architecture une forte isolation qui peut aussi se retrouver à des couches plus basses telles que l’infrastructure réseaux. La réversibilité des données est aussi grandement simplifiée car vous pouvez facilement exporter la base de données de votre client. Le cas de la suppression d’un compte client est aussi une opération simple puisque cela correspond à supprimer un schéma de base de données et recycler un serveur d’application.
Flexibilité : L’application peut être personnalisée pour les besoins spécifiques d’un de vos clients. Cela passera d’une légère modification de l’interface graphique (logo du client) à des impacts plus lourds tel que la connexion à des services spécifiques du système d’information de votre client (autorité d’authentification, web services home made). En fait, il n’existe pas réellement de blocage autre que celui du coût de la mise en oeuvre de ces personnalisations. Elles seront à votre charge ou à celles du client en fonction du niveau de complexité et/ou de spécificité.
Scalabilité : L’amplitude de l’élasticité de votre infrastructure sera limitée et cela pour plusieurs raisons :
Scale down : Chaque environnement dédié à vos clients doit au moins posséder une instance pour répondre en cas de requête. Vous avez 50 clients alors vous serez obligé de disposer de 50 instances de l’application démarrées et ne pourrez pas descendre sous ce seuil. A ce chiffre, il faudra sûrement ajouter un facteur deux pour l’hébergement de la base de données.
Scale out : En ce qui concerne l’accroissement horizontal de votre application, vous serez là aussi confronté à une opération ne pouvant être optimisée. En effet, une instance ajoutée ne peut pas être partagée entre deux applications (à cause de l’isolation des instances).
Scale up : C’est vers cet axe d’accroissement vertical, c’est à dire la puissance des serveurs, que l’on aura tendance à se tourner, l’accroissement horizontal étant peu bénéfique.
Tarification : Elle sera réalisée de manière assez classique via un contrat engageant les deux parties à savoir entre le client et l’éditeur de la solution. Souvent sur des durées annuelles car ce genre d’architecture ne possède pas la souplesse suffisante pour être allouée puis désallouée rapidement. Vous pouvez donc quasiment mettre de côté un système de paiement en ligne vous donnant un accès immédiat à l’application sans engagement.
Infrastructure : Il vous faut disposer d’un outil d’orchestration pour réaliser les tâches de création d’une application pour un client. Cet outil invoquera un système de templating afin de monter rapidement l’environnement. C’est ce même système de templating qui vous permettra de créer rapidement une application de démonstration ou de validation. Il n’est pas envisageable de mettre en place une telle architecture sans outil d’automatisation ou vous serez contraint de compenser par une équipe “ops” beaucoup plus importante.
Comme on peut le constater, le principale avantage d’une architecture single-tenant est d’offrir un haut niveau d’isolation entre les données des différents clients de votre solution SaaS. Mais ce bénéfice se fera au détriment d’autres caractéristiques cruciales pour votre croissance. Plus votre solution rencontrera le succès, plus votre infrastructure sera lourde étant donné la multiplicité des environnements à créer puis à maintenir. Chaque nouveau client fera linéairement accroître la complexité de votre infrastructure ou tout du moins sa taille et par conséquent, toute la maintenance qui en découle. De plus, il vous faudra être extrêmement vigilant sur la politique d’évolution de votre produit sans laquelle vous ne pourrez pas conserver un “time to market” dynamique. En effet, le principal risque serait de multiplier les versions de votre produit à chaque fois qu’une personnalisation client y est faite. Vous mettriez ainsi le doigt dans un engrenage dans lequel il est difficile de faire demi-tour : les spécifiques.
L’architecture multi-tenant privilégie quant à elle la mutualisation des ressources. Si l’on reprend la métaphore des locataires, on les imaginera vivre chacun dans un appartement d’un même immeuble. Cette organisation présentant l’avantage de partager un certain nombre de ressources telles que l’électricité, le chauffage, etc. L’architecture multi-tenant fonctionne suivant le même principe, à savoir que tous vos clients bénéficieront de votre solution à travers une infrastructure commune. Reprenons les grandes caractéristiques de cette architecture :
Sécurité : Les données de tous vos clients se trouvant dans le même entrepôt, vous devrez faire preuve de la plus grande rigueur en ce qui concerne l’étanchéité du modèle de données. En clair, il ne faut pas que le client A puisse voir les données du client B. Tout le modèle de données c’est à dire la structure d’accueil des informations sera pensé pour être filtrable par un identifiant de client. Ce point est essentiel pour que votre application puisse être multi-tenant.
Flexibilité : L’application étant la même pour tous vos clients vous ne pourrez pas offrir autant de personnalisations que dans l’architecture single-tenant ou, en tout cas, moins en profondeur notamment sur le coeur des fonctionnalités telles que l’authentification. De plus, il vous faudra mettre en place des mécanismes afin de formaliser le processus d’ajout de nouvelles fonctionnalités. C’est l’occasion de mettre en place les fondations d’une marketplace qui proposera des plugins de personnalisation et d’ajout de fonctionnalités. Cette dernière représente un investissement plus important que l’écriture de fonctionnalités dans le coeur de votre application mais très précieux tant pour la popularité du produit (ouverture à des éditeurs tiers) que pour son industrialisation (packaging, testing unitaire).
Scalabilité : Idéalement pour la réalisation de cette architecture multi-tenant vous opterez pour une approche micro services. Vous éviterez clairement l’approche monolithique qui ne scale pas naturellement. Cette approche vous permettra de cibler avec précision les composants dont il faudra augmenter ou diminuer la puissance. Je ne cite ici que les avantages concernant la scalabilité mais sachez qu’ils sont nombreux et à tous les niveaux : technique et stratégie commerciale. N’envisagez pas de réaliser une application multi-tenant avec un framework monolithique. Vous rencontreriez très rapidement des limitations techniques et une lourdeur importante au niveau développement. Cette scalabilité sera aussi assurée par le choix d’une base de données aillant la capacité de scaler horizontalement. On aura par conséquence tendance à proscrire les RDBMS au profit de solutions NoSQL.
Tarification : La nature de l’architecture et sa flexibilité à croître en fonction du nombre de clients vous autorise la mise en place d’une souscription en ligne immédiate. Celle-ci se fera avec un engagement n’excédant pas le mois. Le multi-tenant offre ainsi une acquisition des clients plus rapide. Vous pourrez par exemple, autoriser une période d’essai de votre application, voire une offre gratuite pour une petite volumétrie d’utilisateurs.
Infrastructure : La mise en place d’un outil d’orchestration vous permettra d’avoir une meilleure gestion de tous les services qui composent votre application. Vous disposerez aussi d’un template décrivant l’infrastructure afin de pouvoir la reconstruire en n’importe quelle circonstance (démo, canary release, déploiement sur une autre région, etc).
L’architecture multi-tenant nécessite un investissement de départ plus important que son homologue single-tenant. Cela s’explique à travers la mise en oeuvre de mécanismes plus complexes tels qu’une marketplace, une architecture micro services ou tout du moins orientée services et offrant une forte décomposition des fonctionnalités. Elle est également critiquable sur l’aspect de la sécurité à travers ces données qui cohabitent toutes entre elles. Il sera nécessaire de redoubler de vigilance sur tous les processus de validation (tests unitaires, tests fonctionnels et audit sécurité) afin de garantir une séparation logique parfaite. Malgré ces efforts, vous ne pourrez pas préconiser cette architecture à des grands comptes pour lesquels le PAS (Plan Assurance Sécurité) n’autorise pas, pour les solutions SaaS, la cohabitation des données. Vous disposerez, par contre, de nombreux avantages par rapport à l’architecture single-tenant. Par exemple, un bénéfice considérable sera de centraliser l’information afin d’y effectuer de la data science sans obligatoirement y recopier les informations dans un data warehouse.
Comme vous l’avez sûrement compris, il y a un prix d’entrée dans l’architecture multi-tenant supérieur à celui de l’architecture single-tenant. Le graphique ci-dessous résume cet écart :
Le choix entre architecture multi-tenant et architecture single-tenant réside essentiellement dans la projection du nombre de clients que l’on espère pour son application SaaS. Si vous pensez qu’elle répond à un besoin de niche avec un nombre de clients très restreint alors il peut ne pas être pertinent de s’orienter vers l’architecture multi-tenant. Il vous faudra de toute façon passer par une simulation/projection afin de déterminer celle qui est la plus adaptée à votre capacité financière, votre objectif commercial et votre feuille de route (planning).
Une piste serait de partir vers une architecture multi-tenant que l’on déclinerait ensuite en single-tenant pour les clients importants. Il s’agirait “juste” de dupliquer l’architecture multi-tenant et de la dédier à un de vos clients. Il faut bien prendre conscience que l’application multi-tenant peut prendre place dans plusieurs infrastructures séparées. Par exemple, nous pourrions adopter le comportement en fonction du niveau de souscription. L’idée étant de pouvoir répondre à plusieurs catégories de clients, les petits et moyens dans une plateforme multi-tenant, et les grands comptes dans une application dédiée single tenant.
A la lecture de ces quelques lignes vous aurez bien compris l’enjeu entre ces deux types d’architectures et l’impact qu’elles ont sur la stratégie de développement de votre produit. J’aurai personnellement tendance à conseiller d’aller vers la direction de l’architecture multi-tenant que l’on peut ensuite décliner vers du single-tenant. Ou, comme me le souffle mon collègue @slemesle, nous pourrions aussi opter pour une approche single-tenant à base de conteneurs permettant de mutualiser les ressources. Au final, il existe une diversité de solutions pour exposer votre application SaaS, toutes avec leurs lots d’avantages, de bénéfices et répondant à différentes contraintes : techniques, financières et temporelles.
L’illustration utilisée dans le bandeau de cet article provient d’un des projets de l’architecte James Wines. Plus d’informations sur l’auteur et la démarche sur le site Web du MoMA, par exemple.