en faisant un peu de veille, je suis tombé sur un billet évoquant les modalités de déploiement d’une webapp tomcat dans un environnement Kubernetes (How To Host Tomcat In Kubernetes? - GeeksforGeeks).
Serait-il envisageable de déployer une instance Simplicité selon les modalités évoquées ? Y-a-t-il des contre-indications / incompatibilités qui empêcheraient ce type de déploiement ?
Nota bene: il s’agit d’un sujet de veille (évoqué lors du dernier club-utilisateur) qui n’a pas de priorité particulière. Il s’agit d’une réflexion “à froid” / “moyen terme”.
Nous sommes loin d’être des experts K8S mais il me semble que l’article décrit une sorte de load balancing qui ne dit pas son nom.
Il ne parle pas de session Tomcat ni, donc, de routage sur les noeuds Tomcat par session ou d’un mécanisme de partage des sessions entre les noeuds Tomcat.
Or, pour mémoire la UI Simplicité a besoin de sessions au sens Tomcat, i.e. que toutes les requêtes HTTP d’une session aboutissent sur le même noeud Tomcat (d’où notre recommandation de load balancer en mode “sticky sessions” pour les noeuds correspondant à des usages UI) ou que cette session soit accessible de tous les noeuds Tomcat (ce qui a ma connaissance n’a pas encore été fait avec Simplicité et ne sera donc sans doute pas sans impacts potentiels, sans parler du coût technique d’un tel partage de session qui mérite d’être mesuré vs les gains théoriques attendus d’un load balancing en mode “non sticky sessions”)
En revanche les usages API n’ont donc pas besoin de session Tomcat donc un load balacing “non sticky sessions”, quel qu’il soit, ne pose pas de problème aux usages API.
Je comprend que le sujet est globalement complexe et nécessitera un traitement selon des stratégies différenciées selon les cas d’usage (UI/API) et les orientations retenue pour localiser les sessions utilisateurs (navigateur, agent REDIS centralisé, …). Cette diversité de cas de déploiement devra aussi être gérée par ailleurs. Bref, c’est une question d’architecture…
Pour les usages API j’aurais tendance à dire que peu importe l’architecture
Pour les usages UI il faut une architecture qui permet de respecter le principe d’une session Tomcat (avec toujours mon bémol sur une architecture avec partage de sessions car ça n’a pas encore été fait et je reste très perplexe sur le gain potentiel vs le coût de partage des données des sessions)
Dans tous les cas il faut se rappeler que le bottleneck restera toujours la base de données, i.e. il ne sert strictement à rien (voire c’est contre productif) de déployer N noeuds Tomcat si la base n’est pas dimensionnée en conséquence