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.

IMGP6040.jpg

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 :

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.

IMGP6056.jpg

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.

IMGP6046.jpg

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).

IMGP6011.jpg

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.

IMGP6013.jpg

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:

Jour 2:

Jour 3: