Trois jours à QCon London 2010 : Tendances et Confirmations

"QConLondon 2010 : the place to be!" diront certains. Ce qui est certain c'est que c'était l'occasion de voir de grands speakers (Uncle Bob, Dan North ou Mickael T. Nygard...) et de sentir les mouvances de notre industrie. Trois jours intenses, 700 participants venus de plus de 50 pays, 6 tracks thématiques par jour en parallèle : difficile de tout voir et absorber mais voici les éléments que nous avons voulus retenir.

Les confirmations

Le terme de "Software Craftmanship" (littéralement "l'artisanat logiciel") était à l'honneur avec un track de sessions dédié et une keynote mettant l'accent sur le fait que l'amélioration de la qualité logicielle vient en formant les développeurs par l'apprentissage (notamment sur des techniques comme le développement piloté par les tests ou l'intégration continue) et en les rendant fiers de leur métier - on est bien loin de l'approche "industrielle" de l'informatique d'il y a quelques années. Le logiciel est un capital composé de code bien entendu mais aussi et surtout de la connaissance de ce dernier et de son fonctionnement, c'est-à-dire des hommes. Il est nécessaire de tout mettre en oeuvre pour conserver ce capital et éviter sa détérioration.

Nous vous laissons avec cette citation de Robert C. Martin :

Software maintenance is not the work we are doing after the first release, this is the job we are doing when we have decided the application will die.

L'apport d'approches comme le Lean IT ou Kanban n'est plus à prouver en termes d'apport client et force est de constater que ces nouvelles approches complètent à merveille les méthodologies Agiles type Scrum ou XP. Nous avons atteint l'âge de maturité sur ces sujets et il est désormais acquis que c'est la bonne manière de construire du logiciel. Le temps de  la prise de recul est donc là et cohabitation et adaptation locale sont les maîtres mots : prendre le temps de voir comment s'adapter aux différents contextes, faire du design (pas en top-down mais en faire tout de même...)... La qualité logicielle et les tests ont toujours la part noble et au delà du "il faut tout tester", il existe de vraies réflexions : quels sont les tests réellement pertinents ? comment tester de manière efficace ? comment tester ce que l'on ne testait pas avant (GUI, layouts, async, parallélisme...) ? quel est le meilleur langage pour exprimer des tests?

Concernant la SOA, le message clé était le pragmatisme : finis les querelles anti-ESB et les discours REST-only ! L'heure est aux ESB virtuels  où toutes les fonctions classiques de routage, orchestration, transformation, etc. ne sont plus concentrées en un seul composant mais distribuées dans chacune des applications. Pourquoi en effet utiliser des solutions d'ESB centralisées qui cumulent les défauts d'être propriétaires, de représenter de dangereux points de contention, et de nous renvoyer à l'âge de pierre du "software craftmanship" (testabilité, intégration continue, gestion de configuration ...) ? Les architectures SOA 2010 ne sont donc plus ESB-centric mais composées d'applications ESB-enabled où chaque application porte elle-même les fonctions d'un ESB (via par exemple l'utilisation de stack ESB comme Mule). SOA 2010 confirme aussi la fin du mythe du protocole abstrait préconisé par les très complexes WS-* au profit de stacks technologiques plus simples comme HTTP/REST pour les communications synchrones et JMS pour l'asynchrone.

UDDI is a solution looking for a problem.

Le "browser as a platform" qui devient une VM permettant d'héberger des applications (mobiles ou desktop) de plus en plus riches. Les developpements pour mobile sont toujours en forte augmentation (stratégique pour Google et Apple). A tel point que les développements pour mobiles ont un fort impact sur la technologie : HTML5 et CSS3 sont aujourd'hui tirés en grande partie par le développement pour mobile et non par le développement pour desktop. Aujourd'hui, les applications mobiles ne sont plus seulement des pâles copies des applications web "desktop", d'autant plus qu'elles accèdent progressivement à toutes les fonctions du téléphone comme le GPS ou l'accéléromètre. Si bien que développer une seule fois et adresser un ensemble large de smartphone (malgré un manque de standard) peut être plus séduisant que de devoir développer une application native pour chaque smartphone.

Java (surtout la JVM) comme plateforme. Fût un temps décriée pour ses mauvaises performances, la JVM est plus que jamais à l'honneur. De nombreux retours d'expérience montrent que la JVM est désormais un composant sur lequel on peut compter pour faire de la haute performance et on peut citer deux exemples édifiants : le site gilt.com qui absorbe 2500 opérations/secondes sur une infrastructure à base de Java et le fond LMAX spécialisé dans le trading algorithmique haute-fréquence qui encaisse 100 000 opérations par seconde en optimisant le code (Java) pour le cache des CPUS - et non, ils ne développent pas en C++! En allant plus loin, on se rend compte que finalement de nombreux outils dédiés à la forte charge sont également implémentés en Java (Voldemort, Cassandra ou Gigaspaces par exemple).

Concernant le langage, SpringSource assume son positionnement de leader de Java : Rod Johnson présente sa société comme le "Microsoft open source" avec pour mission d'outiller les développeurs pour les rendre plus productifs et faire le liant entre le foisonnement des produits Open Source pour en présenter une vue cohérente. Productivité est le maître mot et c'était l'objectif de sa présentation de Spring Roo (dont le positionnement par rapport à Grails, autre framework SpringSource, reste tout de même assez étrange...)

"One size does not fit all". Il apparaît de moins en moins opportun en 2010 de faire le choix d'un SI 100% homogène où chaque choix technologique est standardisé puis étendu à toute la DSI. Ainsi le même message nous a été martelé tout au long des sessions NoSQL : à chaque besoin de stockage sa solution la plus adaptée (dois-je stocker du relationnel, du graphe, du clé-valeur ... ?) et les retours d'expérience de certaines des infrastructures les plus sollicitées nous témoignent qu'il ne faut pas hésiter à mixer plusieurs solutions pour un même projet. De même au niveau langage : si, comme nous venons de le voir, la JVM se positionne clairement comme une plateforme de Run unique supportant différents langages, on utilisera (éventuellement au sein d'une même application) le langage adapté à chaque besoin : par exemple Java pour son code métier, Ruby (via jRuby) pour les tests, et Erlang (via erjang) ou Scala pour des parties fortement concurrentielles.

Les nouvelles tendances

Le cloud était très présent à QCon (avec un track dédié) et la infrastructure est en train de devenir une commodité, ce qui mène inévitablement du produit au service (au même titre que l'électricité en son temps...). Bref, le cloud (privé ou public) et le 'as a service' est inévitable dès lors que le coût à ne pas l'utiliser sera supérieur aux risques induits. La principale limitation reste le coût de sortie et l'adhérence à une plateforme. L'émergence d'acteurs concurrents devrait aider à lever cette limite et le premier combat qui se trame est celui de l'API d'accès au cloud, l'API d'EC2 (Amazon) en tête. Alors, est-ce la fin de l'informatique, qui va partir dans les nuages et nous échapper ? Non, ce sont les prémices d'une nouvelle accélération : cette "commodification" permettra de dégager des moyens pour réinvestir dans de l'innovation et donc passer à autre chose ! Comme le dit Simon Wardley:

It is a question of "when", not of if.

L'émergence des langages concurrentiels ou parallel computing. Erlang existe depuis 20 ans mais c'est le temps qu'il aura fallu pour donner naissance à de nombreuses initiatives (Scala, Erjang, Kiwit, F#...). Alors pourquoi cet engouement? Kresten Krab Thorup nous donne une explication : les systèmes sont de plus en plus sollicités, gèrent de plus en plus de données et demandent des performances de plus en plus importantes. Or avec le tassement de la loi de Moore, les processeurs ont atteint leur capacité physique maximum, et pour augmenter la capacité de traitement, il faut forcément paralléliser (les ordinateurs, les cores...). Java et les langages "Object Oriented" ne sont pas adaptés aux développements parallèles et concurrentiels. Le nouveau shift technologique nous fera (peut-être) passer d'un modèle 'Object Oriented Programming' à un modèle 'Parallel Programming', la première manifestation de ce shift étant la vulgarisation qui se fait autour du développement via le "modèle de l'acteur".

Cette problématique de parallélisation, de traitements concurrents se retrouve également au niveau SI avec de nouvelles manières d'appréhender les architectures plus évènementielles - Event Driven Architecture - Ces architectures reprennent au niveau du SI les idées de l'actor based programming : des systèmes ou des programmes autonomes et faiblement couplés qui échangent par évènements/notifications. A noter que ce type d'architecture est déjà massivement utilisé sur des systèmes robustes à très fortes sollicitations.

Le renouveau d'une technologie stable depuis 40 ans : c'est la "renaissance de la base de données" avec l'émergence et l'utilisation de solutions dites "NoSQL" (Voldemort, Cassandra, CouchDB, MongoDB...) ainsi que la seconde jeunesse des solutions de data grid (Gigaspaces, Coherence). Force est de constater que ce marché est complexe tant en terme de solutions (et de services rendus) que de technologies et choix d'implémentation. Difficile de savoir quels seront les vainqueurs. En revanche pas d'inquiétude quant au fait que ces solutions fonctionnent et sont utilisées sur des systèmes (e-commerce, sites de pari en ligne, site de réseaux sociaux...) à très forte sollicitation. Il sera intéressant de voir comment les acteurs "traditionnels" de la base de données réagissent et déforment leurs offres pour répondre à ce besoin de spécialisation dans le mode d'utilisation de la donnée.

Le nécessaire rapprochement Dev et Ops (les études et la production)****, déjà popularisé par Amazon et son modèle "You build it, you run it".  Nous nous attelons depuis plusieurs années à abattre les cloisons entre métier et études, un objectif supplémentaire sera désormais la frontière production / études. Aujourd'hui, les études sont responsables du code, et la production de l'infrastructure certes mais aussi du bon fonctionnement du code délivré par les études (monitoring...). Le constat (au travers de nombreux exemples de systèmes ayant explosé en vol) est le suivant : les deux parties ne partagent pas ce qui pourtant est complémentaire, la connaissance du fonctionnnement du code d'un côté et les indicateurs réflétant le fonctionnement de ce code de l'autre. Il faut déplacer la frontière en laissant aux études la responsabilité du bon fonctionnement du code. La production aura alors en charge la gestion du réseau, des machines, des OS et devra surtout aider les études en simplifiant au maximum l'infrastructure, en les accompagnant dans leur compréhension de l'infrastructure, et en automatisant les tâches de configuration qui peuvent l'être de façon à être plus productif mais surtout à garantir que ces tâches sont réalisées de façon cohérentes et fiables (utilisation d'outils comme Puppet, Chef...). Au final, deux tendances quelque peu contradictoires : rapprocher Dev et Ops pour permettre de mieux faire vivre nos systèmes et mieux les adapter à des enjeux de performance et scalabilité mais en même temps des Ops banalisées envoyées sur le cloud. Tout dépend finalement du type d'application dont on parle : innovante et stratégique pour le métier ou banalisés ("commodifiée") ?

Voilà donc ces trois intenses journées résumées en ces quelques lignes. L'IT évolue, change et fait des petits pas. Nous faisons des systèmes indéniablement de plus en plus complexes. Nous avons aussi et surtout la possibilité de faire des systèmes autrement, d'apprendre de nos erreurs passées et de nous améliorer. Nous avons envie de faire partie de ceux qui font autrement, de ceux qui participeront à l'amélioration de notre industrie.

See you @USI2010