dotScale avait lieu ce 8 juin 2015 à Paris. Sincèrement, l’une des meilleures conférences depuis quelques mois.
Comment résumer cette journée en quelques mots ? Pour moi c’est plusieurs dizaine de pages de notes, des rencontres et un bilan très positif. dotScale 3ème édition avait lieu dans un Théâtre Parisien. Mieux installé que lors de précédents « dot Conférences », l’équipe d’organisation a trouvé un lieu plus grand et plus accueillant, où toi public, tu n’as pas peur de passer la journée coincé entre un strapontin et un vieux fauteuil fatigué. Là, c’était mieux.
Sylvain Zimmer ouvre la journée devant 750 participants. Un bon tiers de la salle n’est pas de France. Cela parle Espagnol, Anglais et Italien pendant les pauses. Le format des dotConférence est librement inspiré des talks TED. Une seule track, un format de 20mn, et une interview du speaker sur scène par Sylvain à chaque fois. Cette idée d’interview est très bien car elle évite la séance de Q&A laborieuse, elle permet de préciser quelques points, et l’animateur pose ses questions directement au speaker pendant quelques minutes. J’ai trouvé l’idée sympa et très complémentaire de chaque présentation.
Alors vous n’y étiez pas… et c’est dommage. La conférence revient l’an prochain, et sera sans doute précédée le vendredi d’avant par une nouvelle conférence : dot Security. En effet, l’équipe d’organisation souhaite renouveler le format 1 + 1 mis en place avec dotCSS et dot JS. dotScale sera donc précédé de dotSecurity l’an prochain.
Voici quelques notes résumées sur cette journée :
1. Matt Bostock (@mattbostock) travaille en Grande-Bretagne pour le Government Digital Service. Dis comme cela, on pense à James Bond. C’est l’une des personnes en charge de la plate-forme gouvernementale britannique. Avec 12 millions de visiteurs uniques par semaine, leurs systèmes sont sous tension en permanence. Sa présentation portait sur le système mis en place pour assurer les mises à jour et les reboot automatique de leurs serveurs. Il est important de prévoir des outils de reboot automatique.
2. David Mytton (@davidmytton) est le fondateur de Server Density, un outil de surveillance d’infra-structure type Cloud. Sa présentation porte sur l’importance de l’humain lorsqu’il s’agit de répondre à des incidents de production. En s’inspirant du monde de l’aéronautique, il nous explique comment mettre en place des check-lists, comment assurer des rotations et s’assurer que l’équipe technique est capable de gérer vos logiciels. Pour cela, il faut se préparer aux problèmes en anticipant. La réponse doit aussi suivre un cadre précis, et enfin un post-mortem doit permettre d’améliorer les procédures. Pensez à mettre vos fiches d’incident en dehors de votre infra. Si vous utilisez AWS, il sera plus judicieux de stocker vos checklists sur Google Docs par exemple.
Sa présentation donne quelques pointeurs simples, faciles à mettre en place :
- tenez une liste des numéros de téléphone de l’équipe, qui fait quoi et qui sait faire quoi
- conservez les numéros de vos prestataires, numéro de contrat, licence de support dans un endroit sûr
- mettez en place une « war room » sur HipChat ou Slack lorsqu’un incident grave survient afin de tenir à jour vos équipes
- pensez à une page type support.mycompany.com où vous pourrez lister les soucis en cours, et éviter de surcharger vos lignes téléphoniques
- pensez à loger toutes les opérations que vous faîtes lorsque vous tentez de résoudre un problème
- prévoyez un point à heure fixe pour tenir à jour vos clients si l’incident dur
- soyez paranoïaque et envisagez le scénario « le disque est vraiment mort » pour prendre au plus tôt les mesures les plus radicales
J’ai apprécié cette présentation sur l’importance de l’humain dans la gestion de crises. La clé pour pouvoir monter en charge est de mettre en place ce type de procédure rapidement.
3. Paul Dix, sur InfluxDB
Paul est le CEO d’InfluxDB, une société basée à New-York, qui a levé 8.1 millions de dollar en décembre 2014. InfluxDB est une base NoSQL écrite en Go, autonome et facile à installer comme Redis, adaptée pour les problématiques de série temporelle. Il explique que son équipe est d’abord passée par l’écriture d’une solution avec Scala + Cassandra + Redis, pour aboutir finalement à une solution écrite uniquement avec Go.
Cette présentation est assez technique, Paul explique les différents algorithmes comme LSM (Log-structured merge tree) utilisé par Apache Cassandra, optimisé pour l’écriture de données. Il compare ensuite l’approche de MongoDB, dont les indexes sont basés sur B-Tree, plus précisément Counted B+ Tree. Chaque approche propose des avantages et des inconvénients qu’il faut comprendre avant d’adopter telle ou telle technologie. Pour cela il faut se pencher sur les papiers, et aller plus loin que la simple lecture de la documentation du site.
Paul Dix présente ensuite rapidement le CAP Theorem, qui structure et permet de poser les bases d’un bon nombre de bases NoSQL. Cohérence, Disponibilité et tolérance au Partionnement. Si le partionnement peut dépendre du réseau, vous êtes donc face au choix d’être éventuellement consistant (Availability + Partionnement) ou d’accepter de ne pas être disponible tout le temps (Cohérence + Partionnement). Chaque base couvre une partie mais ne peut pas prétendre couvrir les 3 domaines. Cela a été démontré en 2002 par 2 chercheurs du MIT.
InfluxDB propose une approche où tout est pensé autour des time-series. L’outil s’utilise via une API HTTP type REST comme Elastic Search. Sur Mac OS X l’installation est simple :
brew update && brew install influxdb --devel
Et vous vous retrouverez avec la version 0.9 devel. Pourquoi prendre cette version ? Car l’équipe a retravaillé et changé la partie écriture entre la 0.8 et la 0.9 qui devrait sortir en juin 2015. De l’aveu de Paul, concentrez-vous sur cette version 0.9. En tous les cas, on a bien envie de tester cela du côté de Captain Dash.
4. John Wilkes
John est une rock-star de Google, auteur de Borg et d’Omega. Cette présentation nous emmène dans le futur, où il n’y a plus d’ordinateurs. Google a modélisé ses solutions afin de décrire un ensemble de tâches, certaines pour de la production et d’autres pour du traitement de fond sur les données. Lorsque vous cliquez sur le bouton « Search » de GMail pour retrouver un email, sachez que votre tâche va tourner sur un cluster, et que tout ceci doit être orchestré.
John insiste d’abord sur l’importance de penser votre infra-structure en se disant « jusqu’ici tout va bien ». Prévoir les erreurs, et anticiper toutes les sortes de pannes, permet d’avoir un ensemble cohérent et stable. Au delà de l’aspect monté en charge, ce qui semble banal chez Google, j’ai apprécié ce talk où il parle de l’optimisation de l’utilisation des ressources. Comme il existe forcément un delta entre la puissance CPU+Mémoire disponible à un instant T, et les besoins de votre application, comment optimiser et s’assurer que les machines fonctionnent tout le temps à 100% de leurs capacités ? C’est donc tout un ensemble de scheduler, de gestionnaire de tâches et de répartition du travail qu’il fallait penser.
Pour terminer on imagine ce gestionnaire de tâche, comme sur Windows. Sauf que là, votre machine a plusieurs millions de CPU
5. Les Lightning Talks
La pause déjeuner passé, nous reprenons avec une série de présentations rapides de 7 à 9 mn. De nouveaux speakers viennent sur scène et présentent un sujet autour du thème de la Scalabilité.
Un plugin Docker pour Eclipse, De l’importance de lire les papiers théoriques, le système d’élection du Leader sur Cassandra, Qu’est-ce que les Convergent Replicated Data Types…
C’est assez dense et cela permet de balayer quelques sujets rapidement
6. Neha Narula
Neha est une ex-Googler, qui vient d’obtenir son PhD au MIT au département PDOS. Elle a effectué une présentation assez académique mais particulièrement précise. Pour cela, elle traite de 3 sujets autour de la consistence, qu’elle présentera en détail :
- ACID (Atomic, Consistent, Isolated, Durable)
- les Modèles de Cohérence (avec/sans synchronisation)
- Le théoreme CAP (ou théorème de Brewer)
Cela permet de (re)voir un ensemble important de notions et de principes, qu’il est indispensable de maîtriser dès lors que l’on s’intéresse au monde des bases de données.
7. Ben Firshman
Ben est chez Docker. C’est l’auteur de Fig, remplacé maintenant par Docker Compose. Dans le courant de ce que John Wilkes a présenté, il nous propose d’imaginer un univers sans machine. Disons plus précisément : sans que toi, développeur, tu utilises une machine. Pour cela ton code sera exécuté dans une enveloppe standard, les conteneurs popularisés par Docker. Alors c’est la fin des serveurs. Dans ce monde merveilleux, votre application fonctionne sur un méga-super-gros ordinateur : Internet Sized Computer.
Mais ça, ça pue. Et c’est compliqué. Imaginez que si ce gros ordinateur venait à exister, une partie de votre code pourrait ne pas s’exécuter et disparaître quelques instants. Ou qu’une personne mal intentionné pourrait utiliser votre code et introduire des traitements visant à corrompre vos données.
Si Docker propose l’isolation et la standardisation des processus, il reste maintenant un univers à compléter et à inventer. Dans sa présentation, on voit la vision où les outils de composition, de synchronisation et de mise à jour seront importants. Cela permettra demain de déployer réellement une application, et de ne plus se connecter sur une machine. C’est déjà faisable et proposé par plusieurs acteurs du Cloud. Reste plus comme il l’explique, à créer des standards afin de ne pas se locker avec un vendeur particulier comme Amazon ou autre.
Ce que je retiens : nous ne sommes qu’au début de l’approche « Container as a Service » et qu’il reste des océans d’opportunités pour les startups dans ce monde du « RUN ».
8. Simon Riggs, PostgreSQL
Arrive sur scène Mr Simon Riggs himself, qui est l’un des contributeurs de PostgreSQL depuis 11 ans. S’il y a un projet où le principe de revue de code est drastique, c’est bien PostgreSQL. Connu pour la qualité de son source code, sa présentation met bien en avant cet univers, beaucoup moins artisanal que sur d’autres projets.
Il présente un état de l’art de PostgreSQL où nous découvrons un sacré ensemble de fonctionnalités supportées par PostgreSQL. Support de JSONB dans la version 9.4, support du sampling sur la 9.5. PostgreSQL est une base sérieuse qui peut faire du schema-less, et du clé-valeur.
Seulement voilà. Par rapport à d’autres concurrents, il n’y a pas un marketing de ouf. C’est dommage car ce produit est excellent, souvent reconnu comme étant bien meilleur que MySQL, pourtant plus populaire.
Bref on peut faire de très très bonnes choses avec PostgreSQL, ne prenez pas forcément une base NoSQL dès le premier jour.
9. Kyle Kingsbury, alias @aphyr
Là, on a du lourd, et du show.
@aphyr est l’auteur d’une série d’articles assez poussés sur le comportement des bases NoSQL dans des conditions de partionnement et de problèmes réseaux. Et chacun en prend pour son grade sur son blog. Avec beaucoup de détails tout en restant accessible, ses séries d’articles ont eu le mérite d’améliorer des produits (comme Elastic Search et MongoDB).
La présentation revient sur MongoDB, Elastic Search et surtout AeroSpike qui va prendre cher pendant 5 bonnes minutes. Je vous laisse découvrir les détails, parfois croustillant, mais très bien documentés, de chaque base NoSQL. Ce qu’il faut retenir : ne lisez pas simplement la documentation et les promesses des vendeurs. Vérifiez l’évident et testez !
10. John Graham-Cummings de Cloud Flare
Là, on a du lourd et des chiffres. Cloud Flare est un CDN ainsi qu’un DNS, que j’utilise pour le Touilleur Express depuis plusieurs années. Sa présentation est une visite détaillée de l’architecture d’audit de Cloud Flare. Lorsque votre navigateur visite ce blog, sachez qu’une requête passe par le serveur de Cloud Flare. Oui lecteur, on sait tout sur toi. Que tu sois entrain de lire cet article au bureau, sur les toilettes ou dans un avion. On sait tout !
Et le plus marrant, c’est que Cloud Flare reçoit 4 millions de requêtes de log par seconde. Cela fait 400 Tb de données par jour, 146 Ptb par année. Donc beaucoup. Juste pour de l’audit des requêtes.
Pourquoi Cloud Flare fait-il cela ? Tout simplement pour offrir des tableaux de bords aux clients (comme moi). Ceci me permet de voir la quantité de bande passante sauvée par Cloud Flare. Et cet outil me permet aussi de voir les attaques dont mon site est souvent la cible. J’ai les IPs, et Cloud Flare peut les bloquer automatiquement. Bref un outil assez important lorsque vous avez un site avec pas mal de traffic (ce blog reçoit plus de 16000 VU par mois).
L’architecture derrière est passionnante. On attaque par NGinx + LuaJIT. Les données sont envoyées par Cap’n Proto vers des serveurs Kafka, qui permettent de garder une heure de données, avant de débuter l’échantillonage. Puis ensuite des workers stockent la donnée par sampling sur des bases PostgreSQL + CitusDB pour la partie clustering et les performances lorsque vous effectuez des requêtes.
Une présentation très poussée avec de « vraies histoires » sur les chiffres, sur les choix techniques et sur tout ce qu’il faut faire pour offrir un service de qualité.
11. Salvatore Sanfilippo (aka @antirez)
Salvatore est le créateur de Redis un serveur de données structurées que j’utilise sur le CFP de Devoxx France, utilisé sur le site Zaptravel pour les données ou encore le site pour adultes YouPorn.
Sa présentation porte sur Disque, un nouveau projet expérimental de gestions de jobs en mémoire. Basé sur les idées populaires de Redis, Disque est un système simple qui ne cherche à résoudre que quelques problèmes. Et ça, moi j’aime bien. Redis m’a séduit car il est simple, facile à apprendre et à mettre en oeuvre, et il ne fait rien d’extra-ordinaire.
Durant cette présentation, il explique que Disque est une queue de job répliquée. Le client n’obtiendra un ACK d’écriture que si le job est écrit sur N nodes d’un cluster. C’est un système multi-master où les nodes vont s’échanger le travail à effectuer, sans qu’il n’y ait un master précis. Comme Redis, Disque peut avoir un comportement full in-memory, ou avoir en plus un journal type AOF pour sérialiser les opérations sur disque. Tout ceci se règle et les connaisseurs de Redis ne seront pas perdus.
J’ai été très heureux de pouvoir rencontrer enfin @antirez, et de pouvoir le remercier pour son travail, sa gentillesse et sa simplicité.
12. Jeremy Edberg, Reddit et ex-Netflix
Jeremy termine cette superbe journée par un retour d’expérience entre son passage chez Netflix, et son travail chez Reddit. Il donne quelques pointeurs autour du principe des micro-services, en donnant une définition assez précise.
Il recommande tout d’abord à chaque projet de démarrer sur le Cloud. Comment envisager un projet différent aujourd’hui ? Qui est assez malin pour prédire le succès ou l’échec de votre produit ? Rendez-vous compte que la société WhatsApp a été racheté 19 milliards de dollar par Facebook, avec une base active de 420 millions d’utilisateurs. Le tout avec moins de 50 développeurs… La société avait 55 personnes à l’époque. Chacun aurait reçu 350 millions de dollar. Voilà. Vive le Cloud mon ami.
Dans sa présentation et en lisant ensuite ses articles de blog, j’ai noté quelques idées sympas
- tout est pensé pour que trois développeurs puissent gérer un service maximum. Sinon ce n’est pas des micro-services
- mise en place d’un système de build, de test et de déploiement automatisé. No fear of deployment.
- les développeurs peuvent mettre en prod lorsqu’il le souhaite, mais doivent assurer le S.A.V
- Netflix a créé un système qui créé du Chaos, afin de s’assurer que le système fonctionne. C’est les fameux « Simian Army » popularisé par les Chaos Monkey.
- pensez à des architecture sans état. On est en 2015. Les sessions et les problèmes de mémoire du côté serveur c’est so-2000
- mettez en place des procédures pour gérer les incidents (cela couvre ce qu’a expliqué David Mytton).
- débutez par une architecture classique et monolithique, avant d’envisager les micro-services. La complexité est un problème de riche. Tant que votre produit n’a pas prouvé son intérêt, restez simple.
- Parfois il faut construire soit même, mais le plus souvent vous devrez intégrer (Build or Buy). Il conseille fortement de s’appuyer sur des solutions du marché (open-source) et de faire confiance aux autres.
- ne pas hésiter à tester et à jeter. Plutôt que de longs échanges sur « je pense que »… il faut avoir l’attitude « je sais que… »
Conclusion
Cette journée était utile.
Lorsque vous prenez du temps pour participer à une conférence, vous avez des attentes. Le format de dotScala pourrait être difficile car il n’y a qu’une seule track. Pas d’échappatoire possible. Et bien j’ai trouvé que l’ensemble des présentations était bien. Les speakers sont bien préparés, et il y a une cohérence pendant toute cette journée. J’ai vraiment préféré cette conférence, à expérience précédente de dotJS.
Je repars avec des idées, des outils et de nouvelles pratiques à tester.
C’était bien.
Si tu as aimé la session de John Wilkes tu devrais vraiment regarder Kubernetes.
Au moins tu @aphyr
tu vois pourquoi je souhaitais qu’ @aphyr vienne à Paris 😉
oui c’évident 🙂