Multi-instance VS multi-tenant: Qu'est-ce que c'est ? Comment ça fonctionne ?

Piqure de rappel : Qu'est-ce qu'un SaaS ?

Avant de plonger dans le vif du sujet, il est intéressant de rappeler ce qu'est une solution SaaS :

SaaS signifie Software as a Service (logiciel en tant que service en français). Il s'agit d'une méthode de distribution d'un logiciel qui implique généralement un modèle d'abonnement pour accéder à un produit, un outil ou un service.

À quelques exceptions près, ces logiciels sont hébergés dans le cloud et sont accessibles directement depuis un navigateur ou un appareil mobile ce qui augmente grandement l'accessibilité de ces derniers.

D'un point de vue de l'évolution des usages, pour pouvoir utiliser une application ou un logiciel, il était traditionnellement nécessaire de l'installer sur ses serveurs applicatifs. Pour cela, il fallait avoir un ou plusieurs collaborateur(s) dans son entreprise capable(s) de gérer toutes les couches, de la mise en réseau au maintien de l'application elle-même. Mais surtout, il était bien souvent nécessaire de posséder les infrastructures.

Sont ensuite arrivés les concepts d'hébergement IaaS (Infrastructure as a Service) et, un peu plus tard, PaaS (Plateform as a Service). Ces nouveaux modes de consommation des ressources informatiques ont permis d'apporter une couche d'abstraction et de simplification pour déployer et installer nos logiciels ou ceux de nos clients. C'est donc dans cette lignée de nouvelles méthodes de consommation de commodités informatiques que les SaaS ont vu le jour.

La problématique est alors simple : Permettre à mon client d'utiliser simplement mon logiciel.

Plus besoin de devoir l'installer, de gérer les mises à jour ou de maintenir l'infrastructure.

Architectures des solutions SaaS

Les solutions SaaS sont principalement construites sur deux types d'architectures :
Multi-instance d'un côté et multi-tenant de l'autre.
"Tenant" signifie locataire en anglais, c'est tout simplement l'équipe ou l'organisation de vos clients.

On ne les verra pas ici mais il existe aussi des architectures mono-instance, multi-instance avec base de données partagée ou encore flex tenancy qui sont un peu moins courantes.

L'objectif de cet article n'est pas de prendre le parti d'une architecture particulière car chaque architecture répond à des besoins différents. L'idée est donc de pouvoir comparer les deux types d'architecture pour vous permettre de choisir celle qui vous convient le mieux en fonction de vos problématiques et celles de vos clients.

À noter que le résultat ne sera pas très différent pour l'utilisateur final. En revanche, il variera grandement dans la conception de l'architecture du système, des données et de leurs accès ainsi que dans la configuration et la gestion des utilisateurs.

Penchons-nous donc sur les avantages et les inconvénients de chacune d'entre-elles en commençant par les architectures multi-instances :

Architecture multi-instance

Dans une architecture multi-instance, plusieurs entreprises exécuteront leur propre instance distincte de l'application, avec leur propre base de données. Chaque entreprise aura donc accès à ses données séparément d'une autre.

Ce type d'architecture permet d'apporter les avantages suivants :

• Isolation des données :
  Chaque organisation (ou équipe) dispose de sa propre base de données et de sa propre infrastructure. Ceci entraine une totale isolation des données et offre une garantie de confidentialité pour vos clients. Les pirates informatiques auront donc moins d'intérêt à attaquer votre système car récupérer les accès d'un petit segment de vos données totales les intéresseront moins.
• Scalabilité simplifiée (ou mise à l'échelle):
  Il est plus facile d'augmenter les ressources pour un client car seule son infrastructure sera à modifier. Nous pourrons donc lui allouer plus de CPU, de RAM ou de stockage en fonction de ses besoins.
• Augmentation de la disponibilité globale :
  Si une instance tombe en panne pour une raison ou une autre, ce problème n'affectera pas l'ensemble de vos clients.
• Personnalisation :
  Chacun de vos clients peut recevoir des personnalisations de votre SaaS (fonctionnalités dédiées, mise à jour planifiée, etc…) que vous pouvez facilement tourner en arguments commerciaux.

En revanche, aucune architecture n'étant parfaite, nous noterons quand même les points négatifs suivants :

• Plus compliqué à déployer et à maintenir :
  Vous l'aurez compris, chacun de vos clients ayant sa propre infrastructure dédiée, il faudra provisionner chacune des infrastructures, la maintenir et la mettre à jour séparément.
• Coût total plus élevé :
  Ce choix d'architecture est moins rentable lorsqu'il s'agit de créer et de configurer chaque environnement tels que la base de données ou l'application car les coûts ne sont pas partagés.

Architecture multi-tenant

Regardons maintenant un autre type d'architecture, le multi-tenant. Ici plusieurs entreprises utiliseront une seule instance de l'application (qui pourra évidement être répliquée si besoin), avec une base de données unique. Cette architecture ne donne pas beaucoup de flexibilité mais simplifie le processus d'ajout de fonctionnalités et de correction des bugs de code.

Avantages majeurs :

• Meilleure rentabilité.
  Utiliser la même infrastructure et les mêmes ressources vous coûtera moins cher car les ressources seront partagées entre vos différents clients.
• Simplicité lié à l’infrastructure partagée.
  Puisqu'il n’y a qu’une unique infrastructure elle est plus facile à maintenir.
• Gagnez du temps :
  Ce type d'architecture à l'avantage d'être plus simple à mettre en place qu'une architecture multi-instance. Il est donc plus facile de développer votre application SaaS et celle-ci nécessite moins de temps et de ressources pour la maintenir.
• Toujours "up-to-date" :
  Les mises à jour ne seront à effectuer qu'une seule fois pour que celles-ci profitent à l'ensemble de vos utilisateurs.

Inconvénients :

• Base de données partagée :
  Toute action affectant la base de données affectera tous les clients partagés.
  C’est donc au niveau de l’application que la séparation des données devra être faite et donc à l'équipe de développeurs de prévenir l'exposition des données d'un client à un autre, ce qui augmentera la complexité de la couche applicative.
• Toute violation de sécurité a un effet massif car elle affectera tous les utilisateurs du système.
• Moins personnalisable :
  Vous pourrez moins facilement personnaliser l'offre que vous proposerez à vos clients. Il est toujours possible de verrouiller certaines fonctionnalités dans le code de l'application mais encore une fois, ça pourra entrainer une complexité liée au développement.

Quelle architecture choisir ?

Vous avez maintenant les cartes en mains pour comprendre les différences entre les deux types d'architectures.

Pour résumer, de mon côté, si j'avais une problématique de "fast time-to-market" et besoin de développer rapidement une solution SaaS, je me pencherais plutôt sur une architecture multi-tenant car plus simple à mettre en place. En revanche si j'avais besoin de développer une solution plus robuste et plus sécurisée, j'opterais plutôt pour une architecture multi-instance et bénéficierais d'une isolation totale des données.

Pour aller plus loin, bâtissez votre architecture avec Kubernetes

Kubernetes a l'avantage de pouvoir vous permettre de batir aussi bien une architecture multi-instance que multi-tenant. Vous pourrez alors orchestrer plus facilement vos déploiements, vos mises à jour, répliquer ou même "auto-scaler" votre infrastructure. Chez Scaleway, nous avons développé une offre Kubernetes Managé: Kubernetes Kapsule.

Voyons quelques fonctionnalités incontournables :

• Provisionnement automatique:
  Pour une architecture multi-instances, les utilisateurs finaux demanderont en fin de compte le déploiement d'applications dans Kubernetes. Pour cela, vous devriez envisager d'intégrer votre application à l'API Kubernetes. Il n'est pas rare non plus de pré-provisionner des instances qui seront attribuées à vos clients au moment de la création du compte. Cela vous fera gagner les quelques minutes de provisionnement de l'infrastructure et rendra le parcours utilisateur plus agréable.

• Hostname personnalisable :
  Ces derniers temps, les utilisateurs finaux attachent leur domaine à des applications. Kubernetes a mis en place des outils pour rendre ce processus plus facile et même arriver au point où il devient libre-service (les utilisateurs pressant un bouton pour obtenir leur domaine pointant vers le pod qui leur est attribué). Vous pouvez utiliser les ingress controllers tel que Nginx Ingress pour accomplir cela.
• Scaling des nœuds automatiques :
  Lorsque vos nœuds deviennent pleins, vous aurez certainement besoin de provisionner plus de nœuds afin que vos applications puissent continuer à fonctionner sans ralentissement. Kubernetes Kapsule fournit une option pour vous permettre de scaler automatiquement vos noeuds.

• Scaling de l’application :
  Vous pourrez mettre votre application à l'échelle (vers le haut ou vers le bas) en fonction de l'utilisation. Kubernetes fournit cette fonction "out of the box" à l'aide de triggers qui mettent automatiquement à l'échelle les déploiements. Par exemple, en exécutant cette commande : kubectl autoscale deployment myapp --cpu-percent=70 --min=1 --max=10
  Cette commande définira le déploiement myapp pour qu'elle évolue jusqu'à 10 pods lorsque le pourcentage de CPU dépasse 70.
• Portabilité :
  Notre offre Kubernetes Kapsule est certifiée par la CNCF (Cloud Native Computing Foundation). Kubernetes Kapsule respecte donc les normes de la CNCF pour apporter sécurité, stabilité et robustesse. Cette garantie permet la conception d’applications et d’infrastructures hybrides et multicloud. Cela vous apporte aussi la garantie de pouvoir concevoir une architecture avec Kubernetes pour que celle-ci puisse fonctionner avec n'importe quelle offre Kubernetes managé présente sur le marché étant certifiée.

Kubernetes Kapsule est donc un excellent outil pour gérer votre infrastructure cloud. Si vous rencontrez des difficultés pour mettre à l'échelle votre application, envisagez de passer à une architecture basée sur Kubernetes. Vous constaterez une forte augmentation de la productivité de vos DevOps en matière de déploiements, de clustering et de stabilité globale.

Cet article est tiré du Webinar "Découvrez les avantages de Kubernetes pour héberger une solution SaaS", n'hésitez pas à le revoir sur Youtube :