Suite aux évènements suivants auxquels j’ai assisté, je tenais à vous faire partager mon ressenti, à savoir :
– Web Oriented Architecture, une transmutation des pratiques de construction des SI
– Elastifiez votre application : du SQL au NoSQL en moins d’une heure
– Du Javascript propre ? Challenge Accepted
– Normal ou décaféiné ?
– Developing Modern Web Apps With Backbone.js
– Space Chatons: Bleeding Edge HTML5

Au travers de ces différentes conférences, la tendance incite à bâtir nos nouvelles applications sur une architecture Web Oriented Architecture (WOA), leurs données stockées dans des bases NoSQL et leurs interfaces utilisateur basées sur HTML5, CSS3 et Javascript. Bâties de cette manière ces applications sont scalables mais aussi supervisables une fois déployées dans un Cloud.

Pour mon planning et les pointeurs vers les technologies que j’ai retenu, vous pouvez vous référez ici.

Architecture WOA

Je vous conseille pour bien comprendre pourquoi Habib Guergachi fait tant l’apologie des applications basées sur une architecture WOA, de coupler les conférences du Devoxx France 2012 puis celle de 2013. Habib Guergachi est très pédagogique et a l’art de la formule et des images pour faire passer son message.

Ce que j’en ai retenu, c’est de bâtir nos futures applications en exposant nos services via une API REST accessibles via le protocole HTTP. Vous pouvez lire sur le sujet cet article de Martin Fowler.
L’autre grand point est de se concentrer sur les services qui sont le cœur de métier de l’entreprise et de consommer les autres services spécifiques via des services exposés par des prestataires externes. Ces mêmes services étant eux aussi des services REST.

Habib démontre bien qu’aujourd’hui nous arrivons aux limites du tout intégré. Les entreprises veulent avoir tout les services en interne et les intégrer ensemble avec des technologies complexes. Cela à un coût et c’est très complexe contrairement à une architecture type WOA où tout les services inter-opèrent en exposant des ressources accessibles via une URI. C’est le fameux RELAX d’Habib (Rest + Stateless + Asynchrone).

Cette nouvelle architecture ne vas pas sans de nouveaux défis à appréhender telle que la sécurité et l’authentification. Aujourd’hui, les briques techniques sont là, il nous reste à bien les faire fonctionner. Elles se basent sur du concret, du solide et ont fait leurs preuves : HTTP et la sécurité via OAuth, par exemple, déjà utilisés par les grands du web.

Stockage des données et bases NoSQL

La meilleure démo, à laquelle j’ai pu assister, est celle du basculement d’une application courante de SQL en NoSQL. A remettre en perspective avec les discours d’Habib du Devoxx2012 et 2013 sur les applications WOA. C’est typiquement une mise en œuvre de ces principes.

En effet, nos deux speakers nous démontrent qu’il est assez aisé de basculer d’une application JEE standard vers une application WOA, et ainsi de la rendre scalable. De lui permettre de remonter des données très rapidement, les indexer et faire des recherches fulltext dignes du moteur de recherche de google. A ce propos rafraîchissez vous la mémoire avec l’exemple de la conférence d’Habib avec le moteur de recherche de la BNF qui est loin derrière celui de google pour retrouver ou proposer des résultats même mal orthographiés.
Voici les étapes du rafraîchissement de l’application :
1-Exposer les services via une API Rest
2-Mettre en place une base de données NoSQL CouchBase accessible depuis une URI
3-Remplacer les requêtes des services pour appeler cette URI via un client HTTP
4-Délégation de l’indexation à ElasticSearch pour gérer la recherche fulltext

ElasticSearch est configuré avec CouchBase et inversement. La vitesse où le million d’enregistrements sont gérés par les deux outils est tout simplement ahurissante !

ElasticSearch possède des plugins dont un est particulièrement efficace pour faire du reporting sur les datas, il s’agit de Kibana. Pour ceux qui ont déjà utilisés les produits de BI du marché, vous allez être tout simplement stupéfaits, écœurés et vous empresser de tester ce nouvel outil.

Allez lire les articles de Gaëtan Le Brun sur le sujet notamment son retour du Devoxx 2013 et sa comparaison SQL versus NoSQL.

Le trio : HTML5, CSS3 et l’écosystème JS

Nous avons vu le côté Back avec les services et la persistance des données. Quid du Front ? Ne cherchez pas plus loin pour vos frontaux web, dirigez-vous vers AngularJS.
Aujourd’hui l’écosystème javascript n’a rien à envier à celui de Java. Vous avez tout les outils et frameworks qui vous rendent plus productif pour :
– faire des tests unitaires
– automatiser votre build
– gérer vos dépendances
– et pour le déploiement ? c’est juste un zip :)

Sur ce dernier point, il est aisé de comparer avec l’univers JEE et le packaging de l’application via un EAR, qui peut-être complexe à construire selon les projets.

Pour ceux qui seraient restés sur des aprioris, « le JS c’est pas propre », allez voir cette conférence. Avec tout les conseils des speakers, il est aisé de construire du code JS propre, lisible et maintenable. Pour avoir un aperçu des outils utilisés côté écosystème JS, je vous suggère de lire les articles de Gaëtan Le Brun, ici et ici.

Comme dirait Habib encore une fois, qu’attendons nous pour y aller ? De nous faire virer dans la honte où bien de démissionner dans l’honneur ?

A nous d’être agiles et de saisir ce qui se présente devant nous pour enfin développer des services focalisés uniquement sur les problématiques métiers et passer moins de temps sur des problématiques techniques de développement et d’intégration, liés aux technologies d’aujourd’hui mâtures qui sont celles d’hier et qui nous font souvent souffrir au quotidien.

Héberger ces applications dans un Cloud

En parallèle et dans le même esprit, rien ne sert de prendre en charge l’infrastructure. Mieux vaut s’appuyer sur du Cloud en mode PaaS et avoir une supervision de la consommation et des coûts réels de chaque service. A ce titre, regarder la keynote d’Alexis Moussine-pouchkine qui présente bien les enjeux du basculement dans ce mode. Ni plus, ni moins de savoir exactement combien coûte un service par utilisateur !

Pour de petites structures, il est difficile de pouvoir gérer toute l’infrastructure. En s’appuyant sur le Cloud, elles peuvent s’abstraire de ces contraintes qui sont gérées par des spécialistes.

Un autre avantage du Cloud est sa capacité à rendre supervisable les applications sur différents critères, et ainsi de rendre les entreprises capables de valoriser un coût par utilisateur, et ainsi permettre au DSI d’identifier, de décider, d’améliorer les services à destination des utilisateurs ou de partenaires externes. Il peut faire le lien entre budget investi et retour sur investissement, et ce de manière précise.

Pour se rendre compte de la puissance et de la simplicité du Cloud, testez CloudBees.

Conclusion

En développant des applications basées sur les concepts WOA, l’entreprise déploie ses services et les expose en se basant sur des technologies connues et éprouvées qui résolvent nativement un grand nombre de problématiques (découplage, scalabilité, …).

L’entreprise doit être pragmatique et se concentrer sur des services liés à son cœur de métier et s’appuyer sur des services tiers pour les autres besoins. Cette manière de voir les choses est à l’encontre de ce qui se fait aujourd’hui, comme l’indique Habib, où les entreprises ressemblent plus à des châteaux forts et sont moins ouvertes sur l’extérieur. A l’inverse, celles qui ont pris le virage inverse sont faciles à identifier :).

Pour se concentrer encore plus sur son cœur de métier, l’entreprise peut aussi déporter son infrastructure dans un Cloud privé ou public pour se décharger d’une lourde charge et laisser des experts du secteur gérer les problématiques de scalabilité.