10 Jun 2013, 22:00

dotScale, synthèse de la conférence

Sur un coup de tête, il y a quelques mois, je m'étais pris une place pour dotScale et poser le RTT associé. En début de semaine dernière, je m'étais interrogé sur mes motivations et ce que j'allais bien en ressortir. Force est de reconnaitre que je n'ai pas été déçu, même si je ne m'attendais pas tout à fait à ça. Les "Dot" conférences se veulent être en quelques sorte les TEDx des techos, on sort donc du format de présentation classique, tout comme l'approche du sujet qui était cloud, big data et scalabilité. Ci-après ma tentative de synthèse.

"Be ready to fail"

Que ce soit Jonathan Weiss (Amazon), Quentin Adam (Clever Cloud) ou encore Barry Abrahamson (Wordpress), on sent qu'il y a une véritable culture de l'échec qui a été adoptée. Loin de sanctionner l'échec comme on peut le faire en France et de vivre dans l'utopie de vouloir atteindre la perfection, le postulat est de dire qu'à tout moment, l'erreur / l'incident / l'échec peut advenir. C'est normal, c'est sain et ça permet d'apprendre. Il faut donc vivre avec et s'organiser en conséquence.

On retrouvera ainsi l'exemple de Netflix qui a tellement adopté cette culture que l'organisation elle-même crée de l'incident pour valider sa résilience. Pour l'histoire, ils vont jusqu'à mettre 1/3 de leur plateforme HS pour voir si elle peut tenir la charge... Cela prend le nom de Chaos Monkey ou de Dystopia as a service.

Quel exemple de maturité sur le sujet de leur part et que de chemin à parcourir pour bon nombre d'entreprises...

"Monitor and get metrics"

Un autre point assez globalement partagé, c'est de tester / mesurer / surveiller. Si ce pré-requis n'est pas satisfait, impossible d'aller où que ce soit et de savoir ce que l'on fait. Les métriques sont aussi bien techniques (consommation CPU, RAM, réseau, etc) que fonctionnels (nombre de ventes, nombre de création de compte, etc)

Résilience

Autre point mis en avant, la résilience du système quant à son activité et ses incidents au travers des quelques pratiques suivantes :

  • Validation permantente de sa capacité à sauegarder/restaurer ses données : Wordpress s'est donné par ex un SLA d'1 heure pour remonter un serveur et un jeu de données associé from scratch. Par ailleurs, la partie sauvegarde représente environ 10% des couts d'infrastructure de Wordpress.
  • Ne pas utiliser la RAM pour y stocker des données un tant soit peu persistante ; si le code/serveur échoue, la données est perdue
  • Ne pas stocker ses fichiers sur un simple FS, ça ne "scale" pas ; des solutions plus élaborées de FS distribuées/intelligents à la Amazon S3 par ex sont plus préférables
  • Contenir au maximum les effets potentiels d'un changement ; que ce soit par des approches modulaires (chaque composant est isolé/isolabe et est au service d'un autre) ou bien le recyclage permanent de ses VM en tuant les moins performances ou encore en déployant un changement sur la population la plus petite du service, la logique veut qu'un changement ne doit impacter dans un premier temps qu'un minimum de personnes/serveurs. Une fois le changement validé, un déploiement à plus grande échelle est possible.

Cloud et coût

Mentionné lors d'un lightning talk de 5mn, le sujet de l'approche "Cloud Costing Driven" a été abordé : comme chaque VM est facturée à l'heure / utilisation, il va être facile de faire la chasse aux couts inutiles (oubli d'arrêt d'une VM de développement le week-end, VM du plan de production de nuit allumée 24/24, etc) ou bien de quantifier finement le coût de tel ou tel changement (le changement X a accru notre consommation de Y %)

Le coût va donc gagner en visiblité et en précision, contrairement à aujourd'hui où la VM a un prix fixe et lissé sur l'année, quelque soit son utilisation.

Autres bonnes pratiques

De façon plus classique, on retrouve :

  • Séparer les process et les données, en considérant énormément de choses commes des données (données utilisateurs mais aussi session, voir les événements en eux mêmes),
  • "Statelessness"
  • Utiliser les technologies qui répondent au besoin et non les technos "hypes" / que vous aimez
  • Ne créer pas des "monstres", ils ne scalent pas
  • Eviter la magie ; ie il vous faut connaitre le fonctionnement de vos applications / framework / ... pour qu'un mécanisme interne ne vous empêche pas de passer à l'échelle
  • "Divide & conquer" : render votre code modulaire et déployer les comme des services les uns aux autres ; par ailleurs pour modulariser vos applications, utiliser un "message broker" (au passage, Cron n'est pas un message broker ; visez plutot Celery, RabbitMQ, Redis & co)
  • Les gros calculs se font en asynchrones
  • Utiliser des reverse proxy comme passerelle / passe-plat entre votre application et les utilisateurs
  • Automatiser au maximum

Autres sessions

  • Gandi.net, via Thomas Stocking, nous a présenté leur technologie TRILL/VNT qui leur permet de s'affranchir des 4096 VLAN traditionnels et en proposé plus de 16 millions (4096^2) en s'appuyant sur des RFC existantes. Leur solution sera bientôt disponible sous license Open Source vu qu'ils voient cette avancée comme n'étant pas un avantage concurrentiel et surtout pour espérer fédérer d'autres acteurs autour. En effet, d'autres implémentations sur la base d'autres protocoles & RFC seraient possibles. Un des points fort étant que leur solution ne demande pas d'infrastructure particulière pour en profiter.
  • Solomon Hykes, à l'orgine de Docker, nous a expliqué le chemin parcouru pour en arriver à cette solution :
    • Livrer du code est une activité pénible et requiert beaucoup de main d'oeuvre
    • Ils se sont inspirés de l'industrie du transport de marchandise, qui a fini par inventer un format unique pour transporter n'importe quel objet d'un point A à un point B : le container.
    • Docker se veut donc le packaging standardisé d'une application et ses dépendances.
    • C'est écrit en Go et cela s'appuie sur les containers LXCE.
  • Mandy Waite, de Google, nous a présenté le projet "big data" qu'elle a mené pendant la dernière Google IO en déposant 500 bornes capables de capter un certain nombre d'informations environementables : bruit, température, nombre de pas, ondes, etc durant toute la conférence. Les données collectées via les bornes (équipement à base d'Arduino) étaient ensuite poussée dans un mix Google App Engine / Google Compute Engine / Google Big Query et Google Storage afin d'être analysées et restituées.
  • Shay Banon, créateur d'Elastic Search, nous a présenté pourquoi il a créé ElasticSearch et plus précisément en quoi un système distribué demandait une approche différente d'un système centralisé et quels étaient les paradigmes associés.
  • Doug Cutting, créateur d'Hadoop, nous a présenté l'écosystème Hadoop ; ayant déjà eu une présentation similaire il y a peu (certes pas par son créateur), le point d'intérêt pour moi a été de voir le lien entre la publication de travaux de recherche (principalement par Google d'ailleurs) puis quelques années après l'implémentation de ces idées dans un modèle Open Source dans le monde Hadoop. Avec une pensée intéressante sur justement cette transition d'une recherche à une iméplementation open source : l'open source permet de rendre qqc accessible à tout à chacun, sous la forme d'une commodité.
  • Joshua McKenty, co-fondateur d'OpenStack, est quant à lui revenu sur la façon dont la communauté OpenStack est organisée et la façon dont elle "scale". Le point majeur de cette présentation étant de voir la liaison entre la culture, la communauté et le code en s'appuyant sur la loi de Conway. La culture façonne la communauté qui à son tour impacte le code.

Au final, une journée étonnante et riche en enseignements. Au delà des technos, c'est au final cet aspect culture qui me parait le plus important / intéressant de valoriser et de voir le chemin qu'il nous reste à faire...