QCon London 2014 – Journal de Bord – Day 2

6 Mars 2014, 08:34, banlieue de Londres :
En route pour la deuxième journée de la QCon

Talk 1 – Maneuverable Web Architecture

par Michael Nygard
Michael s’inspire d’un pilote de chasse devenu spécialiste de la théorie du combat qui a réalisé que l’avion qui pouvait le plus rapidement gagner et perdre de la vitesse (meilleure accélération) gagnait le combat, pas l’altitude maximum ou la vitesse de pointe (un théorie matérialisé dans le F-16), qu’il fallait contrôller le tempo.
Mais l’architecture IT typique est un désastre en terme de tempo, et il pense qu’une architecture manoeuvrable peut changer cela.
Ses thèmes communs: pluralité (par opposition à la mutualisation), casser les monolithes, embrasser les URIs.
Il présente des techniques (ouvertes à débats, pas des patterns) pour créer une telle architecture :
– Abstraire Suffisamment l’IHM (découplée du modèle fonctionnel, demande plutôt les champs à afficher au backend)
– Moteur de Script
– Valeurs immutables
– Solutions minimales, généralisées, micro-services
– Autoriser les usages externes + Auto-Défense
Michael termine son talk en évoquant qu’il a déployé d’autres techniques, mais il est moins sûr qu’elles puissent s’appliquer dans d’autres contextes que les siens.
Tout cela conduit à l’émergence du tempo et de la maneuvrabilité, qui sont les propriétés que nous cherchions.

Talk 2 – Garbage collection is good!

par Eva Andreasson
Eva nous parle du concept de Garbage Collector, du modèle mémoire de la JVM (incluant la heap. Elle commence par présenter ce qu’est un GC, puis la heap et le fait que sa taille puisse sortir légèrement des paramètres qu’on lui fourni (en fonction de l’implementation de la JVM).
Elle présente ensuite les types de GC (compteur de référence et traçage), la fragmentation et l’utilisation de la mémoire (avec la copie ou le “marquer-et-balayer”, mark and sweep) et les avantages et limites de chacun. Par exemple, la copie empêche la fragmentation, mais elle est coûteuse et induit un stop-the-world (une pause totale de la JVM), ce qui peut être très mauvais. Le mark-and-sweep peut être fait en parallèle (que du GC, stop-the-world) ou en concurrence (certaines phases du cycle de GC peuvent s’exécuter en même temps que le code applicatif).
L’expérience d’Eva sur des implémentations “alternatives” de la JVM comme JRockit et Azul Zing se ressent, et néanmoins elle arrive à rester très claire et didactique. Elle indique qu’elle a aussi travaillé surs les heuristiques dynamiques, notamment appliquées à sa némésis : la compaction (rassembler les petits objets pour créer de l’espace en mémoire pour les gros).
Voilà pour la théorie. Eva nous donne maintenant son ressenti sur l’état des choses :
The Good, the Bad and the Ugly
Good :
Avoir des déchets c’est bien, on utilise Java comme prévu, le boulot du GC est facilité. Celui-ci a permis à Java d’innover, de faire évoluer le paysage du développement. Il faut cependant tuner
Bad :
En termes de tuning, c’est souvent le désert. Il faut s’intéresser au choix de l’algo de GC, comprendre le modèle d’allocation de son application, mesurer les indicateurs adéquats (de nouveaux outils comme jHiccup sont très intéressants à ce propos)
Ugly :
L’application qui ralenti de plus en plus jusqu’à planter en OutOfMemoryException : il n’y a pas assez de heap pour le rythme d’allocation de votre application.
Pourquoi ne pas allouer plus de mémoire (la RAM est peu coûteuse)? Le problème c’est la fragmentation et la compaction (qui sont encore “mal” gérés aujourd’hui, stop-the-world, à l’exception d’Azul Zing).
Les opérations qui “arrêtent le monde” sont les réels adversaires de l’histoire.
C’est un problème qu’il reste à résoudre dans la JVM moderne.
Garbage is Good, the need to tune is Bad, stop the world operations are Ugly.
Le message final d’Eva est : “joignez l’effort d’innovation autour de l’élimination des pauses GC”.

Repas

Encore une fois un buffet chaud et froid, incluant des spécialités locales (salade au fromage de chèvre du Sussex, salade de tomates et pêches) et moins locales mais plus “classiques” (chili con carne) 🙂 De quoi se remettre en forme pour l’après-midi.

Talk 3 – Rx from first principle

par Erik Meijer
Erik va nous expliquer comment nous aurions pu inventer les Reactive Extensions, Rx, et tout ce qu’il faut savoir sur la covariance et la contravariance.
L’essence d’une convariance est un getter, et le type d’un getter une des fonctions les plus simples : () => A.
Covariance : si une Banane est un Fruit, une fonction qui produit des Bananes est une fonction qui produit des Fruits.
C’est l’heure de la “Token Salad” :
Functor : qqchose qui a map
Monad : qqchose qui a flatMap
Je décroche… Hereusement Erik s’enflamme avec les effets de bord et son exemple de getter “steveb(almer)” 🙂
Un getter qui peut se terminer en exception devrait le montrer dans son type : ()=>Try[A]. Un getter qui peut se terminer sans renvoyer une infinité de valeur devrait aussi le montrer : on raffine encore en ()=>Try[Option[A]].
Les getters viennent d’une factory, un getter de getters.
En fait cela correspond aux interfaces Enumerable + Enumerator (ou plus approximativement Iterable + Iterator)… Ok, je réattache ma ceinture.
Inversez les flèches et on parle alors de contravariance, un getter devient un setter, un Enumerable devient Observer, Enumerator un Observable.
Getter est itératif (pull) Setter réactif (push).
L’interface d’Observable : onComplete() correspond au type Optionnal, onError(Throwable t) au type Try et onNext(A value) à A : Optionnal[Try[A]].
Dans le monde réel, toute cette token salad est concrètement utilisée par Netflix massivement via RxJava, qui est une librairie et pas un framework (donc complètement adaptable à son besoin).
Ce talk aura fini de me convaincre que la programmation fonctionnelle n’est pas pour moi, ou du moins qu’elle est trop compliquée à appréhender dans un format de conférence ou de crash-course, sans écrire du code fonctionnel soi-même à petits pas.
En plus c’est dommage, pas de micro dans cette salle… Heureusement Erik a du souffle et de l’entrain.

Talk 4 – Migrating to microservices

par Adrian Cockcroft
Qu’est-ce que qu’Adrian a appris pendant ses années à Netflix?
– La vitesse fait gagner le marché
– Enlever la friction du développement logiciel
– Haute confiance, bas niveau de procédures
– Culture de la liberté et de la responsabilisation
– Ne pas faire soi-même les travaux lourds sans valeur métier
– Automatiser les patterns communs
– Les microservices apportent de la vitesse et de la haute-disponibilité
Adrian fait une rétrospective sur tout les types de réaction incrédules qu’il a pu avoir à propos de ses talks sur le fonctionnement de Netflix.
Il remontre la photo du colonel Boyd (cf talk 1), en citant son cycle de décision Observe Orient Decide Act.
Les librairies et frameworks les plus avancés sont maintenant OpenSource, et une entreprise devrait embrasser ce côté du développement. GitHub devient le CV de vôtre entreprise. Utiliser une licence type Apache pour relâcher le contrôle et gagner en ubiquité.
Pour la haute-disponibilité, il faut réfléchir nativement “Cloud”. Micro-service, déployables jamais mis à jour, toujours remplacés par des nouvelles instances (permet un rollback instantané)…
Comment créer un micro-service : 1 microservice = 1 “verbe”, dont la fonction peut être comprise et retenue par un seul développeur
– version : laisser
les vieilles versions s’exécuter, délai d’introduction court mais retraite longue
– librairies clientes : on peut commencer par exposer juste un protocole, mais le mieux est d’être à l’origine des librairies clientes
– multithreading : c’est un problème difficile, utilisation de RxJava et le pattern Observable pour masquer cette complexité. Utiliser Netty pour du NIO
– Messaging / Entreprise Bus : difficulté à l’adapter à la combinaison AP (Availability + Partitionning), réserver pour des cas adapté au “j’envoie et j’oublie” sur des réseaux non reliable
Les microservices matures changent lentement, les nouveaux rapidement. Leur nombre augmente au cours du temps, ils grossissent et finissent par se diviser quand trop gros.
Adrian partage ensuite 3 stratégies pour convaincre des managers impatients :
– Carrotte : sous forme de micro service, ça irait beaucoup plus vite
– Bâton : ok pour faire cette fonctionnalité, mais seulement sur l’architecture micro-service
– Objets Brillants : concentrez-vous sur cette autre partie du système pendant qu’on fait la migration
Il ne faut pas oublier l’automatisation du déploiement (avec des vérifications types “tests canaris”) et le monitoring.

Talk 5 – What every hipster should know about Functionnal Reactive Programming

par Bodil Stokke
L’année dernière, c’était une intervention sur la programmation réactive, mais cette année Bodil nous présente selon un format similaire la FRP, dans le cadre de RxJs.
Après nous avoir évoqué l’univers de “mon petit poney” puis de la programmation fonctionnelle réactive, Bodil entreprend de nous familiariser avec ces deux familles de concepts en javascript.
Visiblement son poney préféré reste Pinkie Pie, et celle-ci sera donc l’héroïne du petit jeu (basé sur les Observables) qu’elle a prévu de live-coder par la suite.
Défilement de la scène, animation du personnage, introduction de la physique (vélocité horizontale et verticale) et des réactions aux frappes clavier…
Tout y passe. On triche parfois avec la gravité (histoire de faire s’envoler pour un temps notre poney), puis on ajuste les paramètres, on s’assure qu’elle ne peut sauter qu’à partir du sol, on ajoute du son, et hop on obtient un mini-jeu 🙂
Bodil ayant choisi un son tiré du jeu Mario, elle ne peut terminer son talk sans ajouter un système de récompenses à capturer… Oui notre poney interagira avec des pièces Dogecoin.

Talk 6 – Mapping Etsy’s Front-end – Tools & Techniques for Managing Complexity at Scale

par Daniel Espeset
Etsy a 65 millions de visiteurs / mois, la frontpage est composée de 300 ressources, environ 180 ingénieurs, des machines de test aussi proches que possible de la prod, 50 déploiements par jour (déploiement continu au coeur de leur culture).
Chez Etsy, “anybody can touch anything”. Culture encore une fois de confiance et de responsabilité, d’expérimentation continue par développements incrémentaux. Les ingénieurs sont possesseurs de leur code, sur l’intégralité de la stack (monitoring, déploiement, etc…), avec des équipes spécialisées qui sont là pour porter assistance.
Les ingénieurs sont censés faire une rotation au cours de l’année sur des “camps de base” pour se familiariser avec des aspects qu’ils ne connaissent pas (et gagner des patchs, façon astronautes).
Comment arrivent-ils à faire quoi que ce soit sur un front-end à cette échelle? Des tas d’outils. Leur base de code CSS, JavaScript, grossis à un rythme rapide (1.67x), pas mal pour une startup âgée de 8 ans.
Essayer de retracer tout les usages d’une resource afin de vérifier qu’on peut la modifier devient une tâche titanesque, raisonner à propos du front-end est difficile et supprimer du code mort est effrayant.
Comment réduire cet effet? Les options : analyse statique, test synthétique, logs d’accès, analyse dynamique. Seul ce dernier est finalement applicable.
Daniel nous présente ensuite l’évolution de leur pipeline de déploiement de code vers leur outil Builda (plus particulièrement le code JavaScript et PHP).
Ensuite, l’outil d’analyse qu’ils ont construit en interne : Ranger en tant qu’API et Lodge comme client. L’outil leur permet de retrouver les hiérarchies d’usage, surveiller l’évolution de la base de code, sortir les plus grosses ressources, effectuer des recherches. Ils passent par des logs d’accès, marquent comme mortes les ressources n’ayant pas été vues dans les logs depuis 3 semaines.

Fin de la journée 2

Du moins en attendant la soirée de la conférence sponsorisée par Atlassian 🙂