Architecture multi-tenant partie 1 : présentation

icon Tags de l'article : , ,

Octembre 22, 2022
En anglais, tenant signifie locataire. Donc architecture multitenant = architecture multi-locataires.

La plupart du temps, lorsqu'on développe une application destinée à plusieurs clients, on va avoir tendance à concevoir une (et une seule) appli web, qu'on déploiera ensuite pour chaque client, chaque client/appli ayant sa propre BDD.



Cette approche simplifie le développement, mais elle va complexifier :
  • le déploiement
  • les mises à jour
  • la maintenance
  • le débogage
  • les backups

Ce qui fait qu'on a vite beaucoup à faire niveau infra/ops :



Ces opérations, quand on a 1 ou 2 clients, sont faciles à gérer manuellement. Mais quand on commence à arriver à 10, 20, 50, ... clients, ben vous voyez vite où ça nous mène :


Du coup on doit automatiser ces opérations. Ce qui demande des compétences ops/devops assez poussées. Et même en automatisant un maximum (procédures, provisionning, scripts, monitoring, ...), ben vous aurez très souvent à intervenir manuellement, ne serait-ce que pour lancer les opérations à chaque nouveau client.

En résumé, plus vous aurez de clients, plus vous aurez besoin d'une équipe ops conséquente et compétente. Ce qui va créer de gros problèmes de scaling humain dans votre structure. Ca plus les problématiques de synchronisation/management.

Et bien sachez qu'il existe une solution applicative à ça : l'architecture multi-tenant.

En quoi ça consiste ? C'est assez simple à expliquer : vous avez une seule application web déployée, et une seule base de données, pour tous vos clients.



Là vous vous dites : euh ouais mais ça peut pas être si simple. En effet, techniquement il va y avoir pas mal de choses à implémenter.

Déjà, il y a trois façons de faire :
  • colonne personnalisée : sur chaque table on va créer une colonne "tenant" ou "tenantId" qui servira à filtrer par tenant dans toutes les requêtes
  • BDD séparées : une seule application web, mais chaque client a sa propre BDD
  • schémas séparés : on crée différents schémas en BDD, et chaque client a son propre schéma et ses propres tables

Chaque solution a ses avantages et inconvénients.
La solution colonne personnalisée permet d'avoir un multitenant complet mais demande beaucoup de rigueur niveau code et architecture applicative.
La solution de BDD séparées oblige à créer/mettre à jour/backuper X BDD, 1 par client.
La solution de schémas séparés oblige à créer des tables pour chaque client, ce qui va rendre compliqué la partie investigation/débug.

Dans cette série d'articles, je vais me concentrer sur l'approche colonne personnalisée, afin d'avoir à m'occuper le moins possible des systèmes.

Si on devait imaginer un postulat de départ : vendre une suite applicative à plein de clients, sans augmenter ma charge de travail même si je passe de 10 clients à 100.

Pour ça, le fonctionnement implémenté est simple :
  • quand une requête arrive, en fonction du nom de domaine/de l'url/d'un autre paramètre dans les headers, on va filtrer les données de la BDD, afin de ne renvoyer que les données concernant ce client.
  • Et quand le client crée un objet, on ajoute une information sur l'objet pour indiquer à quel client appartient cette donnée.

Ainsi, les clients ne peuvent pas accéder aux données des autres clients. Quoi qu'il arrive, chaque client a sa propre portion de données et n'a pas accès aux données des autres.


Comme on le voit ici, chaque client verra une application différente et des données différentes, alors qu'ils utilisent la même infrastructure.

Evidemment, cette approche a ses avantages, et des défauts.

Avantages :
  • 0 problèmes de scaling humain
  • 1 seule application web et 1 seule BDD à déployer/mettre à jour/backuper/monitorer
  • débogage simplifié

Inconvénients :
  • limitations charge (si vous avez trop de clients votre BDD risque de ne pas suivre)
  • potentiellement bloquant pour certains marchés qui imposent un hébergement des données indépendant

Neutre :
  • sécurité : beaucoup de gens diraient "oui mais si ta BDD fuite ils récupèrent les données de tous tes utilisateurs", mais soyons honnêtes, même avec des BDD séparées, quand t'as une fuite d'infos, toutes les infos de tous les clients fuitent la plupart du temps car la sécurité ne diffère pas entre les clients
  • technique : le code va est plus compliqué au départ, mais une fois la base posée, on ne voit "presque" plus la différence avec une application classique

Malgré ses défauts, je pense qu'une architecture multi-tenant vaut vraiment la peine d'être mise en place lorsqu'on sort un produit SAAS et qu'on veut se simplifier la vie sur le long terme.

On va arrêter là pour l'instant, dans le prochain article je pense me concentrer sur l'implémentation.

D'ici là... bon dev à vous !

En résumé : .Net Core, qu'est ce que c'est

icon Tags de l'article : , ,

Novembre 27, 2018
Hello tout le monde,

Comme j'ai repris les cours il y a peu et que je me suis mis à fond dans le .Net Core (principalement ASP.Net Core et Entity Framework Core), je me suis dit qu'il serait intéressant de commencer une petite série d'articles pour en parler. Expliquer les différences, ce que ça apporte, tout ça tout ça.

Déjà, en résumé, .Net Core, c'est le nouveau runtime/framework opensource de Microsoft.
Il s'agit d'une refonte from scratch du Framework .Net, destinée à être plus ouverte et plus performante.
Le code source est disponible sur github et ce bébé framework a déjà fêté ses 59 releases grâce à ses 149 contributeur(ices)s!

Du coup, grâce à ce nouveau framework, il est possible de créer des applications .Net pour tous supports : Linux, Mac, Android, etc...

Et si vous êtes un dinosaure du .Net comme moi, je sais que vous allez vous poser quelques questions sur .Net Core. Je vais essayer d'y répondre de mon mieux.

1) Est-ce que c'est vraiment plus performant ?

Oui. En tout cas pour la partie ASP.Net Core. Pour la partie Entity Framework, je ne pourrais dire avec précision, mais je pense que comme avec Entity Framework classique, ça dépend plus de l'utilisation qu'on en fait que du framework lui-même.

2) Est-ce que c'est mieux et/ou plus complet ?

Alors mieux... tout dépend de ce que vous cherchez. C'est plus léger, plus performant, et plus compatible/ouvert.
En revanche, vu qu'il s'agit d'un nouveau framework, c'est clairement moins complet que le .Net Framework. Ca évolue vite, mais au jour le jour.
Du coup, si vous utilisez des fonctionnalités très poussées de .Net, il se peut que vous vous retrouviez bloqué.
Personnellement, ce n'est pas encore mon cas. J'ai réussi à faire en ASP.Net Core tout ce que je faisais en ASP.Net MVC classique !

3) Est-ce que c'est documenté ?

Ohhhh ça oui. Il semblerait que Microsoft ait fait un énorme travail de documentation sur tout ce qu'il était possible de faire avec .Net Core. J'ai même trouvé des ressources pour Entity Framework Core sans équivalent Entity Framework classique !

4) Est-ce qu'il y a des packages NuGet ?


Plein ! Evidemment il y en a moins que de packages pour .Net Framework classic, mais bien assez pour tout ce qu'on veut faire. La majorité des packages Nuget maintenus et/ou critiques ont une version Core aujourd'hui.

5) Est-ce qu'il y a des fonctionnalités en plus ?

Yep. Comme je disais, il s'agit d'un framework codé from scratch. Sans s'embarrasser de l'existant. Du coup les devs ont ajouté plein de choses qui manquaient.
Le premier exemple qui me vient en tête : l'injection de dépendances est gérée nativement !

6) Est-ce que tu es payé pour la rédaction de cet article ?

J'aimerais bien ! Mais ce n'est pas le cas. J'avais juste envie de vous présenter rapidement le framework, avant de commencer à publier du code sur ce sujet.

Voilà, j'espère que cet article vous a plus, et je vous dit à bientôt pour la suite !