Ce lundi avait lieu la seconde édition de dotScale, conférence à Paris traitant de scalabilité, DevOps et systèmes distribués. Cet événement, à l’instar de ses cousins en dot s’inspire de TED et propose un format « court » de 20 minutes par intervention. L’intégralité de ces conférences sera disponible gratuitement en ligne.
Je vous propose ici mon retour sur cette édition 2014.
À propos des dotConferences – @dotConferences
Cette édition a été l’occasion d’annoncer deux nouvelles pour les dotConferences :
- Tout d’abord la publication du Hacker pledge, un manifeste proposé aux entreprises qui s’engagent à proposer un espace de travail « hacker friendly » à leur salariés. Ce manifeste a vocation à être représentatif de nous tous, c’est pourquoi vous pouvez y proposer des pull-requests sur GitHub.
- Dans la même lignée, l’équipe a annoncé l’ouverture de dotJobs, un annuaire des entreprises ayant signé le Hacker pledge sur lequel celles-ci peuvent proposer des offres d’emploi.
Matthew Ahrens – @mahrens1
Matthew Ahrens a ouvert la journée en présentant ZFS. Il présente ce système de fichiers comme particulièrement adapté pour résoudre les problèmes de cloud en insistant sur la facilité de récupération, l’attachement / le détachement de volume suivant les besoins…
Il a également présenté OpenZFS, un projet « chapeau » visant à promouvoir ZFS et à encadrer son développement.
Laurence Moroney – @lmoroney
Laurence Moroney est venu nous parler de boys band. Et tout particulièrement de One Direction qui a organisé une diffusion sur Internet d’un événement sur 7 heures au cours duquel les internautes étaient invités à répondre à un quizz toutes les dix minutes.
Ainsi, 700 000 utilisateurs se connectaient simultanément toutes les 10 minutes, posant deux problèmes à résoudre :
- répondre efficacement à ces pics ;
- ne pas gaspiller la capacité disponible en restant inactif entre ces pics.
Travaillant chez Google, la solution proposée par Laurence Moroney est évidemment à chercher du côté de Google Compute Engine. Il a montré qu’il était possible d’adapter la capacité à la charge en temps réel sur une très courte échelle de temps. Il a néanmoins insisté sur la nécessité d’adapter le traitement au besoin métier effectif : est-il nécessaire de savoir quelles ont été les réponses de chacun au quizz ? Le score total de chaque internaute n’est-il pas suffisant ?
Par une série d’exemples, il illustre la simplification du problème que peut apporter un simple ciblage des vrais besoins métier.
Fabien Potencier – @fabpot
Fabien Potentcier a pris le parti de parler du langage que nous avons tous appris à détester : PHP. Lui-même annonce détester PHP en tant que langage. En revanche, il annonce également adorer PHP en tant que plateforme.
Il explique le manque de cohérence du langage par l’absence d’un « dictateur ». Un développeur ayant un besoin implémentera dans le langage sa solution au besoin qui sera intégrée sans harmonisation. D’ailleurs, PHP est développé sans aucune spécification.
Cependant, PHP a été conçu et pensé pour le Web. C’est ce qui le rend particulièrement attractif, avec sa simplicité d’installation, de configuration et d’hébergement. Le cycle de vie d’une requête (init, execute, shutdown) le rend particulièrement stable et prévient les fuites mémoires.
En revanche, cette conception n’est pas adaptée pour la performance. Les applications PHP sont lentes (ralenties) par ces phases d’initialisation et d’arrêt à chaque requête. Facebook a développé HipHop Virtual Machine (HHVM) en réponse. Taquin, Fabien Potencier demande si cela ne va pas rendre PHP à nouveau hype.
Mitchell Hashimoto – @mitchellh
Au commencement étaient les nœuds qui hébergeaient des services. Vinrent alors les hyperviseurs pour gérer ces nœuds, puis les conteneurs pour héberger des services sur les nœuds. Les environnements sont de plus en plus complexes. « Plus de tout, plus de problèmes », résume Mitchell Hashimoto, créateur de Vagrant et Packer.
Pour simplifier la gestion de ces environnements, il vient de publier Consul qui répond à trois besoin :
- Où est le service foo ?
- Le service foo est-il joignable ?
- Quelle est la configuration du service foo ?
L’interrogation de Consul peut se faire aussi bien par DNS que par HTTP. En exemple, la gestion multi-datacenters :
$ dig my-app.paris.consul. +short<br></br>
10.2.0.1<br></br>
10.2.0.2<br></br>
$ dig my-app.newyork.consul. +short<br></br>
10.2.0.3
Alison Gianoto – @snipeyhead
Une constante nécessaire des conférences techniques : l’intervention de sécurité. Celle qui dit que tout est probablement pire que ce qu’on imaginait. À dotScale, cette année, c’est Alison Gianoto qui s’y colle.
Elle commence par citer une série de chiffres.
- En 2012, on n’avait détecté qu’une « grosse » faille. On en a détecté 8 en 2013.
- En 2011, le nombre d’attaques par jour s’élevait à 190 000. En 2013, il était de 570 000.
- 230 millions d’identités ont été volées en 2011. En 2013, ce nombre a augmenté jusqu’à atteindre les 552 millions.
S’il est vrai qu’on ne peut prendre en compte tous les risques, on ne peut négliger aucun risque. Les raisons des piratages sont variées : SEO « blackhat », jeu, vol de secrets, demande de rançon… la menace doit être prise au sérieux. Sous-estimer un risque revient à en augmenter la surface d’attaque.
Trois grands principes sont à retenir pour évaluer les risques : CIA.
- Confidentiality : règles à suivre pour limiter l’accès à l’information.
- Integrity : assurance que l’information est intègre et digne de confiance.
- Availability : garantie que l’accès à l’information est fourni aux personnes autorisées.
Alison Gianoto suggère d’étalir une matrice des risques dont elle propose un modèle afin de les évaluer au mieux.
Jean-Michel Lemieux – @jmwind
Jean-Michel Lemieux fait remarquer que l’on passe souvent beaucoup de temps à déterminer « comment » faire quelque chose et beaucoup trop peu sur « quoi » faire réellement, à se demander ce qui est vraiment utile.
Il suggère notamment d’avoir recours au pretotyping (pour pretend **totyping). Il l’illustre avec le prototypage du PalmPilot, l’agenda de poche de la fin des années 90. Afin d’en valider l’utilisation, son concepteur l’a simplement… dessiné sur un bloc de papier. Il simulait sa prise de réunion en utilisant ce bloc de papier en faisant comme s’il saisissait effectivement son rendez-vous dans la machine ; cela lui a ainsi permis de valider les cas d’utilisation du produit dans des conditions réelles et ce, à coût zéro.
Cet exemple a permis d’introduire ce qu’il a appelé l’extensibilité dans le cloud. Il prône la vision du produit en tant que plateforme et de la plateforme en tant que produit : l’application est en elle-même le support qui permet de l’enrichir et tous les utilisateurs en sont les contributeurs. Un exemple en serait la marketplace de Google Docs.
Thomas S. Hatch – @thatch45
Thomas Hatch est le créateur de SaltStack, un outil permattant d’automatiser les tâches d’exploitation du matériel jusqu’aux applications. Il revient ici sur la vision qui l’a poussé à créer SaltStack.
Le nerf de la guerre est pour lui la communication ; une communication qui doit nécessairement être normalisée. La gestion de configuration se conforme aux points suivants :
- elle doit être impérative en exécutant des commandes dont le comportement est prédictible ;
- elle doit être déclarative ;
- elle doit être déterministe ;
- elle doit être autonome ;
- elle doit fonctionner partout, quel que soit l’environnement ;
- elle doit pouvoir s’interfacer avec le reste du monde.
Jeff Lindsay – @progrium
Jeff Lindsay a créé Flynn que l’on pourrait définir de façon réductrice comme un PaaS open-source (avec une licence pas très standard) basé sur Docker.
Pour ma part, j’avoue ne pas avoir bien saisi ce qui le caractérise d’un autre PaaS (outre Docker) mais l’engouement autour du projet incite à aller voir de plus près.
Faidon Liambotis – @faidonl
Faidon Liambotis nous a présenté les dessous de Wikipédia. Pour ne citer que quelques chiffres, Wikipédia affiche entre 20 000 et 40 000 pages par seconde, 20 milliards par mois. Les internautes éditent 40 000 articles par heure. Pour celà, les Ops de la Fondation Wikimedia n’utilisent que des composants libres (cela inclut de ne pas passer par des CDN tiers). Seuls certains équipements réseau sont propriétaires, faute de choix.
Tous les serveurs tournent sous un Ubuntu LTS (en différentes versions). Puppet assure la gestion de la configuration et SaltStack l’exécution et l’orchestration.
Un load balancer géographique permet de rediriger les requêtes vers les datacenters les plus proches. Celui-ci résout environ 9 000 requêtes par seconde en crête. Les load balancers frontaux sont de « simples » machines Linux : encore une fois, pas d’équipement propriétaire coûteux.
Les fichiers multimédias représentent 800 To de données brutes. Celles-ci sont stockées au moyen d’OpenStack Swift.
Pour en savoir plus sur les différents projets de la Fondation Wikimedia ou pour participer, un wiki est disponible à notre destination.
Robert Kennedy – +RobertKennedyOnGooglePlus
La mise en ligne du site healthcare.gov était un pilier de la réforme dite « Obamacare » aux États-Unis. Ce site a fait beaucoup parler de lui pour ses ratés spectaculaires à l’allumage. Robert Kennedy fait partie de l’équipe qui a été appelée pour sauver le projet et nous a cité des morceaux choisis pour expliquer l’échec du lancement.
Il note tout d’abord que les différentes entreprises (des grosses, et des connues) n’étaient engagées contractuellement qu’à réaliser individuellement que certains services. Aucune n’était responsable de l’atteinte d’un produit fini et fonctionnel. Chacune d’elles a donc géré son propre projet et le cloisonnement des responsabilités a conduit à un cloisonnement de l’information.
La mise en production n’avait pas été pensée dès le début. C’est ainsi que l’application est partie en production sans être monitorée.
L’environnement de travail était également nuisible à la responsabilisation. Le manque de bienveillance incitait chacun à tenter de masquer ses erreurs (par peur d’être licencié), ce qui, en plus d’en retarder la correction, la complique également.
De manière globale, il estime que les moyens mis en œuvre pour ce projet étaient bien en deçà des besoins compte tenu de la visibilité du projet et de l’ampleur de la réforme.
Paul Mockapetris – @svnr2000
Paul Mockapetris s’interroge sur la nécessité de remplacer le DNS, une interrogation qui mérite d’être écoutée lorsqu’elle vient de son concepteur. Il pointe d’emblée les limites du DNS :
- limites opérationnelles (taille des paquets, logiciels imparfaits dans les points d’accès…) ;
- limites du protocole (difficulté à définir de nouveaux formats) ;
- limites des processus (le DNS OP WG définit des mécanismes et pas des processus).
Paul Mockapetris voit deux alternatives :
- attendre le déclin de DNS, quitte à précipiter sa chute ;
- mettre au point un « DNS v2 » en s’inspirant des bonnes idées qui ont émergé depuis trente ans.
Il reste alors à déterminer le bon assemblage ne contenant ni trop peu, ni pas assez de nouveautés.
Cette présentation aura également été l’occasion d’aborder les Object Naming Service.
Le mot de la fin
Le format des dotConferences, atypique, est rafraîchissant. S’il est parfois frustrant de voir une intervention limitée à 20 minutes, cette durée permet néanmoins une bonne dynamique qui ne laisse pas le temps à l’auditeur de s’endormir.
Cette journée aura une fois de plus confirmé l’engouement collectif pour Docker qui a d’ailleurs remporté le dotScale Prize. Cet engouement s’affiche presque comme une évidence tant l’outil permet de suivre la tendance actuelle à privilégier les micro-services dont la gestion est de plus en plus facilitée par des outils toujours plus riches et plus efficaces.
Je profite enfin de ce retour pour remercier l’équipe organisatrice des dotConferences pour leur invitation mais surtout pour leur accueil, leur disponibilité et leur simplicité. Merci à vous !
