Un petit retour sur la QCon pour animer un peu ce blog qui ne bouge plus beaucoup ces derniers temps, pour cause de nouveaux projets pour la plupart des rédacteurs. Nous avions exploré de nouveaux domaines (TDD javascript, noSQL), qui ont donné des articles, nous implémentons maintenant ces technologies. Nous vous dirons après l'épreuve de la production si cela fonctionne vraiment.

Bref, nous sommes allés à la QCon de Londres qui se déroulait entre les 7 et 9 mars. Comme lors d'un précédent retour, l'organisation est toujours aussi impeccable, le lieu agréable, et les intervenants de haut niveau. Vous nous direz, pour le tarif (environ 1200€) c'est normal.

Voici quelques orateurs remarquables :

• Martin Fowler : "grande gueule" comme il se définit lui même, créateur de tendances et de ThoughtWorks
• Philip Walder : professeur d'informatique théorique à l'université d'Édimbourg. Auteur de nombreuses publications autour de la programmation fonctionnelle.
• Damien Katz : créateur de CouchDB et fondateur de Couchbase
• Rich Hickey : créateur du langage Clojure
• Joe Armstrong : créateur d'Erlang, abonné à la QCon
• Dan North : agitateur agile à l'origine du BDD
• Steeve Freeman : pionnier d'XP
• John Allspaw : concepteur des infrastructures Salon, InfoWorld, Friendster, et Flickr. Auteur de The Art of Capacity Planning et Web Operations chez O'Reilly

Par rapport à l'édition de Londres 2010 nous avons remarqué une augmentation importante du nombre de personnes présentes : la salle plénière a été doublée par une extension fermée il y a 2 ans. 2 espaces "lounge" également (pour les collations, cafés, boissons entre les conférences), il y a 2 ans il n'y en avait qu'un.

Dans les temps forts, il y a eu l'affluence inattendue (en tout cas par l'organisation et  l'orateur lui-même) pour la session "Faith, Evolution, and Programming Languages: from Haskell to Java" de Philip Walder. Une salle remplie, avec un grand nombre de personnes assises à même le sol. Pour une gageure : une présentation drôle et passionnante sur le lambda calcul et comment réconcilier le monde Haskell et Java. La première chose à souligner c'est l'utilisation d'un langage "mainstream" comme Java pour parler de la programmation fonctionnelle. Cela évite le débat stérile du langage adopté par les masses versus le langage conceptuellement pur. Mais le plus intéressant c'était l'éclairage de la durée de construction de la connaissance sur ces technologies qui évoluent très rapidement. Une mise en perspective du monde de l'urgence économique avec ses racines culturelles (© Regis Debray). C'est probablement quelque chose comme une quête de sens qui fait le succès de ce type de présentation.

Autre salle bondée, lors la présentation du jeune Zach Holman, hacker chez GitHub, qui venait parler du fonctionnement de GitHub dans le track "Working Distributed". Une culture nouvelle de société, sans horaires, sans réunions, sans managers (ou très peu), voire même sans bureaux. Hormis les dédouanements entendus en sortant : "c'est bien mais chez nous c'est pas possible parce qu'on a des clients", ou encore "super mais chez nous avec l'équipe d'intégration ça ne marcherait jamais", ce qui était intéressant c'était :

• le monde présent, indiquant peut-être un intérêt pour des manières de travailler radicalement différentes
• l'organisation autour d'un objectif : faire en sorte que les employés "kiffent". Cela rejoint le sujet de l'amélioration de la motivation intrinsèque en promouvant l'autonomie, la vision commune, l'efficacité.

Pour le moins bien, nous avons été déçus par une présentation prometteuse de BigData chez facebook, qui s'est révélée difficilement compréhensible du fait de l'accent de Ashish Thusoo, ainsi que des concepts tellement élevés qu'il n'y avait pas grand chose à en retirer. Egalement, la Timeline chez Twitter avec un Arya Asemanfar semblant s'ennuyer gravement à sa propre présentation.

Lors des différentes présentations, nous avons trouvé que des thèmes étaient prégnants :

Persistance polyglotte, BigData & NoSQL

De petits besoins de persistance de données pour lesquels des fichiers (éventuellement indexés) convenaient, les sites internet ont grossis, utilisant ensuite des bases de données (mysql le plus souvent), qui sont devenues clusters, et puis se sont révélées insuffisantes. L'utilisation croissante d'internet a poussé des sociétés à se concentrer sur des technologies adaptées au stockage d'énormes volumes de données.

Ces technologies ne sont plus polyvalentes comme pouvaient l'être des SGBDR, c'est ce qu'indiquait Siddharth Anand venu parler des infrastructures de données chez Linkedin. Il parlait d'"ADN des bases NoSQL". C'est la raison pour laquelle, un gros site pourra être amené à en utiliser plusieurs. C'était la keynote d'introduction de la QCon par Martin Fowler et Rebecca Parson sur "The Data Panorama", très proche de l'article "Polyglot persistence" dont nous avons déjà parlé.

Chez linkedin, ils utilisent oracle, ils ont développé une base clé/valeur qu'ils ont ouvert : voldemeort. Expresso, autre base développée par Linkedin fournit des timelines consistentes (qui se base sur mysql). Ils maintiennent la cohérences entre les copies de données avec des systèmes de réplication comme databus ou kafka cf Linkedin Technology, et les slides de sa présentation.

Une chose intéressante, c'est de voir comment ils ont adapté l'infrastructure à l'existant: oracle. Ils ont aussi utilisé des solutions ad hoc, pour des données temporaires, comme de simples fichiers indexés. Ils travaillent actuellement à supprimer Oracle.

Hadoop, très utilisé dans ce domaine (par linkedin, facebook, twitter, eHarmony, Yahoo!, ...), a été présenté par Parand Tony Darugar. C'est le "linux de la manipulation de grands volumes de donnés", i.e. :

• HDFS (hadoop file system) : système de réplication de données avec une API REST
• un framework de calculs distribués
• un modèle de programmation Map/Reduce

Les nuages

3 tracks (série de sessions d'une journée) abordent ce sujet : Cloud architectures, API's and tools, Plateform as a service (PaaS) - Practical cloud computing for developers, et Cloud development and beyond. C'est d'ailleurs un sujet proche du big data, puisque des infrastructures telles que Hadoop se basent sur la scalabilité horizontale : les données sont réparties sur un grand nombre de nœuds qui sont vus comme une seule machine par les API's.

Nous avons également entendu parler de cloud dans des sessions n'ayant rien à voir comme "Zero to 10 million daily users in four weeks ; sustainable speed is king", où Jodi Moran qui développe avec son équipe des jeux pour facebook vantait les mérites de Amazon Web Services (AWS) notamment pour améliorer le time to market et les coûts, en bénéficiant des composants du cloud (queues, bases de données, plateforme web), et en supprimant les opérations.

Mark McGranagham nous a parlé de haute disponibilité à Heroku un cloud pour Ruby (au départ). Ils ont par exemple repris des principes d'Erlang comme l'arbre de supervision, le déploiement par partie, et l'envoi de messages entre processus indépendants (modèle IPC).

L'architecture revisitée

Dans ce nouveau contexte, de haute disponibilité, de répartition des mémoires et des unités de calcul, l'architecture doit s'adapter. Elle doit autoriser le déploiement incrémental, la suppressions de fonction en ligne, la visibilité en temps réel de l'état du système, un time to market constant au fil du temps, et bien sûr supporter l'augmentation de trafic.

Une architecture monolithique, même si elle présente des avantages (la simplicité par exemple), aura du mal dans le temps à pouvoir continuer de satisfaire ces contraintes. C'était le sens de l'intervention de Stéfan Tilkov dans sa session "Breaking the monolith". Son propos était de considérer un système comme un ensemble de connexions/compositions de fonctions, et de voir le développement de ce système comme une redéfinition permanente des frontières des fonctions : la "modularisation".

Jesper Richter-­Reichhelm de Wooga (jeux pour facebook) explique également comment la collaboration dev-op a pu influencer l'architecture et leur permettre de passer d'une architecture classique ruby/mysql (webapps stateless, état en base) vers du erlang stateful côté serveur (pour éviter les aller-retours en base), déléguant à des workers en ruby en communiquant avec du zeroMQ et en introduisant une base Redis. Cela leur permet de tenir 14 milliards de requêtes par mois.

Des changements aussi profonds sont des remaniement d'architecture, sujet abordé par Michael Stall dans "Nothing is Permanent except Change - How Software Architects can embrace Change". Nous avions aussi présenté une session sur ce sujet aux XPdays Bénélux et à l'agile conférence.

Enfin, Dan North approche l'architecture différemment : en terme de compromis.

Les compromis en informatique

C'est un sujet qui est revenu dans plusieurs présentations et est au cœur de NoSQL. Dan North avec ses qualités de showman et son sens de la provocation remettait en cause des domaines de l'ordre du sacré de l'agilité comme le TDD, l'automatisation du build ou le principe DRY, en éclairant toute décision du point de vue du compromis :

• pour le TDD : le coût v.s. la non régression. Veut-on un feedback des défauts ou un feedback des utilisateurs ?
• DRY : la factorisation v.s. le couplage
• automatisation du build : rapidité et absence de tâches répétitives v.s. la souplesse et la compréhension de l'application

Le théorème de Brewer (CAP) précise que dans une architecture distribuée, on ne peut pas avoir à la fois des données consistantes (Consistency), toujours disponibles (Availability), et réparties (Partition tolerance). NoSQL et le cloud dont on a beaucoup entendu parler à cette QCon sont donc aussi une histoire de compromis.

Entraînement à l'échec

Un dernier thème était récurrent, c'était l'impossibilité d'éviter l'échec. Lors de la présentation sur Heroku, Mark McGranagham a insisté sur le fait qu'ils avaient beaucoup appris de leurs échecs. John Allspaw lors de la keynote du dernier jour (resilient response in complex system) nous disait que facebook, twitter, amazon, blackberry, avaient eu des échecs en production. Quelle que soit la qualité des devs, ops, des infrastructures, des processus de construction d'un service, des méthodes, cela arrivera. Il faut s'y préparer. "Getting Real About Distributed System Reliability", un excellent article d'un lead developer de Linkedin explique en détail pourquoi même les systèmes répartis comme HDFS sont sujets aux pannes.

John Allspaw donnait les pistes suivantes :

• apprendre d'autres domaines qui ont de l'expérience de gestion d'incident dans des domaines où la haute disponibilité est vitale : le contrôle aérien, l'aéronavale, les centrales électriques par exemple
• définir des procédures, des responsabilités différentes, lors des incidents, et s'entraîner : faire des simulations, maîtriser tous les outils de crise (bash, wireshark, ...)
• mettre en place une organisation apprenante, en sortant d'une culture du reproche, pour se concentrer sur les faits et les comportements

Un entraînement radical est d'échouer continuellement pour s'entraîner, c'est ce que font Netflix avec le Chaos Monkey. C'est un démon qui tue aléatoirement des instances ou services au sein de leur architecture, afin de tester la résilience du système :-)

Voici les aspects qui nous ont marqués, si vous avez participé à la QCon et que vous pensez qu'il manque un point essentiel, merci de nous faire un feedback.

Notes :

Jour 1:

• QCon keynote
• Breaking the monolyth
• High avalability at Heroku
• how software architects can embrace change
• sustainable speed is king
• decisions, decisions

Jour 2:

• Simple made easy
• The evolution of Paas
• architecture for failure
• Timelines @ Twitter
• big data architecture at facebook
• the monkeys and the firehose

Jour 3:

• resilient response in complex systems
• faith evolution and programming languages from Haskell to Java
• how github works
• ain't no cure for the distributed blues
• data infrastructure @ linkedin
• Hadoop Scalable infrastructure for big data

Un petit mot sur les xpdays bénélux auxquels nous avons participé avec JP les 1er et 2 décembre dernier. Première chose, l'organisation, impeccable avec ces bonnes idées : tableaux de programme de la journée avec des cartes à emporter. Pochette transparente de taille A6 avec le programme et de même taille que les cartes. Le lieu est un peu perdu à 30km au nord de Bruxelles, mais c'est dans la nature, les salles sont spacieuses avec de la lumière.

J'ai entendu parler d'Haskell pour la première fois à l'université. J'entendais que c'était un langage très élégant, amusant et bien plus avancé qu'OCaml. Mais OCaml me donnait déjà bien du mal, et c'était ce dernier qui était demandé pour les examens et les projets de programmation. Je n'étais donc pas prêt à apprendre Haskell à ce moment. Plus tard, par curiosité, j'ai regardé quelques projets écrits en Haskell. Je suis alors tombé sur xmonad, un gestionnaire de fenêtres spartiate, mais avec des idées intéressantes, comme l'agencement automatique. J'ai aussi découvert la bibliothèque Parsec, qui permet d'écrire des parseurs très simplement, et dont la lecture du code m'a convaincu que la notion de fonction était une abstraction vraiment puissante.

Il y a quelques temps, lorsqu'un projet informatique démarrait, une question d'architecture qui se posait systématiquement, était "quelle base de données (relationnelle) utilisons-nous ?", et la subsidiaire (en langage objet), "quel mapping relationnel/objet ?". La réponse était d'ailleurs souvent "hibernate/mysql" dans le monde java. Le mouvement NoSQL est issu d'un besoin de stockage de données important, scalable, performant, et robuste sans avoir toutes les fonctionnalités d'une base relationnelle. Ces besoins ont été ceux de gros sites comme google, facebook, twitter, amazon, linkedin, sourceforge, github... Si certains discours ont été excessifs au départ (comme souvent lors d'une inversion de tendance), c'est en réaction à des années de domination du monde relationnel dans le domaine de la persistance, et aux difficultés des développeurs à s'interfacer avec ces systèmes. A présent beaucoup de produits ont été développés offrant de réelles alternatives au monde des SGBDR :

• le stockage par famille de colonnes (hbase, cassandra, hypertable)
• bases orientées document (MongoDB, CouchDB, Terrastore)
• bases clé-valeur/tuples (Redis, Riak, Maxtable)
• bases orientées graphe (Neo4J, HyperGraphDB)

Quand il s'agit de faire persister ses données, la seule option qui semble disponible est d'utiliser un SGBDR (une base de données relationnelle, telle que MySQL ou Oracle). Mais on se rend parfois compte qu'un seul outil ne peut résoudre tous les problèmes. Ainsi, si on ne dispose que de marteaux, on aura tendance à voir des clous partout. Le mouvement NoSQL (comme Not Only SQL), nous propose des alternatives : bases clefs-valeurs, bases orientées document, bases orientées colonnes, bases orientées graphe ; Cassandra, MongoDB, Redis, Dynamo, Riak, Big Table, Voldemort sont souvent utilisés par les sites à gros trafic et à tendance "sociale" qui font le buzz : Google, Amazon, Facebook, Twitter, LinkedIn. Aujourd'hui, nous allons explorer redis, ses principes, son API et ce qu'on peut en faire. Dans un prochain article, nous verrons une utilisation typique en écrivant un clone de twitter simple et sans prétention.

Dans le précédent article sur les tests javascript, nous avons vu comment tester jQuery avec JsTestDriver. Le souci c'est lorsqu'une fonction va chercher des fragments de html, ou du json, ou d'autres données par ajax, dans ce cas l'appel de la fonction va réellement déclencher une requête http. En soi ce n'est pas un problème, on peut faire un test d'intégration en écrasant l'url de production vers une url en localhost. Seulement, il y a 3 écueils :

• avec JsTestDriver, l'url de base a changé (c'est celle du serveur de test qui est dynamique et pointe vers par exemple http://localhost:9876/slave/id/1311194023939/page/CONSOLE/mode/quirks/timeout/30000/upload_size/50/rt/CLIENT), donc il est nécessaire de faire une requête avec une url absolue (http://localhost/test/monJsonDeTest.json)
• pour exécuter les tests il faut alors un serveur http en local avec la ressource déployée et le contexte configuré
• avec JsTestDriver, on obtient une exception javascript (alors que le code de production fonctionne) que je ne suis pas arrivé à expliquer ou à contourner :

  [Exception... \"Component returned failure code: 0x80004005
  (NS_ERROR_FAILURE)\"  nsresult: \"0x80004005 (NS_ERROR_FAILURE)\"
  location: \"JS frame :: jquery.min.js\"

Nous avons des releases de JSP assez fréquentes. Elles n'ont pas d'impact la plupart du temps. Une fois pourtant, on nous signale qu'un candidat n'arrive pas à déposer un fichier. Les logs révèlent que ce n'est pas la première fois mais impossible de savoir à quand cela remonte. En mettant le nez dedans, on se rend compte en plus qu'il y a des deadlocks en série depuis cinq jours, la dernière MEP web. Arf. Ok, dans un monde de rêve, une erreur dans les logs devrait être un évènement grave, qui mobiliserait toute l'équipe. Dans la réalité, les logs parfaites sont rares et les erreurs "connues" sont monnaie courante.

Après avoir eu une barre verte en tests unitaires javascript, j'ai eu besoin d'aller plus loin : nous réalisons une application HTML5, or cette application tourne au sein d'un navigateur, et utilise jQuery. Je me suis tourné alors vers JsTestDriver. Son fonctionnement est différent des autres outils de test : il utilise de vrais navigateurs "esclaves". Il lance un petit serveur http, puis les navigateurs sur une url pointant vers ce serveur qui va déclencher les tests.

Si vous êtes sous ubuntu, en installation par défaut (ou une autre distribution linux en UTF-8), que vous encodez des mp3 avec lame (version 3.98.2 pour moi) en spécifiant des tags mp3, et que vous importez ces mp3 avec iTunes, alors vous devez avoir des problèmes d'affichage d'accents. Ça fait beaucoup de si, mais c'est mon cas, et j'ai cherché un moment avant de comprendre pourquoi, alors je vous donne les raisons. Il existe un octet dans les entêtes id3v2 qui indique le charset des textes. Cet octet est situé juste après les flags de chaque champ (frame). Un champ id3v2 se compose comme suit :

xx xx xx xx tt tt tt tt ff ff 0e valeur champ
frame id      taille    flags encodage
ex : 
TPE1 00000007 0000 03 prince