Malheureusement, ce terme n'a pas de bon équivalent en français. La « Wikipédia » donne « multi-location, location multiple ». Parfois, cela est appelé « propriété multiple ». Ces termes peuvent prêter à confusion, car le sujet n'est en réalité lié ni à la location, ni à la propriété. Il s'agit plutôt d'une question d'architecture logicielle et d'organisation de son exploitation. D'ailleurs, ce dernier aspect est tout aussi important.
Nous avons commencé à former notre compréhension du multitenant au moment où nous avons commencé à concevoir notre approche du modèle de service cloud pour « 1C:Enterprise ». C'était il y a quelques années. Depuis lors, notre compréhension s'est constamment élargie. Nous découvrons sans cesse de nouveaux aspects (avantages, inconvénients, complexités, particularités, etc.) sur ce sujet.
Parfois, les développeurs comprennent le multitenant comme quelque chose de très simple : « pour que les données de plusieurs organisations soient stockées dans une seule base, il suffit d'ajouter une colonne avec l'identifiant de l'organisation dans toutes les tables et d'appliquer un filtre sur celle-ci ». Nous avons également commencé notre réflexion à partir de ce moment-là. Mais nous avons rapidement compris que ce n'était qu'une petite partie (qui, soit dit en passant, n'est pas simple non plus). En fait, c'est « tout un domaine ».
L'idée principale du multitenant peut être décrite de la manière suivante. Une application normale est une maison unifamiliale, conçue pour accueillir une seule famille qui utilise son infrastructure (murs, toit, approvisionnement en eau, chauffage, etc.). Une application multitenant, quant à elle, est un immeuble d'appartements. Dans celui-ci, chaque famille utilise une infrastructure similaire, mais celle-ci est conçue pour l'ensemble de l'immeuble.
Et l'approche multitenant, est-ce bon ou mauvais ? On peut trouver des opinions très variées sur ce sujet. Il semble qu'il n'y ait pas de réponse définitive de « bien ou mal » en général. Il faut comparer les avantages et les inconvénients dans le contexte des tâches spécifiques à résoudre. Mais c'est un sujet à part…
Dans sa compréhension la plus simple, l'objectif du multitenant est de réduire les coûts de maintenance de l'application en « mutualisant » les dépenses d'infrastructure. C'est un mouvement similaire à la réduction des coûts de l'application grâce à l'utilisation d'une solution standard (peut-être avec des configurations et des personnalisations), au lieu d'une création « sur mesure ». Dans un cas, le développement est mutualisé, et dans l'autre, l'exploitation.
À ce propos, rappelons que ce n'est pas directement lié à la méthode de vente. L'architecture multitenant peut tout à fait être appliquée dans une infrastructure informatique d'entreprise ou gouvernementale pour automatiser un grand nombre de succursales et d'entreprises d'un même groupe.
On peut dire que le multitenant n'est pas simplement une question d'organisation du stockage des données. C'est un modèle de fonctionnement de l'application dans son ensemble (y compris une partie importante des aspects de son architecture, de son déploiement et de son entretien).
Ce qui est le plus complexe et intéressant dans le modèle multitenant, semble-t-il, c'est que l'essence même de l'application est « scindée ». Une partie de ses fonctionnalités traite des domaines de données spécifiques (appartements) et « n'est pas intéressée » par les résidents d'autres appartements. L'autre partie perçoit l'immeuble dans son ensemble et fonctionne pour tous les résidents. Cependant, cette dernière ne peut pas s'abstraire du fait qu'il s'agit tout de même d'appartements distincts, et il est nécessaire d'assurer un niveau adéquat de granularité et de sécurité.
Dans « 1C:Enterprise », le modèle multitenant est mis en œuvre à travers plusieurs technologies. Ce sont les mécanismes de la plateforme « 1C:Enterprise », les mécanismes «» et «», les mécanismes (bibliothèques de sous-systèmes standard).
Chacun de ces éléments contribue à la création de l'infrastructure globale d'un immeuble à appartements. Pourquoi cela s'implémente-t-il à travers plusieurs technologies, et non pas en une seule, comme la plateforme ? Avant tout, parce qu'il nous semble qu'il est tout à fait pertinent de modifier certains mécanismes lors d'une variante de déploiement spécifique. Mais en général, c'est une question complexe, et nous sommes constamment face à la question - à quel niveau il vaut mieux réaliser tel ou tel aspect du multitenant.
Il est évident que la partie de base des mécanismes devait être réalisée dans la plateforme. Par exemple, la séparation des données en elle-même. C'est généralement de cela que l'on commence à parler lorsqu'on aborde le multitenant. Mais finalement, le modèle multitenant a « impacté » une partie substantielle des mécanismes de la plateforme, et a nécessité leurs améliorations, et dans certains cas, une réévaluation.
Au niveau de la plateforme, nous avons mis en œuvre des mécanismes de base. Ils permettent de créer des applications fonctionnant selon un modèle multitenancy. Mais pour que les applications « vivent et fonctionnent » dans un tel modèle, il est nécessaire d'avoir un système de gestion de leur « activité ». Cela est assuré par les technologies 1cFresh et une couche unifiée de logique métier au niveau de BSB. Tout comme dans un immeuble collectif, l'infrastructure fournit aux résidents tout le nécessaire, les technologies 1cFresh fournissent tout ce dont les applications, fonctionnant selon le modèle multitenancy, ont besoin. Afin que les applications puissent interagir avec cette infrastructure (sans modifications majeures), elles intègrent des « connecteurs » sous forme de sous-systèmes de BSB.
Du point de vue des mécanismes de la plateforme, il est facile de constater qu'au fur et à mesure que nous acquerrons de l'expérience et que nous développons la variante cloud d'« 1C:Entreprises », nous élargissons l'ensemble des mécanismes impliqués dans cette architecture. Prenons un exemple. Dans le modèle multitenancy, la répartition des rôles des participants à la maintenance des applications change considérablement. Le rôle (niveau de responsabilité) de ceux qui sont responsables de l'exploitation des applications est considérablement renforcé. Ils doivent maintenant disposer d'outils de contrôle des applications plus puissants. Car les utilisateurs des applications (résidents) font avant tout confiance au prestataire avec lequel ils travaillent. Pour cela, nous avons réalisé dans la version 8.3 un nouveau . Ce mécanisme permet aux administrateurs du prestataire de limiter la liberté des développeurs d'applications à un niveau de sécurité nécessaire - en substance, d'isoler le travail de l'application pour chaque résident dans des limites définies de « bac à sable ».
L'architecture pour la gestion des applications fonctionnant en mode multitenancy (ce que l'on trouve dans les technologies 1cFresh et BSP) suscite un intérêt tout aussi considérable. Comparé à un modèle de déploiement classique, les exigences en matière d'automatisation des processus de gestion sont considérablement renforcées. Ces processus sont nombreux : création de nouveaux domaines de données (« appartements »), mise à jour des applications, mise à jour des informations réglementaires, sauvegarde, etc. Et bien sûr, les exigences en matière de fiabilité et de disponibilité augmentent. Par exemple, pour garantir une interaction fiable entre les applications et les composants du système de gestion, nous avons mis en place une technologie de système d'appel asynchrone avec livraison garantie.
Un aspect très délicat est la manière de partager les données et les processus. Cela peut sembler simple (pour ceux qui le pensent) à première vue. La plus grande complexité réside dans l'équilibre entre centralisation des données et des processus et décentralisation. D'une part, la centralisation permet de réduire les coûts (espace de stockage, ressources processeur, efforts des administrateurs…). D'autre part, elle limite la liberté des « habitants ». C'est précisément l'un des aspects de la « dualité » de l'application, où le développeur doit penser à la fois à l'application au sens strict (desservant un seul « appartement ») et au sens large (desservant tous les « habitants » en même temps).
Un exemple de ce type de « dilemme » peut être l’information réglementaire. Il est évident que la tentation de la rendre commune à tous les « habitants » de l'immeuble est forte. Cela permet de la stocker en un seul exemplaire et de la mettre à jour instantanément pour tous. Mais il arrive qu'un habitant ait besoin de modifications spécifiques. Étrangement, cela se produit même pour des informations spécifiées par des régulateurs (organismes gouvernementaux). Cela soulève une question délicate : faut-il partager ou non ? Bien sûr, il est tentant de créer une information commune pour tous et une privée pour ceux qui le souhaitent. Cependant, cela entraîne une réalisation beaucoup plus complexe. Mais nous y travaillons...
Un autre exemple est la conception de l'implémentation de processus réguliers (effectués selon un calendrier, initiés par le système de gestion, etc.). D'une part, ils peuvent être mis en œuvre pour chaque domaine de données séparément. C'est plus simple et plus pratique. Mais, d'autre part, une granularité aussi fine crée une charge importante sur le système. Pour réduire cette charge, il est nécessaire de mettre en œuvre des processus mutualisés. Mais ceux-ci nécessitent une élaboration plus approfondie.
Il est clair qu'une question très importante se pose. Comment les développeurs d'applications peuvent-ils assurer le fonctionnement en mode multitenancy ? Que doivent-ils faire à cet égard ? Naturellement, nous cherchons à ce que le poids des questions technologiques et infrastructurelles repose autant que possible sur les épaules de la technologie fournie, afin que le développeur d'applications ne pense qu'aux tâches de logique métier. Mais comme pour d'autres questions architecturales importantes, les développeurs d'applications doivent avoir une certaine compréhension du fonctionnement en mode multitenancy et des efforts seront nécessaires lors du développement d'applications. Pourquoi ? Parce qu'il y a des aspects que la technologie ne peut pas garantir automatiquement sans tenir compte de la sémantique des données. Par exemple, la définition même des limites de mutualisation des informations. Mais nous essayons de rendre ces complexités aussi réduites que possible. Des exemples de l'implémentation de telles applications existent déjà.
Un aspect important dans le cadre de la mise en œuvre du multitenancy dans «1C:Entreprise» est que nous créons un modèle hybride, dans lequel une application peut fonctionner à la fois en mode multitenancy et en mode normal. C'est une tâche assez complexe et sujet à une discussion séparée.
Source : habr.com
