Multilocation

L'architecture logicielle multi-locataire est une architecture logicielle dans laquelle une seule instance de logiciel s'exécute sur un serveur et sert plusieurs locataires. Les systèmes conçus de cette manière sont « partagés » (plutôt que « dédiés » ou « isolés »). Un locataire est un groupe d'utilisateurs qui partagent un accès commun avec des privilèges spécifiques à l'instance logicielle. Avec une architecture multi-locataire, une application logicielle est conçue pour fournir à chaque locataire une part dédiée de l'instance, y compris ses données, sa configuration, la gestion des utilisateurs, les fonctionnalités individuelles du locataire et les propriétés non fonctionnelles . L'architecture multi-locataire contraste avec les architectures multi-instances, où des instances logicielles distinctes fonctionnent pour le compte de différents locataires.

Certains commentateurs considèrent le multi-hébergement comme une caractéristique importante du cloud computing .

Les applications multilocataires ont évolué à partir de trois types de services et combinent certaines caractéristiques de ces derniers :

1. Partage de temps : à partir des années 1960, les entreprises louaient de l'espace et de la puissance de traitement sur des ordinateurs centraux ( partage de temps ) pour réduire leurs dépenses informatiques. Souvent, elles réutilisaient également des applications existantes, avec simplement un champ de saisie séparé sur l'écran de connexion pour spécifier un identifiant de compte client. Sur la base de cet identifiant, les comptables du mainframe pouvaient facturer aux clients individuels l'utilisation réelle du processeur, de la mémoire et du disque/de la bande.
2. Applications hébergées : à partir des années 1990, les fournisseurs de services applicatifs traditionnels (ASP) hébergeaient des applications (alors existantes) pour le compte de leurs clients. En fonction des limitations de l'application sous-jacente, les ASP étaient obligés d'héberger les applications sur des machines distinctes (si plusieurs instances des applications ne pouvaient pas être exécutées sur la même machine physique) ou sous forme de processus distincts . Les applications multilocataires représentent une architecture plus mature qui permet un service similaire avec un coût opérationnel inférieur.
3. Applications Web : applications Web grand public populaires (telles que Hotmail ) développées avec une instance d'application unique servant tous les clients. Les applications multilocataires représentent une évolution naturelle de ce modèle, offrant une personnalisation supplémentaire à des groupes d'utilisateurs au sein (par exemple) de la même organisation cliente.

Dans un environnement multi-locataire, plusieurs clients partagent la même application, exécutée sur le même système d'exploitation, sur le même matériel, avec le même mécanisme de stockage de données. La distinction entre les clients est réalisée lors de la conception de l'application, ainsi les clients ne partagent pas ou ne voient pas les données des autres. Comparez cela à la virtualisation où les composants sont transformés, ce qui permet à chaque application client de sembler s'exécuter sur une machine virtuelle distincte.

Certaines entreprises promeuvent activement le principe de multi-location et l'utilisent comme source de différenciation concurrentielle. Le recours à la multi-location augmente de jour en jour.

La multilocation permet de réaliser des économies de coûts au-delà des économies d'échelle de base réalisables en consolidant les ressources informatiques en une seule opération. Une instance d'application entraîne généralement une certaine quantité de mémoire et de traitement qui peut être substantielle lorsqu'elle est multipliée par de nombreux clients, en particulier si ces derniers sont de petite taille. La multilocation réduit ces frais généraux en les répartissant sur de nombreux clients. D'autres économies de coûts peuvent provenir des coûts de licence des logiciels sous-jacents (tels que les systèmes d'exploitation et les systèmes de gestion de base de données). En gros, si vous pouvez tout exécuter sur une seule instance logicielle, vous n'avez qu'à acheter une seule licence logicielle . Les économies de coûts peuvent être éclipsées par la difficulté de faire évoluer l'instance unique à mesure que la demande augmente : l'augmentation des performances de l'instance sur un seul serveur ne peut se faire qu'en achetant du matériel plus rapide, comme des processeurs rapides, plus de mémoire et des systèmes de disques plus rapides, et généralement ces coûts augmentent plus rapidement que si la charge était répartie entre plusieurs serveurs ayant à peu près la même capacité globale. De plus, le développement de systèmes multilocataires est plus complexe et les tests de sécurité sont plus rigoureux car les données de plusieurs clients sont mélangées.

L'une des raisons les plus convaincantes pour lesquelles les fournisseurs/ éditeurs de logiciels indépendants utilisent la multilocation est les avantages inhérents à l'agrégation de données . Au lieu de collecter des données à partir de plusieurs sources de données, avec des schémas de base de données potentiellement différents , toutes les données de tous les clients sont stockées dans un seul schéma de base de données. Ainsi, l'exécution de requêtes sur plusieurs clients, l'exploration de données et la recherche de tendances sont beaucoup plus simples. Cette raison est probablement surfaite, car l'une des principales exigences de la multilocation est la nécessité d'empêcher le fournisseur de services d'accéder aux informations sur les clients (locataires). De plus, il est courant de séparer la base de données opérationnelle de la base de données d'exploration (généralement en raison de caractéristiques de charge de travail différentes), ce qui affaiblit encore plus l'argument.

En raison de la complexité supplémentaire de la personnalisation et de la nécessité de conserver les métadonnées par locataire , les applications multilocataires nécessitent un effort de développement plus important. Des considérations telles que le séquençage des données basé sur des vecteurs, l'infrastructure d'algorithmes chiffrables et les interfaces de contrôle virtualisées doivent être prises en compte.

Le modèle multi-locataire simplifie le processus de gestion des versions. Dans un processus de gestion des versions traditionnel, les packages contenant les modifications de code et de base de données sont distribués sur les postes de travail client et/ou les serveurs. Dans le cas d'une instance unique, il s'agirait d'un serveur par client. Ces packages doivent ensuite être installés sur chaque machine individuelle. Avec le modèle multi-locataire, le package ne doit généralement être installé que sur un seul serveur. Cela simplifie considérablement le processus de gestion des versions, et l'échelle ne dépend plus du nombre de clients.

En même temps, la multilocation augmente les risques et les impacts inhérents à l'application d'une nouvelle version. Comme il existe une seule instance logicielle servant plusieurs locataires, une mise à jour sur cette instance peut entraîner des temps d'arrêt pour tous les locataires, même si la mise à jour est demandée et utile pour un seul locataire. De plus, certains bogues et problèmes résultant de l'application de la nouvelle version peuvent se manifester dans la vue personnalisée de l'application par d'autres locataires. En raison d' un temps d'arrêt possible , le moment d'application de la version peut être limité en fonction du calendrier d'utilisation de plusieurs locataires.

Selon Marc Brooker, dans une architecture multi-locataire, les charges de travail non liées et non corrélées doivent être regroupées. En effet, le mélange de charges de travail différentes, avec des besoins et des modèles différents, masque les modèles de chaque charge de travail. Le regroupement des charges de travail réduit le rapport pic/moyenne du système global ; les charges de travail individuelles peuvent utiliser davantage de ressources pendant les heures de pointe sans augmenter de manière significative la structure de coût globale du système et vous aident par la suite à atteindre une meilleure efficacité des coûts. Notez que plusieurs charges de travail provenant de la même application, du même client ou du même secteur ont tendance à se comporter comme une seule charge de travail.

Les applications multilocataires doivent généralement fournir un degré élevé de personnalisation pour répondre aux besoins de chaque organisation cible. La personnalisation comprend généralement les aspects suivants :

• Image de marque : permettre à chaque organisation de personnaliser l'apparence de l'application pour qu'elle corresponde à son image de marque d'entreprise (souvent appelée « skin » distincte).
• Workflow : s'adapter aux différences de flux de travail pour être utilisé par un large éventail de clients potentiels.
• Extensions du modèle de données : prise en charge d'un modèle de données extensible pour donner aux clients la possibilité de personnaliser les éléments de données gérés par l'application pour répondre à leurs besoins spécifiques.
• Contrôle d'accès : permettre à chaque organisation cliente de personnaliser indépendamment les droits d'accès et les restrictions pour chaque utilisateur .

Les applications multilocataires doivent fournir une sécurité , une robustesse et des performances adéquates entre plusieurs locataires, qui sont fournies par les couches situées sous l'application dans le cas d'applications multi-instances.

Les coûts de refonte des applications pour la multilocation peuvent être importants, en particulier pour les éditeurs de logiciels qui continuent de proposer une version monolocataire sur site de leur produit. Ils finissent par être obligés de prendre en charge deux produits distincts, avec tous les coûts qui en découlent.

Une alternative de plus en plus viable à la multilocation qui élimine le besoin de changements architecturaux importants consiste à utiliser la technologie de virtualisation pour héberger plusieurs instances isolées d'une application sur un ou plusieurs serveurs. En effet, lorsque les applications sont reconditionnées sous forme d'appliances virtuelles, la même image d'appliance peut être déployée dans des emplacements hébergés par un ISV, sur site ou chez un tiers de confiance, et même migrée d'un site de déploiement à un autre au fil du temps.