La multi-location est largement utilisée dans le cloud computing, en particulier c’est une fonctionnalité cruciale si nous parlons de solutions SaaS. L’idée derrière l’architecture multi-locataire est qu’un serveur logiciel, une base de données, un stockage ou un contrôleur de réseau peut être utilisé par plusieurs clients tandis que les données de chaque client sont cachées aux autres. La location unique est à l’opposé et signifie qu’une instance logicielle sert une application.
Avantages et inconvénients de la multi-location
L’avantage le plus évident et le plus important de la multi-location est de réduire les dépenses d’hébergement grâce à une utilisation maximale des ressources, mais cette architecture peut offrir d’autres avantages très importants à votre entreprise :
- Mise à l’échelle rapide et facile, qui permet d’allouer autant de ressources que nécessaire sans temps d’arrêt et sans nombreuses routines administratives.
- Haut niveau de protection contre les logiciels malveillants.
- Les mises à niveau et la maintenance des logiciels sont gérées par les fournisseurs SaaS.
- Coûts et temps réduits pour la gestion du matériel.
- Intégration facile avec des logiciels tiers grâce à l’utilisation d’API.
Comme inconvénient potentiel, il convient de mentionner les options de personnalisation limitées par rapport à l’architecture à locataire unique, certains problèmes de sécurité et de conformité et l’effet « voisin bruyant », qui peut se produire lorsque certains clients utilisent une quantité excessive de processeur et ralentissent les autres locataires. ‘ applications.
Pour résumer tous les points ci-dessus, l’architecture à locataire unique offre un niveau élevé de sécurité et de personnalisation et constitue un bon choix pour les grandes entreprises. La multi-location est un modèle plus rentable et hautement évolutif qui convient parfaitement à la plupart des entreprises.
Modèles SaaS multi-locataires
Les modèles SaaS multi-locataires les plus courants sont les suivants :
- Multilocation basée sur des conteneurs : en règle générale, dans un environnement conteneurisé, chaque donnée client (locataire) est isolée, mais un serveur d’application commun est partagé entre eux. Cependant, il est possible d’exécuter à la fois le serveur d’applications et la base de données dans le conteneur d’un locataire complètement isolé.
- Multilocation basée sur la virtualisation : un tel modèle est très proche du single-tenancy et offre un très haut niveau de sécurité et d’isolement car chaque client dispose de sa propre VM avec application et base de données. Malgré cela, il est utilisé de temps en temps en raison de sa faible évolutivité et de son coût élevé.
- Base de données par locataire : dans ce cas, chaque locataire a sa propre base de données. Seul le serveur d’applications est partagé et peut être mis à l’échelle verticalement ou horizontalement si nécessaire. Cette approche fonctionne bien pour plusieurs locataires, mais ne convient pas aux applications dont l’échelle est inconnue en raison du grand nombre de bases de données requises.
- Base de données multi-locataire unique : ce modèle est très populaire car il dispose d’un stockage unique pour tous les utilisateurs, qui peut être facilement étendu lorsque cela est nécessaire. Le principal inconvénient d’une telle approche est le risque élevé d’effet « voisin bruyant », qui a été évoqué plus haut.
- Bases de données mutualisées partagées : le modèle permet de stocker les données des locataires dans plusieurs bases de données. Les données des locataires sont divisées en un ensemble de segments (shards) et peu d’utilisateurs peuvent utiliser le même shard. Cependant, ce modèle garantit que les données d’un locataire particulier ne seront pas réparties entre plusieurs partitions. C’est une approche gagnant-gagnant pour créer une application hautement évolutive.
Points à considérer lors de la conception d’une application multi-locataire
Comme les utilisateurs partagent des ressources dans des environnements multi-locataires, leur sécurité et leur confidentialité doivent être assurées par les fournisseurs SaaS. Vous pouvez choisir entre les trois modèles d’isolation les plus couramment utilisés : isolations de silo, de pool, de pont et de niveau :
– Les fournisseurs Silo SaaS proposent des clusters isolés distincts pour chaque locataire. Cette approche est similaire à la location unique et nécessite des coûts supplémentaires d’infrastructure, de développement et de gestion, mais garantit un niveau élevé de protection de la vie privée.
– L’isolation de pool permet aux utilisateurs de partager la même infrastructure et fournit une mise à l’échelle efficace des ressources, mais présente des faiblesses en matière de sécurité.
– Le modèle de pont est un mélange d’isolements de silos et de pools, ayant des infrastructures partagées et isolées en même temps.
– L’isolement basé sur le niveau implique différents types d’isolement en fonction des plans d’abonnement, par exemple : les locataires du niveau gratuit utilisent une infrastructure partagée tandis que les locataires premium ont des environnements isolés.
- Consommation de ressources attendue
Analysez soigneusement le nombre de locataires que vous devez gérer, les coûts d’infrastructure par utilisateur, l’utilisation du stockage et du processeur, et les bénéfices attendus. De plus, gardez à l’esprit que votre SaaS multi-locataire doit collecter de nombreuses métriques de consommation de ressources très soigneusement et régulièrement.
Essayez d’examiner le niveau de personnalisation dont vos locataires ont besoin pour gérer leurs environnements et le niveau de contrôle dont vous avez besoin.
Recherchez très attentivement le type de support dont vos locataires pourraient avoir besoin de la part de l’environnement et de l’infrastructure, quels contenus et ressources doivent être partagés et qui gérera leurs demandes supplémentaires.
Il doit y avoir une compréhension claire du fonctionnement de l’infrastructure qui prend en charge votre architecture multi-locataires et s’il existe des limitations sur les ressources que vous consommez.
- SLA (Accord de niveau de service)
Il s’agit d’un document très important qui mesure les attentes du client et aide à comprendre ses besoins. Cela devrait certainement contribuer à votre modèle de multi-location.
- Fournisseur d’hébergement réputé
Trouver un hébergement pour votre SaaS suffisamment puissant et évolutif pour garantir un accès fluide et sécurisé aux logiciels pour les clients peut être un véritable défi.
Conclusion
Construire la bonne architecture SaaS multi-locataire est un facteur crucial qui affecte la qualité du service fourni et votre entreprise dans son ensemble. Considérez tous les facteurs de base mentionnés ci-dessus dès le début pour avoir une compréhension claire du logiciel que vous développez et de tous les besoins de vos clients.