Les amis, la mode en architecture en 2011 va être à la simplicité. Terminé ces dernières années où nous avons construit des architectures distribuées en cluster load-balancé pour seulement 10 utilisateurs, pour remplir des états comptables ou des fiches d’assurance. Oui, je vous le dis bien fort et bien profond : nous allons faire des choses simples comme les autres le font.
Donald Ferguson, CTO de CA Associates déclare dans cette interview qu’IBM Websphere est la plus grose bourde technique qu’il a créé. Notez que nous le savions tous depuis longtemps, mais cela fait plaisir de voir ce type de déclaration de la part d’un CTO dans la presse.
Q: What’s the biggest technology mistake you ever made – either at work or in your own life?
A: When I was at IBM, I started a product called Websphere [which helps companies to operate and integrate business applications across multiple computing platforms].
Because I had come from working on big mission-critical systems, I thought it needs to be scalable, reliable, have a single point of control … I tried to build something like a mainframe, a system that was capable of doing anything, that would be able to do what might be needed in five years.
I call it the endgame fallacy. It was too complex for people to master. I overdesigned it.
Because we were IBM, we survived it, but if we’d been a start-up, we’d have gone to the wall.
Ce n’est que grâce à l’acharnement thérapeutique d’IBM, trop content de vendre de la complexité, que ce logicel continue aujourd’hui à faire vivre bons nombres d’applications et de DSI qui ne diront jamais qu’ils se sont plantés. C’est aussi un produit largement « recommandé » par les équipes d’exploitations, qui viennent juste de certifier à grand frais toutes leurs équipes. Imaginez si vous débarquez avec un petit Tomcat, voire même, soyons fou, une application avec Play! Framework ?
A propos de Play! Framework, Habib Guergachi de Zenexity expose un point de vue novateur sur la question de la complexité.
Dans une vidéo de 2 minutes sur le site de « Zengularity« . Dans sa présentation il nous interroge sur la pérennité de l’approche classique dans le monde de l’architecture logicielle. Est-ce qu’une approche Web ne balayera pas demain les concepts d’architecture, voir les logiciels classiques dans le monde de l’entreprise ?
J’ai essayé d’envisager un futur où nous serions désintoxiqués de la complexité.
Est-ce que cela tient vraiment la route ?
Le temps de la désintoxication et de la simplification
Imaginons dès maintenant une nouvelle approche uniquement basée sur l’architecture Web. Oublions un instant les standards JEE et les frameworks du marché pour imaginer une architecture purement web. Qu’est-ce qui coince ?
Pour faire simple, il faut savoir faire simple. Mais c’est compliqué.
L’architecture pilotée par les frameworks apporte plusieurs risques :
– la perte du savoir-faire, de la connaissance ou de la compréhension du niveau caché par le framework.
– la nécessité de s’adapter au framework et son architecture, plutôt que de faire ses choix d’architecture.
– l’obligation de gérer une dette technique sur ce framework dans quelques années.
– le risque de ne pas jouer le bon cheval et de se retrouver dans une impasse technique.
– la difficulté à faire cohabiter certains frameworks qui n’ont pas les mêmes cycles de mise à jour.
– la difficulté à trouver des ressources compétentes sur l’ensemble des socles techniques.
Au vue de cette liste, certains vont penser que je charge un peu fort la barque. J’essaye d’attirer votre attention sur les effets indésirables d’un framework. A petite dose c’est profitable. Mais à haute dose, vous vous intoxiquez.
Je pense que nous devons revenir à un peu plus de simplicité. Après tout, nos clients se fichent pas mal de savoir que telle ou telle technologie fonctionne sur le serveur. Ce qui fait la différence ? L’expérience utilisateur. J’ai un peu le sentiment que parfois, nous nous battons sur l’idée que la cuisson au gaz est mieux que la cuisson à l’électricité, alors que le client veut juste manger. Et qu’il s’en fiche complètement. Croyez-moi, on est bien seul lorsque l’on parle de technologie à l’utilisateur final. Le client final se fiche de la complexité.
Oui mais…
Contre-argument à ce que je viens de dire : oui mais il n’acceptera pas que son service ne soit pas disponible lors d’une mise à jour. Il ne pourra pas accepter que le service ne fonctionne pas de temps en temps. Enfin pour certains métiers, il sera nécessaire de garantir que ses données sont bien sauvegardées…
L’architecture jetable et évolutive
Essayons une autre stratégie complètement anti-écologique : pas de recyclage, uniquement du jetable. Prenons comme idée que l’architecture (ce qui est compliqué à changer selon M.Folwer) d’un logiciel est jetable. Chaque logiciel est unique, comme la construction d’un bâtiment. En conséquence l’architecte doit veiller à ne pas créer de dettes techniques afin que le logiciel puisse évoluer et grandir.
Pour faire du jetable, il va falloir changer ses habitudes. Par exemple ne pas forcément penser en couche, sans recul et sans comprendre pourquoi vous découpez votre code. Il y a eu un moment un mythe selon lequel une architecture logicielle en couche permettrait une meilleure réutilisabilité du système. Or c’est faux. Personne ne réutilise votre logiciel. Je vous le dis très franchement : votre projet ne sera pas réutilisé par l’équipe d’en face. Car votre documentation est tellement mauvaise, que votre découpage ne sert à rien. La maintenance de votre code ne sera pas meilleur avec un découpage. Elle sera meilleure car le développeur qui fait la maintenance est meilleur. Essayez de penser à tout cela au calme. Regardez vos projets passés. Et dîtes moi franchement si vous avez vu du code réutilisé.
On met des couches dans une architecture pour deux raisons : soit on pense que c’est un moyen de garantir l’évolutivité, soit on souffre d’incontinence. La magie de la langue française est que ma proposition fonctionne pour les deux :
– si vous êtes jeunes, vous mettez des couches car on vous a dit de le faire
– si vous êtes vieux, vous ne pouvez plus vivre sans celles-ci, mais vous ne savez plus pourquoi vous en mettez… dans chacune de vos architectures.
Une architecture est plutôt l’expression d’une vision. Elle doit permettre les évolutions. C’est son seul et unique rôle. Je vois plus l’architecte comme un jardinier finalement, qu’un constructeur d’immeuble. Il doit s’attacher au quotidien à garantir la qualité du socle de son logiciel. Il doit avoir cependant une vision neuve à chaque projet. Ce qu’il réutiliser ce ne sera jamais du code, mais plutôt des pratiques ou des patterns. Son savoir-faire compte autant à mon avis que son seul savoir.
La complexité doit être un choix. Elle ne doit pas être imposée par une équipe d’exploitation.
Le choix d’un serveur d’application peut avoir de lourdes conséquences sur un projet. Bien souvent, un serveur d’application complet vous impose une complexité qui n’est pas forcément nécessaire. En conséquence, il faut désintoxiquer vos équipes d’exploitation si celles-ci vous imposent ce type de choix.
Il y a souvent des choix imposés. De plus en plus d’équipes d’exploitations vont vous demander d’utiliser tel ou tel serveur d’application Java. J’en appelle à tous les DSI qui lisent le Touilleur Express : c’est une énorme connerie. Si votre équipe de support ou d’exploitation fait les choix d’architecture, croyez-moi vous ne faîtes pas votre boulot correctement. Je suis convaincu que les choix d’architecture doivent être décidés et discutés avec les équipes d’exploitation pour chaque projet, le plus tard possible. En prenant un serveur d’application Java standard, nous pensons que nous réaliserons une économie. Or vue la vitesse à laquelle évolue les technologies, vous risquez d’accumuler une dette sur votre plateforme d’exploitation dès le départ.
Il est donc indispensable de retarder au plus tard le choix d’un serveur d’application..
Peut-être que d’ici 2 ans, ils seront inutiles.
Les serveurs d’applications J2EE.
C’est vrai que cela fait un peu année 2000 parfois…
Une architecture Web
Après avoir bien chargé ce qui, au passage, me fait travailler, voyons un peu ce que l’on peut faire en 2010.
Regardons dans le futur.
Dans quelques années, les services de la DSI seront exposés comme de simples services Webs. Les différents protocoles de vos différents WebServices auront disparu. Finalement, nous ferrons ce que font Google, Yahoo ou Flickr vous proposent déjà : chaque équipe métier proposera une API Web très simple, avec une architecture de type REST sans état. Nous utiliserons le protocole HTTP, le seul qui passe les firewalls du monde entier. Nous utiliserons des petits serveurs Webs sans état, avec une base relationnel ou des données dans le Cloud. Mais le vrai Cloud sera dans l’entreprise, pas chez Amazon. La majorité des entreprises pour les quelques années qui viennent continueront à exploiter des machines et des serveurs… au moins pour les 10 ans qui viennent.
Les serveurs d’applications avec état vont disparaître. Plus précisément les frameworks avec une session du côté du serveur. L’essor du HTML5 offre la possibilité de stocker des informations de sessions dans le navigateur. Et entre une base de données et un navigateur, il devient inutile de stocker quoique ce soit sur le serveur. Il faudra donc privilégier l’approche où le serveur est sans état. Imaginez l’univers de simplicité que cela offre : pas de problèmes de réplications de sessions, pas de soucis de données non à jour par rapport à la base, pas de problèmes de montée en charge ou de gestion de mémoire.
Mais attendez… ça existe déjà non ?
Est-ce à dire que nous revenons au client lourd avec HTML5 ?
Après avoir joué pendant quelques années avec le web, qui est sans état, nous revenons au client lourd. Il y aura encore quelques vendeurs pour essayer de nous vendre des trucs compliqués. Mais je pense que l’architecture des solutions en entreprise sera plus proche de ce qui fait le succès des grands du Web.
Le futur sera plus simple, moins intoxiqué et englué dans les frameworks. La DSI doit s’adapter et proposer je pense des solutions simples, au risque de se faire doubler par des équipes clientes, qui en auront marre du dogmatisme technique, de la vision d’architecture à papa, et qui voudront simplement des solutions, pas de nouveaux problèmes.
Franchement, cet article tombe à point nommé.
J’avais un besoin urgent de le lire, et çà fais du bien.
Certains pourront être choqué de ces propos, mais n’empêche, la vérité fais souvent cela 😉
Attention tout de même au syndrome NIH (Not Invented Here). L’abus de frameworks peut être nocif pour la santé, mais il ne faut pas non plus tomber dans le syndrome « je fais tout tout seul » et se mettre à réinventer la roue.
Pour ce qui est de la simplicité, c’est compliqué, je dirai même qu’il faut une sacré dose de courage pour rester simple. Lorsqu’on met en place le framework ABC qui répond bien aux besoins des itérations 1, 2, 3, 4 et 5 du projet, il faut une sacré dose de courage pour virer ce framework à l’itération 6 lorsqu’il n’est plus approprié. Comme on ne le fait pas, on se traîne un framework inadapté pour les itérations suivantes, et ça, ça apporte de la complexité.
Je suis d’accord sur au moins une chose, rien n’est plus compliqué que de faire simple.
2 citations qui résument ma pensée (il faut beaucoup d’expérience pour comprendre réellement ce que cela signifie amha) :
“Everything should be made as simple as possible, but no simpler. »
« Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius — and a lot of courage — to move in the opposite direction. »
Bonsoir,
Article très intéressant!
Vous dites que ce que l’on réutilisa ce sont des bonnes pratiques et des patterns, ben si au lieu de les coder on les génère?
Si on se focalisait plutôt sur la modélisation des données, des process, des IHM et des services Web à exposer?
Car c’est bien ça qui préoccupe les end-users au final? Non?
Bah tout ça ça a un nom : L’ingénierie des modèles!
A méditer 😉
Si on se focalisait plutôt sur la modélisation des données, des process, des IHM et des services Web à exposer?
==> à des fins de génération de code bien sur!
Excellent article Nicolas, c’est frais, rafraîchissant, et plein de promesses pour la nouvelle année à venir 🙂 .
« Dans quelques années, les services de la DSI seront exposés comme de simples services Webs. »
=> finalement, ça ressemble quand même beaucoup à la promesse initiale des SOA, non ? On peut tout à fait faire du REST « complexe » et « in-maintenable ». On peut tout à fait faire du SOAP sans état. Je ne veux surtout pas défendre SOAP, les WS & cie, mais à mon avis c’est plus un problème organisationnel que technique.
Dans le monde JEE, ce qui prend du temps, c’est bien souvent les problématiques d’intégration. « Comment je fais du HTML5 en GWT communiquant avec des services exposés par Grails hébergé sur AppEngine avec une base orienté documents ? »
Effectivement, les frameworks dits « fullstack » apportent un sentiment de grande productivité dans un premier temps, car les problèmes d’intégrations ont déjà tous été résolus. Jusqu’à ce que je souhaite intégrer telle fonctionnalité non disponible dans le framework.
Je m’interroge sur la voie à suivre… + de modularité ? => + d’intégration. + de « jetabilité » ? Les pistes sont bienvenues…
Effectivement, je pense aussi que ça va pas mal bouger de ce côté là en 2011. Attention tout de même à ne pas « enfumer » les gens en voulant tout jeter à la poubelle sous prétexte de simplicité.
Exemple concret : la très bonne vidéo d’Habib sur les EAI/ESB (http://www.zengularity.com/item/1650674910/eai-esb-napportent-rien-si-les-applications-ne-sont) qui est très intéressante et pertinente 95% du temps et qui sort dans les 30 dernières secondes une conclusion qui arrive dont je ne sais où pour justifier sa position qui consiste à dire que tout ça ne sert à rien.
Les approches systématiques (dans un sens ou dans l’autre) conduisent souvent dans le mur pour des projets de tailles moyenne ou importante.
Pour notre part, la solution qu’on a commencé à implémenter pour trouver le juste milieu dans RESThub est la suivante :
– Construire sur base d’une stack de technos basée sur Spring3 (en l’utilisant via des annotations standards JEE6) un framework Java Fullstack dans lequel on peut remplacer n’importe quelle brique très simplement
– Définir une stack Javascript permettant de faire des interfaces RIA HTML5 utilisant des webservices REST stateless en utilisant jQuery, Sammy.JS et Jersey.
Le stateless avec la front côté serveur proposé par Play! n’est que, à mon avis, une solution temporaire bien que très pratique. Pour faire du vrai stateless côté serveur, il faut forcément passer le front (MVC) côté client.
On a encore du boulot pour simplifier la partie front, mais on y travaille 🙂
Beaucoup de vérités mais un vœu malheureusement bien pieux que celui de la simplicité et du pragmatisme ! Perso je pense que cette complexité est voulue, consciemment ou inconsciemment, par la majorité des acteurs.
Voici, de façon volontairement provoque, ceux qui selon moi cautionnent cette complexité :
– Les grosses SSII, pour lesquelles il vaudra toujours mieux vendre 500j de dev JEE / Websphere / Oracle que 150 jours de Windev même si l’appli ne sera jamais réutilisée, que les composants promis génériques de le seront en fait jamais etc…
– Les petites SSII spécialisées qui voient là un moyen de vendre des consultants à des tarifs de spécialistes sous prétexte qu’ils savent traficoter le fichier XML cryptique non documenté, de se faire buzzer à coup de white paper pour DSI naifs ou de slideware auprès de développeurs réduits à l’état de disciples, parfois au point d’en être prosélite (non, je ne ferais jamais de Microsoft, c’est le mallllllllll ! Il faut faire de Statelesssssss sinon t’est un has been !)
– Les « Geek » qui, au final, se délectent de cette complexité et ne cessent se faire des articles sur « framework X versus framework Y », de se branler sur le fait que Globalus est plus performant que Tartifio dans les appels RPC via une stack OSGI forkée. Mais auront-ils l’honneteté de le reconnaitre…Ne faudrait-il pas que la séparation « le métier » / « les développeurs » que l’ont voit dans bcp trop d’entreprise cesse ? Ne faudrait-il pas que les développeurs soient impliqués dans le métier pour que leur but soit la solution finale, l’utilisateur…et pas le façon dont leur framework sérialise en JSON…
– Les DSI, qui ne sont souvent plus que des gestionnaires : ils ont besoin de justifier le maintien de leur budgets et adorent lire 2 ou 3 termes techniques hype dans 01 info pour impressionner leur homologues qui, les pauvres, en sont encore à faire de l’EAI ou des EJB ! Les nuuuuuuuuuuuuuls !
– Les Architectes, en particulier des grandes banques et autres administration, qui imposent des normes de code ou de sécurité d’une complexité démente, qu’ils adorent définir comme « non né go cia bleuuuuuu! »…tout en laissant des trous béants juste a coté !
– Je ne parle même pas des éditeurs…
Ok, je provoque un peu…mais tant que ça ?
Version « spellchecked » de mon message précédent, on s’emballe qd on parle avec le coeur des fois 😉
Beaucoup de vérités mais un vœu malheureusement bien pieux que celui de la simplicité et du pragmatisme ! Perso je pense que cette complexité est voulue, consciemment ou inconsciemment, par la majorité des acteurs.
Voici, de façon volontairement provoque, ceux qui selon moi cautionnent cette complexité :
– Les grosses SSII, pour lesquelles il vaudra toujours mieux vendre 500j de dev JEE / Websphere / Oracle que 150 jours de Windev même si l’appli ne sera jamais réutilisée, que les composants promis génériques ne le seront en fait jamais etc.
– Les petites SSII spécialisées qui voient là un moyen de vendre des consultants à des tarifs de spécialistes sous prétexte qu’ils savent traficoter le fichier XML cryptique non documenté, de se faire buzzer à coup de white paper pour DSI naïfs ou de slideware auprès de développeurs réduits à l’état de disciples, parfois au point d’en être prosélyte : non, je ne ferais jamais de Microsoft, c’est le mallllllllll ! Il faut faire du Statelesssssss sinon t’est un has been !
– Les « Geek » qui, au final, se délectent de cette complexité et ne cessent se faire des articles sur « framework X versus framework Y », de se branler sur le fait que Globalus est plus performant que Tartifio dans les appels RPC via une stack OSGI forkée… Mais auront-ils l’honnêteté de le reconnaitre…Ne faudrait-il pas que la séparation « le métier » / « les développeurs » que l’ont voit dans bcp trop d’entreprise cesse ? Ne faudrait-il pas que les développeurs soient impliqués dans le métier pour que leur but soit la solution finale et l’utilisateur…et pas la façon dont leur framework sérialise en JSON.
– Les DSI, qui ne sont souvent plus que des gestionnaires : ils ont besoin de justifier le maintien de leur budgets et adorent lire 2 ou 3 termes techniques hype dans 01 info pour impressionner leur homologues qui, les pauvres, en sont encore à faire de l’EAI ou des EJB ! Les nuuuuuuuuuuuuuls !
– Les Architectes, en particulier des grandes banques et autres administration, qui imposent des normes de code ou de sécurité d’une complexité démente, qu’ils adorent définir comme « non né go cia bleuuuuuu! »…tout en laissant des trous béants juste a coté !
– Je ne parle même pas des éditeurs…
Bonjour à tous,
Merci de cet article plein de bon sens.
J’aimerais partager quelques commentaires. L’industrie informatique est tenue par environ 10 acteurs majeurs qui ont formé un cartel. Leur métier: vendre des licences et obtenir les rentes récurentes qui vont avec tous les ans. Leur métier n’est pas de créer de la valeur pour les clients, mais de créer des tendances et de vendre de la tuyauterie (oracle et ibm en tête). Ils arrivent à nous faire croire qu’il faut changer d’outils our de techno tous les deux pour sauver un truc depuis une page web vers une base de données! Biensur, les intégrateurs suivent (dans la très grande majorité) et les DSI continuent d’investir sans jamais voir les retours espérés initiallement. A qui profite le crime?
L’informatique de gestion va entrer dans sa 30-40 ème année. Nous sommes une industrie très jeune en train de nous industrialiser. Il fallait 3 compilations et deux semaines pour mettre au point un programme de traitement batch en cobol en 1980. Il faut aujourd’hui 3000 compilations et 1 mois pour faire la même chose en 2010 en « nouvelles technologies ». La finalité n’a pas pourtant pas changé!
Quelques commentaires un peu provocateurs certainement:) Restons lucides! Joyeux noel a tous!
@Fred : Amen ! Sooooooo true !
Bonjour et Bravo! Article très intéressant, J’ai adoré.
J’adhère complètement aux concepts présentés ici et à la nécessité de repenser nos architectures. C’est quelque chose dont j’ai entendu parler la première fois sur le groupe de travail TSA présentant le concept de serveur fin (Thin server architecture) et de backend stateless.
Je rebondis également sur le commentaire de Sébastien très pertinent à mes yeux. Je crois dans un futur où l’on exposera de belles API Rest, où l’on développera deux applications différentes et stateless coté serveur avec des équipes frontend et backend, où l’on déplacera complètement la présentation coté client qui consommera du JSON et mise en forme via template JS (et une belle architecture MVC coté client).
Aujourd’hui, des solutions robustes existent. Designs patterns et bonnes pratiques sont en train d’émerger pour simplifier et industrialiser la partie front de nos applications. (Je vais dailleurs m’intéresser de près à RESThub, j’adore la philosophie et les choix des technos mises en place (Spring3 / sammy.js))
Bonjour,
je ne partage pas complètement votre point de vue dans la mesure ou je suis plutôt dans une position ou je préconise voire impose les architectures.
Je suis d’accord sur websphere.
Cependant, il ne faudrait pas oublier que le coût d’un logiciel est la somme d’une multitude de coût dont la supervision, l’exploitation, le maintien des compétences des équipes, la résolution d’incidents, l’assistance technique, …
Le développement du logiciel et sa maintenance ne sont qu’une partie du coût d’un logiciel.
Penser que seul l’architecte logiciel est le seul habilité et compétent à décider d’une architecture me paraît prétentieux et faux. Le logiciel n’appartient pas à l’architecte, mais à l’organisation qui va devoir payer le coût GLOBAL pendant des années.
Or la fragmentation technologique nuit aussi gravement à la santé d’une entreprise : les équipes exploitations n’arrivent plus à suivre les évolutions technologiques et ne disposent pas forcément d’un support compétent et pointu sur des solutions très spécifiques ou alors à des coûts exorbitants.
Quant au turnaround souvent conséquent dans les équipes de dev, on se retrouve avec des logiciels dont plus personne ne maitrise l’architecture au bout de deux ou trois ans.
La multiplication de solutions spécifiques est un cauchemard à moyen terme: j’ai connu des développeurs qui se retrouvaient à modifier le code source d’un serveur d’application Python parce qu’ils n’avaient pas prévu une évolution fonctionnelle et que ce serveur n’offrait pas cette fonctionnalité. Au départ, pourtant cette solution était vendu dans les même termes que votre article.
JEE n’est pas parfait mais avec JEE6 on arrive à niveau de simplicité qui est tout de même intéressant tout en étant un framework standard, documenté, …
Créer un webservice avec JAX-WS par exemple est d’une simplicité confondante.
Je suis aussi surpris par vos réflexions sur l’architecture en couche : avez vous été obligé de travailler avec un logiciel web bâti sans framework et sans pattern ? (une servlet qui fait tout de plus millier de ligne, des JSP ou on même vue, RMI, JDBC, …)
Je vous garanti que cela vaccine à vie et cela vous fait bien comprendre combien coûte ce genre de pratique.
Enfin, ce n’est pas à la faute aux frameworks si les développeurs sont sous-éduqués et ne savent plus faire la différence entre le pattern IOC et spring par exemple mais bien aux SSII qui prolétarisent leurs ressources . Le problème c’est qu’il y a tout un tas d’architecte qui préconisent des solutions qui tiennent plus du réflexe ou du marketing que d’un vrai travail d’architecte.
Cordialement.
Merci Nicolas pour ce papier plein de bon sens, qui respire le bon air frais de la sagesse. Ce qui me plait dans cette approche (à la fois la tienne et celle de Zenexity) c’est que le changement vient une fois de plus par la « bas » et non plus par le bullshit des vendeurs de solutions « miracles ». Je partage ton avis sur la question et j’ai pris sur moi d’arrêter de penser que Java/Spring/JavaEE (et consorts) étaient la panacé aussi bien pour un développement web, que pour un framework fonctionnel. Néanmoins, je pense qu’il est bon parfois de s’en remettre à un framework dont le but est de proposer un code fiable, testé et éprouvé par beaucoup d’utilisateurs. Mais aussi de disposer d’une architecture basée sur des patterns et du savoir-faire. En effet, tout le monde n’a malheureusement pas la chance d’avoir l’architecte et les développeurs capables de pondre un socle technique solide et réutilisable à la fois et donc je pense qu’il faut parfois s’en remettre à d’autres pour progresser.
Ulrich
Bonjour à tous,
Article très intéressant.
Je me demande juste la conséquence d’un allégement de tous les développements « usine à gaz »
A quel prix serait l’expertise d’un developpeur java ?
Ne va t’on pas perdre clientèle justement ? Serait ce, à terme, la fin de l’argent « facile » grâce aux usines à gaz couteuse à maintenir ?
Aussi autre question…
Ne va t’on pas perdre justement la vision de java actuel ? un empilement de framework ? pour une plateforme épuré ? Les personnes de chez Sun, JBoss et consort n’ont ils justement pas intérêt à tuer dans l’oeuf ce mouvement pour péréniser leur revenu ?
ps : dsl pour l’orthographe
De fait, on est à un tournant intéressant pour les développements logiciels sur le web, et plusieurs tendances se rejoignent et se conjuguent:
– pression sur les couts par le biais de la mondialisation
– effet additionnel de la crise (parfois la crise a du bon !)
– simplification de la plate-forme Java EE avec la dernière mouture v6
– changement spectaculaire attendu de la techno HTML auparavant stagnante depuis plusieurs années
– généralisation petit à petit des PF d’intégration continue et des PF qualité (Sonar, Squale, etc.)
– etc.
Donc, oui, on devrait encore profiter en 2011 d’une vague intéressante en matière d’innovations technologiques, vague (orientée vers plus de « légèreté ») qui ne fait que se poursuivre.
Là où je suis moins d’accord, c’est dans la disparition des serveurs Java EE. Appèle leurs successeurs comme tu veux, mais ils devraient sans doute être appelés « serveurs quelque chose », et vraisemblablement « serveurs Java EE v-quelque chose ».
Quant à se passer des frameworks, je n’y crois pas non plus, vu le temps précieux qu’ils peuvent faire gagner.
Après, je crois que tout est dans le juste milieu et la bonne appréciation de la valeur de tel ou tel choix suivant de nombreux et multiples paramètres (et c’est là où réside la complexité, même pour choisir un framework apparemment « simple ») :
– taille de la communauté d’un framework,
– dynamisme de la communauté,
– support possible d’une société,
– licence,
– respect des standards,
– respect des bonnes pratiques de développement
– documentation disponible
– anticipation ou non de l’évolution technologique (i.e. est-ce que le dit framework se situe dans la bonne vague ?),
– existence ou non de frameworks similaires,
– capacité de changement d’un framework à un autre (à travers la disponibilité d’interfaces ou non, par ex),
– criticité du choix du framework pour le succès du projet,
– connaissance de l’équipe en place,
– etc.
Bref, c’est la fameuse évaluation du cout du ROI, non seulement à court-terme, mais aussi à moyen-terme et à long-terme.
Reste que je suis d’accord avec l’optique de ton billet qui me fait penser à l’idée que je me fais de l’approche « good enough architecture » (sans doute pas loin de la « just enough architecture » si j’en crois le titre d’un livre « Just Enough Software Architecture: A Risk-Driven Approach »).
Il faudrait d’ailleurs peut être rédiger une sorte de manifeste ou de guide des bonnes pratiques pour une « good enough architecture ».
Personnellement, j’ai tendance à être horripilé par les développeurs qui multiplient les types de paramétrage possibles ou qui généralisent à outrance leur code, alors qu’ils n’ont tout au plus qu’un cas à prendre en compte et que leur logiciel n’est pas bien testé et qu’ils rechignent à écrire la documentation… Je préfère des développeurs qui maitrisent le refactoring, plutôt que ceux qui développent du code en plus, au cas où, i.e. au cas où ce qu’ils ont imaginé, mais qui a peu de chances de se passer, se révèleraient exceptionnellement une voie d’évolution du dit logiciel…
Article intéressant et le moins que l’on puisse dire et que la vision fait consensus chez les lecteurs du touilleur.
Du coup ça oblige vraiment à se remettre en cause.
Personnellement l’ensemble du billet passe pour moi sauf le dernier paragraphe « Une architecture web » qui pose question.
On parle de simplicité parce que serveur sans état et du coup je cite :
=> pas de problèmes de réplications de sessions,
=> pas de soucis de données non à jour par rapport à la base,
=> pas de problèmes de montée en charge ou de gestion de mémoire
Là j’ai atterri chez les Bisounours.
Donc ma question: Faut-il se désintoxiquer des frameworks côté serveur et des middleware pour mieux ingérer les frameworks javascript, le HTML5 et sa logique de client lourd (bdd locale, websocket…)? Je vois pas où est la simplicité, on déplace simplement la complexité (je n’ai pas de préférence entre gérer la session côté serveur ou côté client si il faut en gérer une).
Personnellement, je suis à 100% pour les architectures web. Par contre j’ai l’impression que le HTML5 marque une vrai rupture avec le HTML4 : Le HTML4 on pouvait en faire avec FrontPage (sic). Là ça redevient un truc ardu, complexe, pour le (bon) développeur quoi. Et finalement le navigateur web devient le middleware entre la page web (le DOM) et la BDD distante, du coup on risque de retomber dans les mêmes « travers » avec des délires d’architectures :
– multiplication de framework (c’est déjà un peu le cas, combien d’offre d’emploi de développeur web sans « bonne maîtrise de jQuery »?)
– programmation en couche
– …
« le futur sera simple » oui dans la vision de ce billet, très « client/serveur ». On occulte un peu la route qui nous achemine vers le web 3.0. Pour moi le futur des archi web c’est :
– aggrégation, consolidation, validation, transformation des données distribuées partout sur la planète.
Or ça se passera soit dans le navigateur soit sur un serveur, mais ça fera parti des + gros défis: L’architecture sera full-web oui, mais elle sera multi-agent avec des services qui apparaitront/disparaitront tous les jours. On aura surement notre lot de WebSphere dans ce mouvement.
Pour conclure, je suis d’accord pour « qu’on nous desintostique » (comme dirait Coluche) même si je trouve le terme un poil provocateur. J’attends de voir ce qu’on va nous donner à manger. Pour ce qui est « du temps de la simplification », je suis plus sceptique : pour moi ça sera radicalement différent mais pas plus simple.
C’est parfait. Le seul risque concerne la sécurité si la session est présente chez le client. Elle est complètement manipulable, modifiable, etc. Les services Stateless doivent en tenir compte.
@philippe il est possible de signer le cookie qui est échangé avec le client. En cas de modification de celui-ci, un framework web bien fait va l’invalider automatiquement.
Merci pour cet article plein de bon sens.
Les couches n’ont pas pour seul but de garantir l’évolutivité. Elles ont aussi pour but la maintenabilité et la testabilité.
Je rejoints Thibaud sur le déplacement de la complexité et sur sa conclusion.
@Dominique : est-ce que les serveurs Java EE v-quelque chose ça n’est pas justement de simples conteneurs de servlets avec les frameworks qui vont bien (Spring, Hibernate, GWT …) ?
@philippe @nicolas : je pense également la gestion de la sécurité sur des serveurs stateless est un élément clé, et comme le signale Nicolas des solutions existent pour gérer ça, ce qui ne veut pas dire que tout soit simple, loin de là.
Même si avec un peu de crypto, on arrive pour des cas simples à rester en stateless, dès qu’on a quelques droits à gérer, on doit gérer un état pour ces informations côté serveur, sous peine d’écrouler sa BDD très rapidement. Différentes solutions sont possibles (continuer à gérer une session avec un jsessionid juste pour la sécurité, utilisation d’un memcached …).
Pour ceux que ça intéresse, je vous conseille de suivre OAuth2 qui intègre ce genre de mécanisme. Des discussions sur la sécurité (OAuth2 est encore en draft) ont régulièrement lieu sur la liste de diffusion.
Au final, je pense que sur 2011, le vrai challenge pour la communauté Java va surtout être de monter en compétence significativement côté Front sur HTML5/CSS3 et surtout Javascript.
Je pense que c’est ce virage là qui va être dur à négocier, car culturellement on est moins front (du moins le croit-on) que les développeurs ROR ou PHP. Attachez vos ceintures 😉
« Et dîtes moi franchement si vous avez vu du code réutilisé »
Pas souvent, effectivement, à mon grand désarroi. Mais il serait peut-être intéressant de se demander pourquoi. Voici à mon sens quelques explications:
– les frameworks sont souvent trop techniques et il existe très peu de frameworks fonctionnels; un framework devrait inciter à développer des composants réutilisables
– problème de culture: rare sont les concepteur/développeurs qui font l’effort de concevoir/développer des composants génériques
– la pression sur les projets fait qu’on n’a pas toujours le temps
– rares sont les entreprises qui favorisent les échanges entre les projets; cela repose donc uniquement sur les individus
@Sebastien : complètement d’accord avec toi quant à la nécessité et l’urgence de monter en compétences HTML5/CSS et aussi développement pour la plateforme mobile. Ce serait dommage de passer à côté de ces technologies, qui à mon avis peuvent nous faire faire de beaux projets.
100% d’accord. Prenons l’exemple d’un web service SOAP (beurk). On peut déployer toute une usine à gaz plus (websphere) ou moins (tomcat) lourde ou faire un petit programme léger (un jar de 25mo) avec un jetty embarqué, certes, mais invisible. Cette idée d’informatique jetable je la défends depuis 25 ans maintenant. Mais derrière, elle implique de trouver la « valeur » où elle se trouve réellement, c’est à dire chez les développeurs. Quant aux framework, ce terme désigne des choses tellement différentes qu’il n’a plus de sens parce qu’il en a trop.
Mouais. Pas convaincu. Quitte à être le seul pas vraiment d’accord.
En gros, tu dis que tout e qui existe (le plus souvent pour des raisons légitimes) est bientôt mort (pourquoi, on se le demande…). Il me semble que tu généralise pas mal (souvent dans ton blog) de cas extrêmes qui ne sont en rien représentatifs de la vrai vie.
Si c’est pour dire que les serveurs d’app son mort, les WS aussi et les frameworks avec, pour tout remplacer par du REST (des WS en fait), du Stateless (ca existe depuis toujours… et on peut en faire avec Java sans play! quoi qu’on en dise), du HTML 5, etc. En gros, ca donne l’impression d’un super slide commercial :
« Tout est mort dans 2 ans ! vous devez absolument faire du HTML 5 + Play! »
@Wadle : Je me permets de répondre à ta dernière phrase qui m’ennuie : « ca donne l’impression d’un super slide commercial »
Il y a 3 ans lorsque je trouvais que Xebia était génial, on me taxait de « pro-Xebia » et certains pensaient que j’allais terminer chez eux. On est bon copain mais non. Il y a 2 ans lorsque j’ai écris des articles sincères, désintéressés et gratuits sur eXo Platform, sur SpringFuse ou sur Kalistick, on m’a demandé si j’avais touché un chèque à chaque fois… Et bien non. Il y a 1 an c’était Grails, et en ce moment c’est Play! Framework.
Bref dès que je prends le temps de donner un avis personnel et parfois passionné sur un produit ou sur un sujet, je sais que je m’expose à la critique. Je l’accepte et je le fais car je suis indépendant (freelance et financièrement) et assez connu pour que les lecteurs fassent la part des choses.
J’écris en toute liberté mes articles avec la passion. Je n’ai jamais touché un kopec ou même reçu un stylo/un teeshirt de la part d’un éditeur/d’une SSII/de qui vous voulez. Je suis indépendant, freelance et je compte bien le rester encore quelques temps. Lorsque je fais une présentation de Play! au Luxembourg ou en Suisse, je le fais avec mon temps et mon argent. J’investis du temps en faisant des rencontres, en prenant des contacts et en pensant à construire plus tard une boîte avec des gars passionnés. Et je veux un bon outil. En ce moment c’est Play! Framework. Stop, c’est tout. Cherchez pas plus loin.
Donc ne cherchez pas de slide commercial, il n’y en a pas. Lisez simplement cela comme de la passion, avec des opinions tranchées et des avis sur toutes sortes de sujet.
Pourquoi cela dérange-t-il lorsque l’on se dit que l’on peut réaliser certains projets dans le monde de l’entreprise, sans complexité ? Avec Play! ou avec Ruby On Rails ? Avec du PHP ? ou avec Python et Django ?
Est-ce qu’il faut systématiser une approche J2EE/Spring pour répondre aux problèmes des services informatiques et des clients finaux ?
C’est ça la vraie question.
Quand je dis que ca fait « slide commercial » c’est plutôt dans le sens où on dirait un commercial qui a lu 01net et qui essaye de révolutionner le monde avec un super pres.
Je ne trouve pas que Java EE / Spring n’est pas à systématiser, bien au contraire. Mais c’est au moins aussi radical de présenter l’avenir comme la disparition de ces technos au profit d’une autre.
Tu te poses une bonne question mais tu y réponds par la même radicalité que celle que tu dénonces, c’est pour le moins bizarre.
@Nicolas : Est-ce qu’il faut systématiser une approche J2EE/Spring pour répondre aux problèmes des services informatiques et des clients finaux ? C’est ça la vraie question.
Attention de ne pas trop généraliser et mettre dans le même pot tout les frameworks quelles que soient leurs natures.
Il y a certes les services informatiques et les clients, mais aussi la maitrise d’œuvre.
La question ne peut se résumer à JEE/Spring et le reste c’est par trop réducteur
Article intéressant mais …
Je pense que c’est un faux problème. Je ne suis personnellement pas très sensible aux outils. Et les choix d’architectures, complexes ou pas sont des outils pour moi.
Je pense que les artisans sont plus importants car aussi bien outillé que l’on soit, si l’on ne sait pas penser simplement on peut faire des choses très inappropriées : complexes, maladroites.
Il faut aussi savoir que le changement fait partie de notre métier et des choix initiaux très pertinents ne le sont plus 3 ans après. Plutôt que de dire on jette tout et on refait je suis pour réfléchir à pourquoi on n’a pas pu faire vivre/évoluer notre produit.
Et pour embrasser correctement le changement il faut une compréhension profonde du fonctionnel plutôt que des outils « jettables » ou pas.
Sans vouloir être méchant c’est assez pauvre comme article.
-Il faut faire simple=> Ok mais ça fait quand même un bout de temps que tout le monde le dit.
-Il faut supprimer les frameworks et l’architecture en couche pour faire simple=> c’est un poil réducteur.
-Arrêter l’architecture en couche vous n’allez pas réutiliser votre code=>Est-ce vraiment le seul avantage que tu vois au développement en couche ?
-Bon sur les serveurs d’app et websphere c’est vrai mais ce n’est pas un scoop non plus.
+1 à Waddle quand il dit que ça fait slide commerciale et que tu réponds à une question par la même radicalité que celle que tu dénonces.