QCON NewYork 2015, résumé

le 16/06/2015 par Benoit Lafontaine

QCON New York est vraiment une superbe conférence où à chaque créneau, on hésite entre au moins 2 ou 3 sessions. J'ai eu la chance de pouvoir y assister la semaine dernière et voici donc un résumé des sessions que j'ai pu voir.

Conférence / Organisation / lieu /

Pas mal de pauses entre les sessions, ça me permet de faire les CR en fin de sessions, donc pas mal :)

Café !!! (oui pour 3 jours, c'est un point particulièrement important) * petits stands, mais nombreux et partout moins de monde autour, peu de queues * self service pas de serveurs, ça fait moins classe, mais c'est plus efficaces par contre toujours remplis, pas de "ha merde y'en a plus ici"

Y'a tellement de conférences NETFLIX qu'ils auraient pu avoir un track entier pour eux.

Tendances : On les tendance dans les titres des tracks : microservices, Big Data, mobile & Iot, Reactive, WebFront, containers (docker) et deux trucs que j'avais pas vu avant () dans les conférences : la culture et le développement personnel.

Et du coup, c'est là où je me dis que quand même les tribus OCTO reflètent très bien les tendances. Pour l'instant on n'a pas de trous dans la raquette vis-à-vis de QCon :)

Une maturation autour du discours microservices : ça a aussi des risques qu'il faut prendre en compte. Ne faites des microservices qu'après avoir construit un monolithe. On ne fait pas du microservice Top-Down en phase de conception, ça doit venir d’un processus d'amélioration continu. On peut résumé par "monolithe first, microservices second", qui reboucle avec le post de Martin Fowler : MonolithFirst. Et les monolithes, ça marche bien aussi.

L'agile c'est bien, mais l'important c'est les retours utilisateurs. Du coup, livrez vite, livrez souvent, le déploiement continu c'est cool.

Le Machine Learning sert à plein de choses différentes, c'est bien mangez-en.

La culture est très importante dans les entreprises, il faut que tout le monde aille dans le même sens et se sente responsable (du produit, de la compagnie). Ca rejoint un peu le WHY de Simon Sinek. Pour que les équipes différentes (Dev & Ops, microservices, ...) aillent dans la même direction, il faut qu'elles aient des responsabilités partagées, qu'elles soient « accountable ».

Kafka c'est top, avec les bon plugins, ça doit pouvoir vous faire le café… mais surtout en temps réel, à autant de personnes que vous voulez en même temps et sans jamais perdre de commandes.

ABSTRACTION AND FEDERATION - FROM MICRO CHIPS TO MICROSERVICES, Mary Poppendieck

"Limit risk and lower friction"

Keynote assez sympa, après c'est toujours marrant d'avoir quelqu’un qui vous parle de l'évolution des architectures en commençant par "j'ai commencé à développer avec des cartes perforées".

Un petit condensé de plein de trucs, pas mal de microservices et ses fondamentaux :

On veut déployer indépendamment, ça c’est limiter les risques. Car les grandes releases, c'est du risque, ça rejoint le déploiement continu et du coup docker aussi.
On fait des microservices APRES avoir construit quelque chose qui marche.

Quelques notions intéressantes : pourquoi chercher toujours la non-duplication ? => Aux states, y'a des gouvernements par états, c'est de la duplication, et pourtant ça a des avantages. => Microservices ont leur BDD indépendantes, ca marche aussi. Et pourtant la fonction « stockage » est dupliqué non ? Bref, ça rejoint ce que je dis aussi souvent : c’est pas parce que ça à le même nom que ça doit être la même chose.

DevOps avec une séparation Dev (lower friction) et OPs (limit risk) marche bien si les 2 mondes ont une responsabilité partagée.

AUTOMATING OPERATIONAL DECISIONS IN REAL-TIME @ NETFLIX, Chris Sanden Plein de metriques, plein de serveurs. Dans les serveurs, des fois y'en a qui ne marchent plus bien, c'est normal. Donc on peut faire du Machine Learning pour les trouver automatiquement. Et dans l'idée c'est pas compliqué :

on groupe les serveurs par hardware et software, en se disant que ceux là devraient se comporter de la même façon. On fait tourner un algo de clustering et de densité dessus.
Quand les nœuds se trouvent proches de leurs voisins, c'est logique. Quand un nœud est isolé, c'est qu'il est suspect.
On éteint le nœud suspect. Et comme ils ont un mécanisme d'auto-scaling, y'en a bien un qui va remonter.

NETFLIX’S VIEWING DATA MICROSERVICES: HOW WE KNOW WHERE YOU ARE IN HOUSE OF CARDS, Matt Zimmer Matt Zimmer s’occupe du service qui track qui regarde, quoi, quand, sur quel device.

L’architecture fut d'abord un monolithe, avec plein de trucs stateful. Et c'est pas grave : ça marche bien. Ca scale pas mal… et d'ailleurs, ça aurait pu scaler encore quelques années comme ça. Alors pourquoi changer ? Parce que si ca scale, ça va quand même arriver à des limites, d’ici 3-5-10 ans, ils savent pas exactement, mais vu leurs courbes d’augmentation du nombre d’utilisateurs et de consommation par utilisateurs, ça peut venir plus vite que prévu). Donc déjà autant le faire avec du temps devant soi pour le faire tranquillement au lieu de le faire plus tard dans l'urgence. Mais une des raisons principales est de pouvoir optimiser les couts. Il montre une courbe qui indique le nombre d'instances EC2 active, la courbe est plate, ils n'utilisent pas du tout l'élasticité d'AWS.

Leur migration, qui doit finir dans les semaines qui viennent, aura pris un peu plus de 18 mois. Afin de limiter le risque (cf Poppendieck), ils montent leur version 4 à côté de la version 3 et font du shadow testing : toute requête qui arrive sur la prod est dupliquer vers le nouveau système et les réponses sont comparées pour voir si le nouveau système est satisfaisant ou non. A noter qu'ils ont aussi mis en place un circuit-braker pour éviter d'impacter les utilisateurs si le nouveau système devient lent. Au cours de leur migration, ils ont eu un bug assez important où le fait d'avoir un système event-based leur a permis de rapidement réparer en rejouant tout leurs logs. Du coup, le deuxième grand conseil c'est que d'avoir un système "event-based" et de tout pouvoir rejouer depuis le début, ça a une valeur énorme en cas de crash.

MICROSERVICES AND THE ART OF TAMING THE DEPENDENCY HELL MONSTER, Michael Bryzek Revue de quelques bonnes pratiques de la part du co-founder et CTO de GILT sur leur passage vers une archi microservices. Là encore un petit rappel sur le fait qu'ils étaient partis sur une archi monolithique et que c'était une bonne idée : "monolith first, microservices second". Aujourd'hui ils ont plus de 160 micro-services. Au passage il fait le détail de quelques services et qui montrent bien plusieurs points :

Leurs services font a peu près entre 5 et 20 méthodes, sans qu'il y ait particulièrement de bornes définies à ces chiffres
Chaque service à un langage et un stockage différent (Scala, Java, ruby / Hbase, mongoDB, postgres) en fonction du besoin de performance et aussi de l'année à laquelle le service a été créé.

Ses conseils :

Le design des APIs doit être "First Class", c'est-à-dire avec un soin particulier. Cela veut donc dire aussi d'avoir un design "up-front". Pour ça, d'ailleurs, c'est pas mal d'utiliser les protobuf, thrift, avro ou leur outil maison apidoc.me. Attention, il faut mettre le design upfront en relation avec deux autres points : a) "monolith first, microservices second", du coup quand tu ressens le besoin de détacher un microservice, t'as déjà une bonne idée de comment il devrait marcher, et t'en profite quand même pour passer un peu de temps à réfléchir sur le schéma de ta ressource b) le cycle de vie de ton API : quand t'es en 0.x, tu fais ce que tu veux, tu pète tout à tout moment Quand t'es un 1.x tu t'engage à ne pas faire de breaking change parce que dans ce cas là tu passe en 2.x
Les APIs doivent être cohérentes entre elles Au début, tout le monde faisait son API de la façon la plus intelligente possible. Ils se sont retrouvés avec plein de façons différentes. Aujourd'hui, ils préfèrent avoir des APIs cohérentes entre elles plutôt que d'avoir des designs plus malins pour chaque cas particulier. Bon, au vu de l'exemple qu'il a donné, on peut se dire aussi qu'aujourd'hui ils respectent mieux l'esprit "ressource" de REST.
Garantir la compatibilité ascendante ET descendante. C'est à dire qu'un bout de code écrit sur la 1ère version doit pouvoir tourner sur les données d'aujourd'hui et qu'un programme d'aujourd'hui doit pouvoir tourner sur des données de la première version. Ca implique notamment qu'on ne supprime ni ne renomme d'attributs, que tout nouvel attribut est soit optionnel soit avec une valeur par défaut. Se rappeler quand même qu'avant la version 1.x, on fait ce qu'on veut. Il avait un avis très tranché et je trouve ça assez intéressant parce que ça va un cran plus loin que ce qu’on voit d’habitude.
Générer les librairies clientes... et ses librairies doivent avoir zéro dépendances. Là encore, très intéressant. Le fait de n'avoir aucune dépendance permet d'éviter les problèmes de gestion de dépendance. On peut avoir n'importe quelle version cliente de deux services, ça va toujours marcher. Oui, les développeurs ayant utilisé un jour dans leur vie un client SOAP avec Jaxb sous WebSphere voient bien de quoi il s’agit.

HOW DID WE END UP HERE? Trisha Gee & Todd Montgomery Keynote un peu fourre-tout où on parle d'agile, de diversité homme-femme, d'open-source en passant par le problème des architectes qui ne codent pas (c'est vrai ça, est-ce qu'on voudrait qu'un chirurgien qui n'opère plus depuis 10 ans fasse les protocoles suivis par tout ceux qui pratiquent ?). Plein d'idées intéressantes et rigolotes, si vous avez l'occasion de regarder la vidéo, on passe un bon moment, sans être complètement indispensable. Les idées qui m'on marquées : Selon des études (Gartner, Mackinsey), les projets en Agile réussissent à environ 60% contre environ 45% pour les projets en Waterfall. Enorme écart pour un joueur de poker, mais finalement pas si impressionnant pour des projets, je m'attendais à plus. A noter que les projets sans aucune méthodes réussissent mieux (quelques points seulement) que les projets en Waterfall. Et au final, ce qui à un impact beaucoup plus fort sur les chances de réussites d'un projet, c'est la taille du projet et la taille de l'équipe : les petits projets ont pus de chance de réussir. L'agile c'est bien, mais il faut le faire bien et éviter le "water-scrum-fall". Ce qui importe c'est apprendre, avoir des retours clients, et donc livrer souvent (ça reboucle avec mon ignite-talk à Devoxx : l'itération 1 doit aller en production).

AKKA STREAMS: STREAMING DATA TRANSFORMATION À LA CARTE, Viktor Klang Session assez inintéressante sur AKKA et reactive-streams, où le speaker fait juste le tour des possibilités et méthodes dispo dans AKKA et reactive-streams. Autant lire la doc, ça va plus vite et c'est plus précis : http://akka.io/docs/ https://github.com/reactive-streams/reactive-streams-jvm/blob/v1.0.0/README.md

SCALING STACK OVERFLOW: KEEPING IT VERTICAL BY OBSESSING OVER PERFORMANCE, David Fullerton Session très intéressante sur l'architecture de StackOverflow, principalement très monolithique basée sur C# et MSSQL, qui répond parfaitement à leur besoins (beaucoup de reads, principalement la home, assez peu de contenu personnalisé). Leur architecture est très "simple" :

un load balancer
9 serveurs Web
une grosse base de données.

Contrairement à pas mal de monde, ils déploiement ce monolithe très rapidement (~3 mins) et plusieurs fois par jour. Leur nombre de serveurs est un peu surdimensionné, mais ça leur permet d'être tranquilles en cas de maintenance, de crash serveur ou autre. Le processus général pour arriver à une architecture si "boring"est :

partir de ce qu'on connait. C'est pour ça qu'ils n'ont pas de stack style NodeJs, ruby ou scala
mesurer en live
fixer ce qui est lent

La performance est considérée comme une feature majeure, leur objectif est d'avoir tout en dessous de 30ms. En cas de lenteur, ils ont une sorte de "stop the line" et tout s'arrête jusqu'à ce que les performances soient revenues. Au fur et à mesure, ils ont sortis des composants (ex: recherche dans Elastic Search) ou développé des composants spécifiques (nouvel ORM pour remplacer LINQ). Au final, sa présentation conforte le message général de la conférence sur les microservices : commencez à construire un monolithe et couper lorsque le besoin s'en fait sentir, une bonne quote pour résumer ça "Extract service that solve real problems, not imagined ones". Quelques spécificités assez intéressantes : Ils ont assez peu de tests et n'hésitent pas à tester directement en production. Les feature flags, des canary releases, associés à leur capacité à livrer vite leur permette de fixer rapidement les problèmes. Pareil pour les tests de performance : direct en production.

GOOGLE DOCS - ARCHITECTING THE WORLD'S LARGEST REALTIME COLLABORATION SYSTEM AND DEVELOPER SDK, Micah Lemonik Dans un premier temps, l'ingénieur en chef de Google Docs montre rapidement l'architecture très directe utilisée sur ces applications : un client JS, un serveur Stateful, une base de donnée. Le côté stateful explique pourquoi notamment, il y a une limite sur le nombre de collaborateurs simultanés sur ces applications. Et même s'ils s'appellent Google, ils ne peuvent pas dépasser le théorème de CAP. Ensuite, il explique pourquoi pour gérer la concurrence, ils n'ont pas pu utiliser les mêmes mécanismes sur Docs que sur spreadsheet. Difficile à retranscrire sans écrire un bouquin. L'idée générale c'est que sur spreadsheet, les actions sont toutes commutatives, que l'action A arrive avant la B, n'a pas d'importance. Alors que sur Docs, ce n'est pas le cas. Du coup, ils sont obligés de faire des transformations (mathématiques) pour faire marcher le tout. Enfin, il explique comment comportement du "Undo" aujourd'hui est bien ce que les gens attendent mais est complètement contre-intuitive d'un point de vue ingénieur ou mathématique. Le problème est : la case A1 est à 6. Pierre change la valeur à 7, Michel la change à 8. Pierre fait "undo", que ce passe-t-il ? Réfléchissez-y 5 minutes sans ouvrir spreadsheet... moi je me suis fait avoir. Et si vous voulez l'explication, regardez la vidéo :)

RESULTS DRIVEN DEVELOPMENT & PUSHING THE BOUNDARIES OF MOBILE, Aaron Glazer Comme le mec à une boite qui fait de l'A/B testing sur mobile et de l'analytique, il a prêché faire de l'analytique et de l'A/B testing sur mobile. La présentation elle-même n'apportaient pas grand chose. Au fond, il disait que l'ensemble de l'équipe - métier, marketing, devs, ops, etc - devraient tous suivre le même focus final - augmenter les ventes par exemple - et que ça aidait vachement. Pour exemple, il a pris une application mobile sur laquelle ils avaient remplacé les 5 écrans d'explications + sign up, par un seul écran avec une promsesse et un login facebook. Résultat : une augmentation drastique de l'utilisation de l'application et du nombre de ventes finales (focus premier). Voilà voilà… Les chiffres qui m'ont interpelés sont ceux du nombre de mot qu'ont a sur les différents écrans :

Desktop ~400 mots, on a la place pour s'épandre (et du coup ne pas être précis)
Mobile ~30 mots, on a le droit à une promesse grosso modo
Watch ~5 mots, là il faut carrément jouer à pyramide

OPEN Spaces Les Open-Spaces sont toujours des moments exceptionnels où on discutent de plein de sujets avec des gens d'horizons variés. Ce que je retiens surtout est une discussion très intéressante autour de blockchain, la technologie sous-jacente à bitcoin. Olaf Carlson-Wee indique qu'ils travaillent pour rajouter des fonctionnalités dans blockchain et que ça pourrai devenir "turing-complete" c'est-à-dire de pouvoir exécuter tourner n'importe quel fonction (aujourd'hui, la blockchain n'en a que 2). On pourrai donc imaginer utiliser cette techno dans plein d'autres secteurs... a condition d'accepter la baisse de performance du à la techno, a peu près 10 fois moins rapide. Les cas d'usages seraient multiples (DNS, certificats SSL, ...) mais celui qui m'a particulièrement intéressé est le vote : on pourrai alors avoir un système de vote électronique que n'importe qui pourrai vérifier. La difficulté serait de continuer à garantir cette vérifiabilité tout en garantissant l'anonymat. Et là peut-être que l'idée ne serait pas de mettre les votes eux-mêmes dans la blockchain, mais uniquement le programme. Et du coup, je me suis rappelé du projet http://ethereum.org/ qui a pour but justement de faire quelque chose du genre.

Keynote de cloture, Mark Rendle Keynote de fermeture très rafraichissante, après 3 jours c'était bienvenue, où on fait le tour de A à Z des "xxx driven development". Quelques exemples :

BDD : Buzzword Driven Design où comment déveloper une application NodeJS-AngularJS-MongoDB-hadoop, sur une architecture microservice... même si c'était juste pour afficher le menu de la cantine.
CDD : Clipboard Driven Design (aka Stack Overflow Driven Design)
WDD : Wizard Driven Design, les développeurs VBA voient de quoi on parle. Et aux développeurs Rails ou Yeoman ou autres : c'est pas parce que c'est en ligne de commande sur un terminal noir et blanc que c'est pas des wizards ;)

Voila pour les sessions que j'ai eu la chance de voir. Toutes les vidéos devraient arriver publiquement dans 6 mois je crois (oui c'est long), mais pour certaines conférences, les slides sont dispos en téléchargement : https://qconnewyork.com/ny2015/schedule

Enjoy :)