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 :
- Hôte / matériel partagé, code partagé et base de données multi.
- Il est plus facile d'étendre les fonctionnalités du code et de corriger les bugs (code partagé).
- 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.
- 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 :
- Hôte / matériel partagé ou non partagé, code par instance et base de données par instance.
- 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).
- Il est plus facile de déplacer l'instance entière vers un hôte / matériel différent.
- 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).