Multi-location ou multi-instance?

J'essaie de créer une solution SaaS basée sur le Web et j'ai pris une route où je ne suis pas sûr d'utiliser la multi-location ou la multi-instance. J'essaierai de décrire ce que j'essaye de réaliser, et chaque approche des avantages et des inconvénients (mon avis, selon ce que j'ai lu). Veuillez inclure vos suggestions au cas où j'aurais oublié quelque chose dans une approche par rapport à l'autre.

L'application que j'essaie de créer est, comme je l'ai mentionné, une solution SaaS où les entreprises peuvent créer leurs comptes, et chaque compte / entreprise a ses propres utilisateurs, clients, produits, services ... etc. Chaque utilisateur; qui est un employé de l'entreprise; liés à un compte / entreprise n'auront accès qu'aux clients, produits et services de son entreprise. Les entreprises peuvent avoir un nombre illimité de clients, de produits et de services, chaque entreprise doit donc avoir son propre centre de données.

Pour cela, j'ai décidé de créer une base de données partagée (en enregistrant toutes les informations d'identification des utilisateurs à des fins de connexion) et plusieurs schémas partagés de bases de données (base de données par compte / entreprise). Fondamentalement, Multi Tenancy .

Ensuite, quelqu'un a suggéré d'utiliser plutôt Multi Instance , où chaque entreprise aura sa propre instance de l'application (c'est-à-dire le code, les bibliothèques, la base de données, les frameworks, etc.) totalement séparée des autres sociétés. Cela semble mieux car je n'ai pas à m'occuper d'une couche supplémentaire où je dois m'assurer que les utilisateurs de chaque locataire n'ont accès qu'aux données de leur entreprise. Je pense qu'il est bon de mentionner que je dépend de Docker pour réaliser cette approche (je ne l'ai jamais utilisée auparavant), mais je pense qu'il manque de fonctionnalités (plus sur celles-ci plus tard) dont j'aurai besoin à l'avenir (au moins je ne l'ai pas fait) pas les trouver avec un peu de recherche).

Cependant, chaque approche comporte des avantages et des inconvénients, donc je ne pouvais pas décider quelle approche adopter. Voici une liste, mais nu avec moi car je n'ai pas la connaissance des deux, donc il pourrait y avoir quelque chose que je ne connais pas, ou une solution à un problème que je n'ai pas trouvé sur le web: [Chaque approche a une liste ordonnée dont j'ai suivi une comparaison un par un]

Multi-location :

1. Hôte / matériel partagé, code partagé et base de données multi.
2. Il est plus facile d'étendre les fonctionnalités du code et de corriger les bugs (code partagé).
3. Il est plus difficile d'étendre le matériel (peut utiliser un service cloud) ou de déplacer la base de données du locataire individuel vers un autre système sans apporter de modifications au code.
4. Plus important encore, comme je l'ai mentionné précédemment, je dois ajouter une couche supplémentaire au système pour m'assurer que l'utilisateur appartient bien à sa société et qu'il n'accède pas aux informations d'une autre société.

Multi-instance :

1. Hôte / matériel partagé ou non partagé, code par instance et base de données par instance.
2. Il est plus difficile d'étendre les fonctionnalités ou de corriger les bogues (je ne sais pas s'il existe un moyen de le faire dans Docker où vous pouvez ajouter des fonctionnalités / fonctionnalités à une instance ou un conteneur Docker et les déployer sur les autres).
3. Il est plus facile de déplacer l'instance entière vers un hôte / matériel différent.
4. En tant qu'instance, je n'ai pas besoin de prendre soin de cette couche car chaque instance aura sa propre base de données.

Tous les avantages et inconvénients sont redondants au cas où je voudrais faire quoi que ce soit manuellement (comme la création manuelle d'une instance pour chaque locataire), et c'est pourquoi je doute de la solution Docker, sauf s'il existe un moyen de résoudre ce problème, qui est peut-être le principal raison de la question. Je vous serais reconnaissant de bien vouloir répondre à la question en faisant référence aux solutions, et pourquoi pensez-vous que cette approche est meilleure que l'autre.

Dans le cas où cela aiderait (peut-être?), Nous utilisons Laravel comme framework principal pour le back-end (tous RESTfully).

Je me pose exactement la même question en ce moment.

Je penche pour la solution de location simple multi-instance mais je n'ai pas encore pris de décision définitive. Permettez-moi de partager certaines de mes réflexions:

Le principal avantage historique de l'architecture multi-locataire est une meilleure utilisation des ressources d'infrastructure , par mutualisation (OS unique, base de données unique, couche d'application unique) et une meilleure occupation desdites ressources (lorsqu'un utilisateur est absent, un autre peut utiliser la même ressource) .

Il simplifie également considérablement le cycle de vie des logiciels : vous déployez de nouvelles versions sur une seule instance, tous les clients sont mis à jour en même temps.

Il semble cependant que les récents progrès de la technologie cloud rendent la première classe d'avantages largement disponible dans une architecture multi-instance (instance par client) (je pense spécifiquement à une plate-forme comme Jelastic ici, mais je suis sûr qu'il y en a d'autres qui fournir les mêmes fonctionnalités):

• PaaS basé sur des conteneurs
• Provisionnement et mise à l'échelle automatique des conteneurs (conteneurs élastiques)

La gestion du matériel et des plateformes n'est donc plus la préoccupation du fournisseur de logiciels. Les ressources sont mutualisées beaucoup plus efficacement qu'auparavant au niveau des infrastructures et des plates-formes .

Il y aura toujours un surcoût pour les instances multiples (certaines applications et middlewares seront exécutés N fois au lieu d'une seule), mais beaucoup moins que lors de l'utilisation d'une machine (virtuelle) distincte par instance. La base de données pourrait être partagée de toute façon (un schéma par instance, plusieurs schémas par serveur DB)

Aussi :

• L'automatisation de la création de nouvelles instances est possible via l'API PaaS
• L'automatisation du déploiement de nouvelles versions est possible via l'API PaaS, sans temps d'arrêt (nécessite un certain travail de mise en place)
• La mise à l'échelle est toujours terminée, jamais à la hausse. Nous n'avons pas à nous soucier des énormes ensembles de données au niveau de l'instance.

Bien sûr, nous aurions besoin d'une sorte de service central qui gère tout cela automatiquement (par exemple, la création d'une instance lorsqu'un nouvel utilisateur crée un compte). Cela permettrait également de gérer les problèmes de paiement et de licence, l'interaction entre les instances, etc. Ce service central peut être assez complexe et difficile à développer, mais la bonne chose est que nous n'avons pas à l'implémenter en amont (maintenant que nous n'avons pas beaucoup alors que le multi-locataire devra être intégré dans l'application dès le départ.

Ce qui m'amène aux derniers avantages de développer un locataire unique pour un projet de démarrage très précoce (pré-investissement):

• La même version (ou presque la même) de l'application peut être déployée sur site en tant qu'appliance virtuelle ou conteneur de docker ou même sur une machine gérée par le client (certaines entreprises hésitent toujours vers le Cloud et cela peut aider un démarrage précoce à ne pas expulser les adopteurs précoces importants)
• Plus rapide pour sortir un produit avec des ressources limitées (la couche d'application et le schéma de base de données sont assez moins complexes), peut obtenir un produit locataire unique "stupide" en premier lieu (MVP) pour les premiers utilisateurs et montrer la valeur commerciale de l'application aux investisseurs potentiels, et ajouter toute l'automatisation du cloud plus tard
• Peut être considéré comme un argument de vente pour les clients soucieux de la sécurité des données: les données sont mieux encapsulées car chaque client a son propre schéma ou même sa base de données. Beaucoup moins de risques de "débordement"

NB: Je pense évidemment ici à une application métier où les clients seraient des entreprises (chacune avec plusieurs utilisateurs individuels) et non des particuliers. Il ne serait pas logique d'exécuter une instance distincte d'une application pour chaque utilisateur individuel (ou le ferait-il?)

La prise en charge des deux options est également possible (un pool de locataires sur plusieurs instances).

Je privilégie la cause multi-instance de l'isolement naturel. L'instance de chaque client s'exécute dans ses propres processus et ses données sont isolées dans sa propre base de données. Vous pouvez mettre à niveau les instances vers de nouvelles versions par client / instance si vous le souhaitez.

Les systèmes basés sur les locataires présentent un risque pour la sécurité des informations. Considérez à quel point il est facile d'oublier une clause "WHERE tenantId = x". La principale raison d'utiliser un système compatible avec les locataires serait la performance, les processus sont lourds, en partageant un processus, vous pouvez potentiellement tirer le meilleur parti d'une machine. C'était plus vrai je pense que dans un monde 32 bits alors c'est aujourd'hui sur les machines 64 bits qui ont beaucoup plus de RAM.

Un système multi-instance aurait peut-être besoin d'un peu plus d'outils pour créer et configurer l'environnement tel que les bases de données et les instances d'applications Web. On peut affirmer que vous devez également avoir ce script pour vos déploiements à instance unique. Cela a également d'autres avantages, comme la possibilité de configurer des environnements de développement et de test

Je laisserais les capacités du locataire jusqu'à ce que vous puissiez en faire la preuve (coût d'ingénierie vs argent économisé sur l'infrastructure (matérielle) grâce au partage de processus).