Discussion :

[Lovegiver]

Bonjour,

je cherche des conseils concernant le déploiement puis l'usage en mode SaaS d'une application auparavant déployée en standalone.

L'entreprise qui m'emploie déployait jusqu'à présent une solution basée sur des outils spécifiques (notamment 4D, InDesign, etc.). Chaque client disposait des infras nécessaires pour faire tourner sa propre copie de l'application dans ses locaux.

Je travaille quant à moi sur la prochaine version de l'application. Je dois porter celle-ci en Java et rendre celle-ci accessible en mode SaaS.

Plusieurs serveurs seront déployés chez nous, chacun hébergeant une partie du service global : un serveur d'application, un serveur de BDD, un autre pour le traitement d'images.

La question que je me pose est celle de savoir comment déployer mon appli Java plusieurs fois sur le même serveur, sachant que chaque client aura sa propre application accessible depuis une URL spécifique du genre : client1-application.com, client2-application.com, etc.
Chaque instance de l'application accèdera à ses données hébergées sur un serveur de BDD où chaque client disposera de sa propre BDD (PostgreSQL).

J'ai du mal à conceptualiser la façon dont je dois architecturer mon appli et notamment la partie réseau :

L'URL accessible par les clients (donc port 80) devra arriver jusqu'à mon routeur où, selon le client, cette URL fera l'objet d'une redirection vers mon serveur d'application.
Le client 1 accèdera à l'instance de l'appli mappée sur le port 8081
Le client 2 accèdera à l'instance de l'appli mappée sur le port 8082
etc.

D'autre part, certaines fonctionnalités seront accessible via des web services.

Je suis preneur de toute bonne idée, tout retour d'expérience, car c'est la première fois que j'ai à gérer ce type de problématique.

Merci d'avance pour vos éclaircissements.

[ddoumeche]

Les divergences applicatives sont t'elles tellement significatives qu'il faille N versions de l'application ?

Pour moi, ce genre de chose se gèrent avec du paramétrage au niveau du compte utilisateur, voir dans le pire des cas la coexistence de deux ou trois versions de l'application et un reroutage vers la bonne version au moment du login.

[Lovegiver]

Bonjour @ddoumeche et merci pour ta réponse

Tous les clients n'utilisent pas nécessairement les mêmes services mais tu as raison : l'application reste la même.

Je pensais que le fait d'instancier autant de fois l'appli qu'il y a de clients garantirait une bonne étanchéité et un bon cloisonnement du point de vue de la confidentialité et de la sécurité des données.
En effet, chaque client disposera de sa propre DB et il semblait approprié (mais je me trompe sans doute) que chaque DB soit accédée par une appli distincte.

Concernant ta suggestion, cela impliquerait de "sortir" les User de chaque DB client afin de constituer une base dédiée à l'authentification. A l'issue de cette authentification le User serait dirigé vers le contexte adapté, donc une instance spécifique de l'appli.
Comment fais-tu pour exécuter un contexte plutôt qu'un autre après authentification ?

++ et bon week end

[ddoumeche]

Bonjour @ddoumeche et merci pour ta réponse

Tous les clients n'utilisent pas nécessairement les mêmes services mais tu as raison : l'application reste la même.

Je pensais que le fait d'instancier autant de fois l'appli qu'il y a de clients garantirait une bonne étanchéité et un bon cloisonnement du point de vue de la confidentialité et de la sécurité des données.
En effet, chaque client disposera de sa propre DB et il semblait approprié (mais je me trompe sans doute) que chaque DB soit accédée par une appli distincte.

Concernant ta suggestion, cela impliquerait de "sortir" les User de chaque DB client afin de constituer une base dédiée à l'authentification. A l'issue de cette authentification le User serait dirigé vers le contexte adapté, donc une instance spécifique de l'appli.
Comment fais-tu pour exécuter un contexte plutôt qu'un autre après authentification ?

++ et bon week end

Si tu veux un cloisonnement réellement total, tu peux faire une BDD par client, ce qui s'appelle du sharding et a l'avantage de pouvoir monter en charge en multipliant le nombre de serveurs de BDD, et de pouvoir maintenir N versions de ton/tes applications ... mais attention c'est complexe à gérer.

Si tu instancies autant d'applications que de clients, ta consommation mémoire serveur va exploser, sachant qu'aujourd'hui la moindre petite appli fait 500 Mo. Et je ne parle pas des patchs sur le code source, quand tu vas devoir appliquer 20 lignes de correctifs à 500 clients, donc à 500 codes sources.

Tu dois effectivement extraire les noms des utilisateurs, en utilisant par exemple leurs emails comme login (ce qui te garantit l'unicité), ce qui n'est pas choquant pour du Saas. Une fois authentifié, mets leur un cookie magique indiquant la version favorite, et renvoie-les à la bonne page (client-application.com/dashboard), le cookie étant utilisé par le redirecteur pour déterminer la bonne version.
Par expérience, je te conseille aussi de stocker les préférences dans la même base physique que les logins.

Vu qu'une url, c'est un contexte, c'est la redirection qui choisit le bon contexte. Tu peux utiliser mod-proxy pour cela, qui est plus souple que mod-jk, ou carrément écrire ton propre rerouteur.
C'est une architecture de base qui ne prend pas en compte les questions de haute-disponibilité bien, mais cela ne gène en rien.

une image vaut 10³ mots :

[Lovegiver]

Ton approche est très intéressante et je souhaite te remercier pour le temps que tu m'as consacré.
Je commence à regarder mod_proxy pour voir comment exploiter au mieux cet outil.

Dans l'hypothèse où tous mes clients utiliseraient la même application (versus une instance par client), comment gérer les lectures/écritures dans la DB ?

Je vais préciser ma question afin d'être plus clair :

Sans faire de sharding je vais faire en sorte que chaque client ait sa propre DB. Pour cela je vais m'appuyer sur PgSQL qui permet de multiplier les serveurs de DB.

Comme je compte utiliser Spring, j'ai vu qu'il était possible de travailler avec plusieurs DataSources, ce qui est plutôt positif dans mon cas.

Maintenant que j'ai 1 appli pointant vers N bases de données (1 par client), comment indiquer à Spring qu'un INSERT dans la DB doit être réalisé dans la DB du client1 plutôt que dans celle du client2 ?

D'autre part, dans l'hypothèse où je rajoute un nouveau client, je vais créer une nouvelle DB dans PgSQL, mais comment déclarer cette nouvelle DB à l'application ?
Est-ce qu'un fichier de paramètre peut suffire, fichier que l'on pourrait enrichir sans avoir à rebooter l'application ?

[tchize_]

Si tu utilise spring, et que tu n'a pas de singletons (sesion ou request bean seulement), alors, lors de l'instanciation des DAO, tu va leur filer normalement un datasource à utiliser. Il suffit que le datasource choisi soit le résultat d'un appel de méthode dépendant de l'utilisateur. Ainsi le DAO pointe sur la DB de l'utilisateur en cours de traitement. L'inconvénient du coup, c'est que c'est au revoir les DAO en singleton, ceux là sont configurés une seule fois.

Personellement, sur les applis multi-client que j'ai géré par le passé, on gérait plus ça au niveau logique. Les données propres à un client possédant une colonne clientId, et les requêtes incluant systématiquement le clientId. Ca permet accessoirement aussi de gérer plus facilement les client qui fusionnent suite à une acquisition