Prise en charge de la mutualisation

Quels sont les défis typiques qui se posent lors de la conversion d'une application à locataire unique en application à locataire multiple? La sécurité et l'isolement des données me semblent les plus importants. Quels sont les autres?

Je suis l'un des architectes d'un effort d'automatisation assez important, et historiquement, c'est notre entreprise qui l'utilise. Nous voulons permettre à d'autres de l'utiliser également. Chaque fois que nous parlons de "le rendre multi-locataire", la conversation tourne autour de garder les utilisateurs avec un locataire éloignés des données qu'un autre locataire possède, et de s'assurer que les utilisateurs avec un locataire ne peuvent pas (intentionnellement ou par inadvertance) créer des impacts dans un autre environnements du locataire. Ce que je me demande, c'est si la sécurité / l'isolement des données sont vraiment les seules préoccupations majeures ici, ou s'il existe d'autres préoccupations majeures auxquelles nous ne pensons tout simplement pas.

architecture multitenancy

— Grant Palin
source

La solution la plus simple? Une nouvelle instance de l'ensemble du système, y compris le matériel, vide, à partir de zéro, un nouveau système par locataire. Si le système et les données sont assez précieux, cela peut être une très bonne option. Si vous n'aimez pas de nouveau matériel pour chaque instance, utilisez la virtualisation. Ce n'est peut-être pas le plus efficace, mais cela économisera certainement une tonne de maux de tête.

— SF.

Probablement du point de vue de la conception, c'est le plus simple, mais d'un point de vue administratif, cela ne semble pas l'être. Au moins, nos administrateurs système ne sont pas très enthousiasmés par cette proposition. (Et oui, nous utilisons des machines virtuelles.) Beaucoup plus d'instances à gérer (surveillance, déploiement, etc.) approche semble troquer la simplicité des dev pour la simplicité de l'administration ...?

Réponses:

Outre le cloisonnement des données, vous pouvez rencontrer des problèmes avec

Disponibilité - avec un seul locataire, ils ne peuvent que DoS eux-mêmes, mais même lorsque les données sont correctement cloisonnées, un locataire peut toujours épuiser les ressources.
Journalisation - tous les messages de journal supposaient un seul locataire. À moins que vous ne cloisonniez les journaux par locataire, vos messages de journal peuvent devenir moins utiles.
Concurrence - les applications à locataire unique peuvent s'exécuter sous une charge modérée, ou un conflit élevé pour quelques verrous peut sérialiser efficacement certaines opérations. Si les verrous sont multipliés par locataire, vous pouvez commencer à voir l'entrelacement des opérations qui ne s'est pas produit auparavant. Des conditions de course qui étaient très peu susceptibles de se manifester, pourraient maintenant se manifester.
Nouvelles sources de conflits de ressources - où auparavant vous pouviez avoir n sockets et m descripteurs de fichiers, multipliez maintenant ce nombre par locataire.
Compromis de configurabilité / rétrocompatibilité - où avant de pouvoir obsolète un composant lors du déploiement d'un remplacement, vous pouvez désormais avoir un locataire exigeant un composant et un locataire exigeant que l'ancien composant qu'il remplace reste indéfiniment.
Citation à comparaître - vous êtes actuellement une cible à comparaître pour les problèmes liés à votre entreprise. Avec plusieurs locataires, vous devrez peut-être répondre aux demandes d'assignation même si vous n'êtes pas partie à l'action en justice.

Certains supposent que vous exécutez tous les locataires dans le même espace d'adressage (machine ou cluster). Si chaque locataire exécute votre logiciel sur son matériel, vous pouvez évoquer une partie de ce qui précède et ajouter:

Difficultés d'accès aux machines pour déboguer.
Demandes d'assistance pour les anciennes versions.
Demandes pour permettre aux sous-traitants tiers de configurer.
Moins de contrôle sur le matériel sur lequel il fonctionne.
Moins de contrôle sur le cycle de patch / mise à jour du système d'exploitation sur lequel il fonctionne.

— Mike Samuel
source

À mon avis, le plus gros problème de la multi-location est la personnalisation. Cela se produit régulièrement si vous vendez une application métier à des entreprises. Cela peut varier de quelque chose d'aussi simple que chaque client désirant ses propres skins à la possibilité de configurer des champs, des règles, des formulaires et des rapports supplémentaires. Le niveau de personnalisation que vous devez prendre en charge joue un rôle essentiel dans l'architecture.

— Sriram
source

La réponse de Mike est très bonne, et beaucoup de points là-bas sous-estiment presque leur complexité en raison de leur brièveté, alors prenez-les à cœur.

Un point que j'ajouterais est que vous devriez avoir de bons outils de gestion pour créer (et plus tard, gérer) de nouveaux locataires. Selon l'architecture physique avec laquelle vous optez, cela peut être loin d'être anodin et c'est quelque chose qui est souvent négligé. Les avantages d'un logiciel en tant que produit de service n'entrent vraiment en jeu que lorsqu'il y a un grand nombre de locataires, donc un effort considérable devrait être consacré à la restauration.

Pour prolonger la réponse de Sriram; la personnalisation par locataire est à peu près interdite, tout ce qu'un locataire pourrait vouloir changer devrait être configurable . Par exemple, si votre solution ne prend pas en charge l'ajout dynamique de champs de données dans au moins quelques domaines clés, vous serez probablement inondé de demandes de personnalisation. Il est l' un des rares cas où un peu d' avance de complexité supplémentaire ne paie en fait de (disons qu'il va à l' encontre YAGNI, ou tout au moins, ce niveau de configuration est presque une exigence clé, de sorte que vous êtes en avoir besoin).

— Daniel B
source

Pourquoi la personnalisation est-elle "interdite"? C'est certainement techniquement réalisable. Il existe de nombreux modèles différents qui permettraient de réutiliser le système de base pour plusieurs locataires tout en prévoyant des pièces personnalisées pour les locataires individuels. Si un client est prêt à vous payer pour la personnalisation, il semblerait raisonnable de l'envisager. Il existe de nombreux produits multi-locataires qui ont des personnalisations par client pour cette raison. Il est plus dans l'esprit de YAGNI IMO de permettre une extensibilité et non pas par défaut de tout configurer.

— RationalGeek

Eh bien, je fais référence aux logiciels en tant qu'implémentations de service, en général (de "multi-tenancy"). Bien sûr, c'est techniquement réalisable, mais cela va à l'encontre des principes fondamentaux du SaaS. Sur le plan financier, vous réduisez les coûts en partageant la mise en œuvre et probablement l'infrastructure pour de nombreux locataires. Cela vous permet d'offrir votre produit à un prix inférieur, rattrapant ainsi la «longue queue» du marché (un grand nombre de personnes ne sont prêtes à payer qu'une petite somme). Vous pouvez maintenir peut-être 5 branches d'un système, mais pas 15 000, et c'est à cela que vise le SaaS.

— Daniel B

Au niveau de l'entreprise, je vois fréquemment des fournisseurs de SaaS qui sont prêts à apporter des personnalisations importantes à leur code afin de décrocher un client. Lorsqu'un client paie 6 ou 7 chiffres pour le service, il s'agit probablement d'un modèle commercial raisonnable.

— RationalGeek

Oui, dans ces cas, je suppose que oui. La plupart des changements que j'ai vus ont été mis en œuvre en tant que nouvelles fonctionnalités configurables qui ont été désactivées par défaut pour les clients existants. Le problème, je pense, c'est quand les 3 ou 4 premiers clients reçoivent chacun un traitement spécial parce que la solution n'a pas encore décollé. La solution se révèle trop spécifique et crée une culture du "OK, nous allons juste la pirater". Mais oui, je suis d'accord avec votre commentaire sur les gros clients.

— Daniel B

C'est une distinction utile que vous faites autour de la personnalisation. Je pense que le même concept pourrait également s'appliquer à la gérabilité. Notre mutualisation vise probablement relativement moins de gros clients plutôt que de clients à longue queue. Si l'objectif principal de la mutualisation est de capturer la longue queue, ce n'est peut-être même pas la bonne approche pour nous. Merci pour ces réflexions.