Retour sur la Velocity New York Conference 2016

Photo Credit: oreillyconf

Retour sur la Velocity New York Conference 2016

Nous étions cette année à New York, à quelques blocs de Time Square, pour suivre l’édition New Yorkaise de la Velocity Conference 2016. C’est une conférence que nous apprécions particulièrement et à laquelle nous nous rendons quasiment chaque année, soit dans son édition européenne (Berlin, Londres, Barcelone, et Amsterdam cette année en novembre), soit aux U.S. (précédemment Santa Clara, New York cette année, et San José l’année prochaine). C’est l’occasion de suivre une conf de très haute qualité composée de 4 ou 5 tracks en parallèle, dédiée aux problématiques de performance et de scalabilité. On remarque que d’année en année la conférence s’est réorientée autour du mouvement DevOps, alors qu’elle était précédemment beaucoup plus centrée sur la WebPerf (desktop et mobile).

La conférence commence par l’Ignite (sorte de mini conférence dans la conférence), basée sur un format court (type Lightning Talk) de 5 minutes pour une présentation de 5 slides défilant automatiquement. On retiendra de cette première partie des talks intéressants exposant les tristes chiffres de la diversité dans la tech aux US, mais aussi une conférence très drôle de @beldhalpern de @ThePracticalDev sur des parodies des livres OReilly (voir le O RLY Cover Generator) :

L’ignite s’est fini sur le célèbre Ignite Karaoké où 16 volontaires se sont prêtés au jeu de cet exercice hilarant mais tellement difficile, consistant à improviser une conférence sur le sujet de son choix sur 5 slides inconnues de l’orateur et qui défilent automatiquement au bout de quelques secondes 😃. Ce qu’on fait aussi chez M6Web de temps en temps nommé Karaoké Slideshow et que Kenny avait animé lors d’un Forum PHP (voir la vidéo).

O'Reilly Conferences sur Flickr Crédit : Flickr

Nous avons ensuite suivi deux jours de conférences dont les thèmes majeurs étaient :

  • Les Service Workers
  • Les microservices
  • Le monitoring
  • HTTP2
  • La sécurité des apps
  • Les détections d’anomalie
  • Les ChatOps
  • Le WebMobile, AMP et les PWA

ChatOps

Un des sujets assez récurrent, notamment dans la mouvance DevOps est l’utilisation des ChatOps, sujet popularisé par Github (via Hubot). Cela consiste généralement en un bot ou une IA posée sur un outil de Chat type Slack, Flowdock ou Hipchat, permettant de simplifier la communication entre différentes équipes et les différents outils (ticketing, alerting, monitoring, état d’une machine, etc). Une démo de l’IA de Dynatrace à reconnaissance vocale à été faite, montrant comment par la voix, on pouvait recevoir dans l’outil de Chat les infos sur les incidents de la veille, créer les tickets de support etc. Voir ici. Un peu gadget, mais rigolo.

L’un des points à retenir, c’est que même si ces outils font partie de la « culture » DevOps, ce n’est pas l’ajout d’un de ces outils qui fera apparaître cette culture dans votre entreprise si vous ne l’avez pas.

Tools will not fix a broken culture

O'Reilly Conferences sur Flickr Crédit : Flickr

Le WebMobile, AMP, et les PWA

Plusieurs conférences avaient pour but de comparer ce que l’on pouvait obtenir de nos jours via du WebMobile versus ce que l’on a sur les apps natives. Le fossé s’est énormément rétréci et les WebApps ont désormais accès à la plupart des fonctionnalités présentes côté natif :

  • Notifications
  • Ajout sur le Home Screen de l’icone
  • Full Screen
  • Orientation
  • Gestion hors ligne

Ce qui nous amène aux Progressive Web Apps : PWA

Pete Lepage @petele de chez Google nous a notamment présenté des projets open-source de Google pour mettre en place différentes politiques de cache via les « serviceWorkers » (voir https://developers.google.com/web/tools/service-worker-libraries/), ainsi que les futures api : Web Payments, Credential Management …

Toujours sur la partie mobile, Malte Ubl (@cramforce), core développeur de AMP, nous a présenté le futur de ce protocole de Google pour offrir des pages plus rapides pour la consultation de site média sur mobile.

AMP is a web component library, validator and caching layer for reliably fast web content at scale

En commençant par un bilan d’AMP, 3000 PR + 200 contributeurs (au bout d’un an seulement !), Malte nous a expliqué qu’un site mobile très optimisé pouvait logiquement être plus performant qu’AMP.

Arriveront prochainement sur AMP, le support des formulaires, des optimisations avancées d’images via le Google AMP Cache, des Service Workers pour AMP pour ne jamais télécharger AMP dans le « chemin critique » du chargement de la page.

Un petit focus a aussi été fait sur les PWA et AMP avec amp-install-serviceworker qui est un Service Worker permettant d’installer la PWA après chargement de AMP, pour faire une upgrade transparente de AMP vers une PWA (Voir une démo ici choumx.github.io/amp-pwa)

AMP : « Start Fast, Stay Fast »

Nous avons aussi vu une conférence sur l’optimisation de la consommation des webApps en terme de CPU / temps de réponse, notamment via l’étude des capacités JS de chacun des devices/OS avec le benchmark JetStream Javascript.

On découvre notamment que l’iPhone 7 a des capacités assez impressionnantes, contrairement à l’iPhone 5C, que le mode « économie d’énergie » ou encore une bonne insolation rendent les devices beaucoup moins performants. D’excellentes slides à voir ici : hearne.me/2hot

WebPerf

Côté WebPerf, peu de grosses nouveautés, on retiendra @nparashuram qui nous a montré comment automatiser le “profiling” des ChromeDevTools dans Node.js via ChromeDriver !

Plus d’infos ici : http://blog.nparashuram.com/2016/09/rise-of-web-workers-nationjs.html

Tammy Everts (@tameverts de Soasta) et Pat Meenan (@patmeenan de Google et créateur de WebPageTest) nous ont fait un gros retour basé sur toutes les métriques récoltées par Soasta mPulse (outils de Real User Monitoring en SAAS) afin de déterminer des corrélations entre les temps de chargement et d’autres métriques (taux de rebond, conversion, etc.) grâce à l’application de concept propre au Machine Learning sur une quantité énorme de data. Toujours intéressant.

Slides ici : http://conferences.oreilly.com/velocity/devops-web-performance-ny/public/schedule/detail/51082

O'Reilly Conferences sur Flickr Crédit : Flickr

Côté Single Page App, le Server Side Rendering est revenu à plusieurs reprises afin d’avoir des SPA performantes dont le premier rendu est généré côté serveur, ce que permet nativement React, et désormais Ember et Angular 2. Voir notre article sur l’isomorphisme : http://tech.m6web.fr/isomorphic-single-page-app-parfaite-react-flux/

Coté HTTP, on retiendra Hooman Beheshti qui nous a fait un retour d’expérience sur HTTP2. Après une explication des nouveautés du protocole (binary, single, long-lasting TCP connection, streams encapsulation, frames, bi-directional…), une comparaison avec HTTP 1 nous a été exposée. En conclusion, HTTP2 est complexe et la migration n’est pas une simple modification de paramètre. Bien que cette nouvelle version est légèrement plus rapide, en particulier sur un réseau lent (<1Mbps), le protocole supporte très mal les pertes de paquets ou les fortes congestions à cause de l’unique connexion (TCP slow start). La recommandation est de tester sur chaque site et d’optimiser ses pages selon la version d’HTTP utilisée. Une piste serait HTTP2 over UDP.

Les slides

DevOps

De nombreuses conférences avaient pour objectif d’aborder les bienfaits du DevOps et plus largement les bonnes pratiques liées au mouvement afin de gagner en qualité et fiabilité.

On retiendra notamment la conférence de Cornelia Davis (DevOps: Who does what?) explicitant les différents rôles dans un SDLC (Software Development Life-Cycle) et leur répartition en équipe dans l’organisation.

Les rôles dans le SDLC :

  • Architecte : Ent Archi, Biz Analyst, Portfolio Mgmt
  • SCO : Info sec
  • Infra : Srv Build, Cap Plan, Network, Ops
  • Middleware/AppDev : Middleware Eng, SW Arch, SW Dev, Client SW Dev, Svc Govern
  • Data : Data Arch, DBA
  • Biz : Prod Mgmt
  • Ent Apps : DCTM (Documentum) Eng.

La répartition en équipe proposée :

Platform (unique / transverse) :

  • Middleware/AppDev : Middleware Eng, Svc Govern
  • Infra : Srv Build, Cap Plan, Network, Ops
  • SCO : Info sec
  • Data : DBA

Customer Facing App (de 1 à n équipes)

  • Middleware/AppDev : SW Arch, SW Dev, Client SW Dev
  • Data : Data Arch
  • Infra : Cap Plan, Ops
  • Biz : Prod Mgmt
  • Architecte : Biz Analyst

Enablement (unique / transverse) :

  • Architecte : Ent Archi, Portfolio Mgmt

DCTM - Documentum (Enterprise Content Management Platform) (unique / transverse) :

  • Infra : Ops, Cap Plan
  • Ent Apps : DCTM (Documentum) Eng.

On notera notamment la présence d’Ops dans les équipes Customer Facing App et inversement de Middleware Eng dans l’équipe Platform.

De même, la présence d’architectes transverses (enablement) permet de garder une architecture cohérente. (Pas de slides disponibles pour cette conférence)

O'Reilly Conferences sur Flickr Crédit : Flickr

Microservices

La conférence de @susanthesquark, axée sur les microservices, rappelait quelques bonnes pratiques :

  • Architecture sans SPOF
  • Ne pas laisser la dette technique s’accumuler
  • Déploiement continu
  • Travail en équipe entre Dev / PM / SRE
  • Monitoring
  • Procédures standard de gestion des incidents
  • Post-mortem pour apprendre de ses erreurs…

Les slides

Concernant le monitoring des microservices, la conférence de Reshmi Krishna @reshmi9k s’intéressait à l’analyse de la latence, inhérente à ce type d’architecture. La principale technique proposée est celle du suivi d’une requête de bout en bout, grâce notamment à l’outil Zipkin. De même, une gestion des timeouts globale (pour chaque requête pour tous les microservices) et dynamique (selon le contexte) permet de maîtriser les problèmes en cas de ralentissement d’un service en particulier.

Les slides

Sécurité

Concernant la sécurité, la conférence de Kelly Lum @aloria, passait en revue le minimun vital :

  • La sécurité doit être pensée dès la conception
  • Permettre aux utilisateurs de reporter facilement des problèmes de sécurité et être à l’écoute des réseaux sociaux
  • Toujours remercier les utilisateurs signalant les failles
  • Avoir une équipe testant régulièrement la sécurité (Crack Team).
  • En cas de failles de sécurité, après correction, toujours analyser les causes et apprendre de ses erreurs.

Les slides

Conclusion

Vous pouvez retrouver la plupart des slides ici. et voir les vidéos de certaines conférences ici. ou ici.

Les photos officielles de la conf sont ici.


En passant, si vous avez trouvé une faute de frappe, vous pouvez forker et éditer ce post. Merci beaucoup !