QCon London 2014 – Journal de Bord – Day 3

7 Mars 2014, 08:42, banlieue de Londres :
En route pour la troisième et dernière journée de la QCon.

Keynote – The world “after” Cloud Computing and Big Data

Par prf. Gunter Dueck
Le professeur nous parle de changement, de la zone de confort et comment en sortir pour trouver de nouveaux challenges, avec humour.
Comment deux souris, ne trouvant plus de fromage (le monde est devenu bacon), finissent par mourrir plutôt que s’adapter.
L’architecture et la technologie du futur n’est pas déterminée en réfléchissant à la technologie “en vogue”, mais par les usages d’aujourd’hui, réimaginés en nouveaux usages.
Ces usages et nouvelles technologies seront probablement disruptives, nécessiteront une transformation de certaines industries (ou leur disparition), par exemple l’industrie automobile vs la voiture automatique.
On parle de robotique, impression 3D, biologie synthétique… En fait l’informatique au travers du Big Data tend vers l’ingénierie, des usages plus proches du métal, on intègre des monde différents.

Talk 1 – Platform Engineering, Lessons Learned in Scaling Twitter

par Brian Degenhardt
Brian souhaite nous expliquer comment utiliser l’ingénierie pour découper son problème en parties gérables, ce qu’il a pu apprendre en travaillant depuis 1 an sur la plate-forme Twitter.
Twitter a commencé avec une architecture monolithique, et ils se sont rapidement rendu compte des limitations : difficulté de mise à l’échelle du modèle de stockage, tout changement nécessite de déployer tout les serveurs, performances concurrentes pauvres…
Les ingénieurs ont commencé à découper en services de stockage avec le reste de l’application monolithique, puis sont passés à une architecture hyper-découpée en services à tout les niveaux (stockage, logique, présentation, routage). Le “monorail” (le coeur monolithique originel) est encore en usage pour certaines fonctionnalités à faible trafic.
Brian nous explique ce qu’il se passe quand on envoie un tweet, du rédacteur au destinataire d’une @réponse, et qu’en parallèle (fanout) d’autres services consomment le tweet envoyé (par exemple pour la recherche, le firehose qui envoie l’ensemble des tweets en circulation récemment, …).
La question ensuite est “comment construire un service?”. Twitter-Server est un projet open-source dédié à cela. C’est basé sur Finagle, un système de RPC pour la JVM encore une fois open-sourcé par Twitter. On voit les services comme des fonctions asynchrones, retournant un Future<T> comme résultat, le cas échéant en tirant parti des possibilités de composition offertes par ce modèle de concurrence.
La question du monitoring et l’usage de statistiques plutôt que de mesures individuelles est aussi important pour Brian. Des outils comme Viz et Zipkin sont utilisés en interne à Twitter pour la surveillance des services. Chaque équipe a son propre tableau de bord montrant les éléments liés à leurs responsabilités.
Brian a parlé vite, et ça nous laisse pas mal de temps pour poser une multitude de questions. On en apprendra ainsi plus sur le fonctionnement de Finagle, l’agrégation des statistiques, le type de connaissance au niveau matériel qu’il faut avoir, etc…

Talk 2 : How Netflix Leverages Multiple Regions to Increase Availability: An Active-Active Case Study

par Ruslan Meshenberg
Comment mitiger l’échec d’un système qui change rapidement et à grande échelle. On parle d’incidents du plus haut niveau, du type de ceux couverts par les médias.
Est-ce qu’une instance va tomber? Probablement, pour différentes raisons. Netflix utilise Chaos Monkey pour tester la résilience de leurs systèmes à un tel événement.
Est-ce qu’une zone peut tomber? Rarement mais c’est arrivé. Chaos Gorilla est un autre outil de Netflix utilisé pour tester ce genre de cas (et Chaos Kong pour l’échelle d’une région, c’est à dire plusieurs datacenters).
Ruslan nous expose des principes de base pour mitiger les incidents (qui vont arriver) : isolation et redondance.
Après un gros incident lié au load-balancing d’une région en 2012, Netflix a commencé par construire une solution de résilience pour l’ELB, puis une solution plus générique, une architecture Active-Active.
Ruslan continue à nous présenter les outils opensourcés par Netflix (ou en train de l’être) pour le déploiement, les tests canaries, le déploiement automatique, la surveillance, le failover (en se basant sur le DNS).

Repas et tirages au sort

J’ai la mauvaise idée de tenter le coup de prendre mon repas à un étage différent de celui qui m’est affecté, pas de chance c’est le plus pris d’assaut et il reste peu de choses. Tant pis, au moins j’ai le temps d’aller croiser les doigts pour la session de tirages au sort pour les différents lots des sponsors.
Au final, c’est un autre Editor InfoQ, Olivier, qui va remporter 3 livres O’Reilly le veinard 🙂
Tout ça prend un peu de temps, et Tim Fox a tout juste le temps de s’installer pour commencer la présentation suivante.

Talk 3 – High Performance Reactive Applications with Vert.x

par Tim Fox
Tim, le créateur de Vert.x, va nous faire une présentation de sa plate-forme légère pour applications réactives.
Superficiellement similaire à Node.js, mais pas un clone. Particulièrement polyglotte, et mettant l’accent sur la performance (utilisation de Netty par exemple) mais aussi la simplification.
Tim nous présente les APIs asynchrones au cœur de Vert.x et pourquoi ce choix des événements asynchrones : les serveurs modernes ont souvent besoin de beaucoup de concurrence, mais les threads sont encore une ressource rare et chère. Ce qui amène à une approche non-bloquante.
Chaque application Vert.x est composée d’unités de code appelées Verticles, mono-threadées et écrites dans n’importe lequel des langages supportés. Cela ressemble un peu au modèle d’acteurs. Tim indique que c’est en effet très proche…
Le bus d’événements est la colonne vertébrale de Vert.x, sur laquelle les Verticles envoient des messages et communiquent entre eux, en String, Buffers ou JSON. On a même un bus d’événement en cluster, au-dessus de différentes JVM, ce qui permet d’écrire non plus des applications monolithiques mais des microservices dans des langages variés.
Tim fait la démo d’une application “publish/subscribe” avec un client Vert.x JavaScript.
On pourra découper son application en modules (des fichiers zip avec méta-données), qui apportent une isolation du ClassLoader notamment. Nous sommes encouragés à partager nos modules afin de créer un vrai écosystème Vert.x. A l’heure actuelle il y en a déjà pas mal pour la plupart contribués par la communauté (dont un pour exécuter du code NodeJS, NoDyn). Tim nous montre qu’on peut packager un module dans un fatjar exécutable embarquant Vert.x, avec un relativement faible overhead (environ 5Mo).
Vert.x traite la haute disponibilité en faisant de la reprise automatique, de la détection de partition automatique (avec une approche par qorum), par simple ajout du paramètre -ha à la commande d’exécution.

Talk 4 – Works in Progress

par Jaimee Newberry
Une approche un peu différente pour parler du future, en mettant un peu plus l’accent sur le côté humain des choses par rapport aux autres tracks.
Jaimee aime interagir avec son public et poser des questions à l’assistance, comparer son vécu au ressenti du public.
Elle nous présente son parcours éclectique, étudiante en art devenue développeuse de sites web, en passant par un parcours académique (création d’un cursus sur les IHM) pour finir dans le monde du mobile…
Jaimee se rend compte qu’elle dépense une énorme énergie dans les produits et les équipes avec lesquelles elle travaille. Et qu’elle pourrait aussi se voir en tant que produit sur lequel dépenser le même genre d’énergie :
parallèle entre la création de bons produits (ce qu’elle sait faire) et la création d’un environnement de vie sain. Elle pose alors 4 étapes pour y arriver.
Découvrir :
Non pas “qu’est ce qui viens après?” mais plutôt “qu’est-ce qui est important?”, trouver ses valeurs et les étapes pour atteindre un environnement qui les supporte.
Concevoir :
Un plan, quelque-chose qui se rapporte à ces valeurs et les exprime de la manière la plus diversifiée possible pour leur faire faire surface.
Développer :
C’est là qu’on fait le travail, qu’on met les plans en action. Pas forcément des étapes gigantesques, mais même à petits pas, car dès qu’on commence des choses géniales se produisent.
Itérer :
Revenir à sa liste de départ, retravailler sur des points qu’on a déjà essayé d’améliorer, réévaluer, réadapter à son nouveau rythme et contexte. Et célébrer les réalisations, même les plus petites.
Une session inspirante sur la motivation et le développement personnel et comment cela influence nos réalisations et notre travail. “We are works in progress“.

Talk 5 – How Elasticsearch Powers the Guardian’s Newsroom

par Shay Banon et Graham Tackley
Shay Banon est le créateur d’ElasticSearch (la technologie) et CTO d’ElasticSearch (la société).
Graham travaille au Guardian, un des principaux journaux britanniques. Ils ont un site depuis 1995, qui est aujourd’hui le site d’information en ligne en anglais le plus lu dans le monde.
Shay commence par nous présenter ElasticSearch et la philosophie du produit. Ce talk sera cependant principalement un retour d’expérience du Guardian, accompagné de démos du système Orphan mis en place au journal.
Graham commence par présenter un dashboard montrant la provenance du trafic, le découpage des graphes de statistiques par section, etc… Ils sont capables d’analyser la provenance du trafic sur un article, minute par minute, en ressortant par exemple les tweets mentionnant l’article.
D’autres graphes permettent des analyses plus techniques, temps de chargement, temps de réponse… Mais d’ou viennent les données?
En fait toutes ces pages sont générées dynamiquement par des recherches ElasticSearch, avec un délai d’environ 5 secondes pour la prise en compte des interactions des visiteurs.
Ce projet a été commencé lors d’un Hack Day, une période de 24h pendant laquelle les ingénieurs du Guardian peuvent travailler sur le projet de leur choix.
Graham nous fait un historique des étapes par lesquelles le service est passé, d’un prototype très simple tournant sur sa machine lors du hackday à un service basé sur ElasticSearch et distribué dans le cloud.
Shay prend le relais pour expliquer le design d’ElasticSearch et comment il se rapporte bien à des cas d’utilisation ou la donnée est liée au temps.
Pour terminer, Graham nous montre comment ils construisent leurs graphes : agrégation des données de pages vues (pour chaque vue un doc JSON) dans ElasticSearch, recherche dans ElasticSearch (des requêtes très ciblées, ils n’utilisent pas les fonctionnalités full text du produit), puis aggrégation (via facettes avant la version 1.0) et filtrage.
Tout ça réalisé par une équipe de 3 !
Un retour d’expérience mêlé de détails d’implémentations de la techno sous-jacente, un format vraiment réussi.

Fin de QCon

Et voilà, la QCon Londres 2014 est officiellement terminée! Il est temps de rassembler ses goodies, une dernière occasion d’interagir avec les speakers et il faudra penser à rentrer.
3 jours riches en apprentissage, idées et rencontres, la grasse matinée ne sera pas de trop samedi matin pour récupérer l’énergie (bien) dépensée 🙂