vendredi 9 mars 2012

Architecture Web Stateless et Stateful avec Ineat Conseil

Le 23 février 2012, le Ch'ti JUG avec le soutien de la société Inéat Conseil, a organisé au pôle Euratechnologie une soirée sur le thème Stateful Vs. Stateless.
À ma gauche, Thomas Recloux (@thomasrecloux), short bleu, qui va montrer qu'utiliser la session n'est pas une fatalité.
À ma droite, Antoine Sabot-Durand (@antoine_sd), short rouge, qui va réhabiliter le stateful en revenant au fondammentaux de Java EE.

Voici mon résumé du match.

Quel match?

Ce ne fut pas réellement un match comme annoncé mais plutot un état des lieux des 2 approches selon moi.

L'approche Stateless

Ce terme inexact concerne le développement d'une application Web sans utilisation de la mémoire attribuée par le serveur et dédiée à la conversation avec le client. En effet, lors de l'utilisation de ce genre d'application, comme par exemple un site de vente en ligne, cet espace permet de concervé une trace des articles déposés par exemple dans le panier de l'internaute, jusqu'au moment fatidique de la commande.

Quid de la montée en charge?

Hors ce mode de fonctionnement a toujours eu un gros défaut, c'est la gêne occasionnée lors de la montée en charge. En effet afin d'assurer un confort optimal aux utilisateurs et parce que la puissance des ordinateurs a une limite à un instant t, il est d'usage d'avoir recours à une "ferme de serveur" capable de répartir la quantité d'utilisateur. Ce qui lève le problème de cet espace mémoire qui lui reste sur un seul serveur.
Il y a donc des solutions permettant de resoudre cette problèmatique mais ne faisant qu'alourdir l'architecture déja bien complexe de ce genre d'application. C'est d'ailleur ce qui à populariser cette démarche avec la mise en ligne d'application de réseau sociaux devant servir toujours plus de client sans pour autant nuire à la qualité du temps de réponse qui a forcer les développeurs de ces applications à ce séparer de la session.

L'utilisateur à 3 têtes

Un nouveau défaut vient s'ajouter au précédent avec la popularité des navigateurs alternatifs à Internet Explorer. Ils ont apporter depuis longtemps la capacité de naviguer le Web grâce à plusieurs onglets. Cette fonctionnalité tellement appréciée qu'elle à finit par être incluse même dans Internet Explorer. Dans ces conditions, tout internaute est capable de naviguer un même site avec plusieurs onglet: Je regarde les articles qui me plaisent, j'en ouvre certains dans des onglets distinct pour les garder à l'oeil. Ce qu'il faut savoir à ce moment précis, c'est que le serveur n'a aucunnement consience de la quantité de fenêtre ouverte par l'utilisateur. En effet ce dernier ne fait que traiter les requête transmise par le navigateur. Et ce scénario n'est pas juste restreint au site Web.
J'ai récemment du aider les développeurs d'une application d'un de nos clients, ce dernier souhaitant pouvoir utiliser plusieurs fenêtres / onglets pour que ces utilisateurs puissent traiter différents dossiers en parallèle. Cette satanée session ne pouvant contenir qu'un seul dossier à la fois, il est impossible de gérer simplement la gestion parallèle de plusieurs dossiers sans faire preuve d'imagination pour la conception d'une solution.

Et bien d'autres ...

Je ne cite que les cas d'utilisation les plus parlant pour l'adoption de cette approche mais il y en a bien d'autre.

C'est donc une présentation très concrète, mettant en avant les limitations du stateful et les solutions apportées par le stateless. Mais également les limitations du stateless, surtout avec Spring MVC / Security, ainsi que les solutions de contournement adéquates.

L'approche Stateful

Cette seconde présentation fut quant à elle tournée sur les nouveautés dans le monde JEE, notamment les apports mutuels avec Spring Framework dans la spécification Java Entreprise.
Ce fut également l'occasion pour le speaker d'indiquer que le stateful est décrié par les développeurs parce que ces derniers ne seraient pas objectifs en utilisant Spring Framework, celui-ci est résolument orienté vers le Stateless. Remarque pertinente.
Enfin, nous avons pu jetter un oeil sur la dernière version de JBoss (7.1), toujours aussi ... lent comparativement aux conteneurs légers tel que Tomcat ou Jetty.

Comment ça je ne suis pas objectif?

On constatera aisément pour qui irait ma voix en cas de vote, compte tenu de la richesse de mon argeumentaire sur le stateless vis à vis du stateful. J'espère que d'autres auront un avis différents, si tel est le cas n'hésitez surtout pas à vous manifester en commentant ce billet.

<troll> Je terminerai juste en indiquant mon score de ce non match : 7 - 1 </troll>

4 commentaires:

  1. Je n'étais pas présent malheureusement...
    7-1 !? Mais c'est la raclée!? est-ce qu'il y a eu du sang au moins?

    J'attend avec impatience la vidéo de ce Chti JUG pour faire mon propre comptage des points :-)

    RépondreSupprimer
  2. C'est dommage, tu casses du sucre sur le statefull sans nous dire comment le stateless en résout les inconvénients...et sans parler des inconvénients du stateless.
    Tu es au moins honnête en écrivant que tu n'es pas objectif ;).

    RépondreSupprimer
  3. Je pense que cet article manque plus de maturité que d'objectivité.
    Bien que défenseur des architectures stateless, je considère que réaliser une application stateful n'est pas une hérésie, même en 2012, et ce pour plusieurs raisons qui semblent ne pas être connue ici :
    - tout le monde ne construit pas une application destinée à etre utilisée par plusieurs millions d'utilisateurs... faut arreter le fantasme. Avant de mettre à genou un serveur, sauf à être un manche en développement, faut quand même y aller.
    - une application stateful n'empeche en RIEN une gestion conversationnelle sur plusieurs onglets, faudra revoir les classiques (exemple trivial : spring webflow)
    - la scalabilité est tout à fait possible avec une application stateful sans grande difficulté... 2 approches pas forcément exclusives : scalabilité horizontale ou verticale. Dans le cas de la verticale, un équilibrage de charge avec affinité de session, c'est quand meme pas bien complexe à mettre en oeuvre...
    - une application stateful ne s'heurte pas à la limite de puissance des serveurs (qu'est-ce qui empeche de faire du calcul distribué ? => rien), à la mémoire effectivement

    En conclusion : il faut oublier cette idée une bonne fois pour toute, appelée "one size fits all". Non, l'approche stateless n'est pas la réponse la plus simple ou efficace à tous les problemes (essayez justement de modéliser un webflow stateless...), et oui une approche stateful peut être plus pertinente dans certains cas (économiquement par exemple car potentiellement plus rapide à réaliser).
    Et surtout, il y a bien pire qu'une application stateful : c'est une application stateless mal conçue, car dans ce domaine, le meilleur côtoie souvent le pire.

    RépondreSupprimer
  4. Merci pour cet article, ca me fait toujours plaisir quand je lis des comptes rendus de Ch'ti JUG. Ne serais-ce que pour ceux qui n'ont pas pu y être et pour avoir des retours d'utilisateurs tout simplement ;-)

    Personnellement j'ai particulièrement apprécié la présentation stateless dont le contenu était très pertinent et qui donnait une bonne vision d'ensemble de la problématique. J'ai trouvé que la partie stateful était un défi plus complexe à relever car c'est plus difficile de convaincre sur ce terrain mais les arguments et les exemples étaient là et on a bien vu que le stateful a encore de beaux jours devant lui, que ce n'est pas si compliqué et qu'il est pertinent dans de nombreux cas. Dans l'ensemble, j'ai trouvé que les présentations manquaient un peu de pêche par moment mais que le contenu était travaillé et intéressant.

    Bravo aux 2 speakers car ce n'était pas un exercice simple, car c'est un sujet récurrent ou beaucoup de monde à son mot à dire!

    PS: JBoss 7.1 démarre moins de 3 secondes ;-)

    Je dirai plutôt 3 - 2 comme résultat du match final

    RépondreSupprimer