| Avertissement | ||
|---|---|---|
| ||
La mise à disposition de Esup-Multi en Mode SAAS est en cours de réflexion n'est pour l'instant qu'hypothétique et implique une étape de réflexion sur les attendus, les contraintes et les limites. |
Hébergement du backend en mode SAAS
Nous proposons un hébergement en mode SAAS de :
- La gateway et l'ensemble des microservices de l'application
- Le sereveur serveur NATS
- La base Mongo
- La base Redis
- Le CMS Headless
La configuration des microservices nécessitera l'implication de l'établissement
| Remarque |
|---|
Quid de la pwa ? |
=> La PWA sera . La version web de l'application sera également disponible à partir du moment où le thème multi sera fournit par l'établissement.
Les connecteurs SI
On maintient les connecteurs SI dans les établissements.
Les connecteurs qui fournissent les données issues du SI restent dans les établissements et devront respecter les formats d'entrée et sortie attendus. Il faudra ouvrir un accès à ses ces connecteurs aux serveurs hébergeant le backend. Il faudra également faire attention à la tenue en charge de ses ces services grâce à des tests de charge.
On peut imaginer une exception pour le connecteur restaurant si et seulement si ce dernier ne s'alimente que des flux du CROUS (peu lié au SI et déployable facilement en SaasSAAS)
...
...
Quid de l'auth et du CAS ?
=> L'API CAS devra être accessible au serveurs hébergeant le backend.
| Remarque |
|---|
Stockage du mot de passe etc. ? Quid du SMTP pour l'envoi de mails de contact ? |
Les applications clientes
...
2 possibilités :
- Soit on maintient la publication des applications clientes dans les établissements.
- Soit le mode SAAS inclut la publication sur les stores (une fois le thème fourni)
L'établissement devra personnaliser le look en créant un thème et compiler les deux app natives iOs et Android
...
| Remarque |
|---|
Quid de la synchronisation Front-end Back-backend ? |
En mode Saas SAAS comme en mode On prem, il faut que lorsqu'une évolution est faite sur le backend, ce dernier devra rester compatible avec (au moins) la version précédente du client afin de laisser le temps aux utilisateurs de mettre à jour leur applications clientes
Quoiqu'il en soit, les universités devront suivre les évolutions de l'app pour mettre à jour les clients et synchroniser une mise à jour avec le backend avec l'hébergeur.
| Info |
|---|
Voir si dans un second temps on peut automatiser le déploiement sur les stores par un outil intégré à la CI : Fastlane / CodeMagic / App Flow |
Et si on veut développer et ajouter ou corriger une fonctionnalité ?
Alors Pour cela on passera par le processus de contribution. L'établissement devra partager sa contribution qui sera intégrée au code de l'application.
On ne pourra pas proposer en mode SAAS une contribution qui ne serait pas intégrée au projet et disponible à la communauté.
Et techniquement ?
Un backend complètement cloisonné avec un dns dédié qui pourra évoluer indépendamment des autres instances SAAS.
Tests de charges?
Sizing ?
Et côté RGPD
Données personnelles stockées : En mode SAAS, les données SI restent hébergées dans les établissements seules les données concernant l'auth et permettant la réauth sont hébergées en SAAS.
Et combien ça coute ?
Ailleurs :https://www.esup-portail.org/destination-le-cloud