Compte-rendu dotScale 2017

Conférences du matin

Neha Narkhede, co-fondatrice et CTO de Confluent, a ouvert le bal avec un talk inspirant sur le passage à l’ère numérique, et ses implications, dans la façon de concevoir les SI modernes. Elle nous recommande de devenir “Event-centric”, ainsi les différentes applications partagent une seule fois leur changement d’état ou d'événement dans un outil centralisé (Kafka). Vous pouvez retrouver sa présentation ici.

Ensuite Adrian Cole, lead dev de Zipkin nous a fait un exposé sur les différences et les complémentarités entre les activités de logging, de collectes de métriques et de tracking. Les 3 sont étroitement liées mais couvrent différents aspects, et seule la bonne tenue des 3 permet de faire un troubleshooting efficace en cas d’incident. Le log fourni des traces brutes d’événements, la collecte de métriques s’applique à compter et agréger ces événements dans le temps et le tracking inter-services permet de détecter les goulots d’étranglements qu’une requête a pu subir (lenteur de redis / réseaux / etc). Vous pouvez retrouver sa présentation ici.

Clay Smith, “developer advocate” chez NewRelic nous a présenté le concept de serverless à travers l’implémentation FaaS (Function as a service) d’Amazon AWS Lambda λ. Il nous emmène à la découverte du design de ce type de service et les performances sous jacentes, en explorant les différentes métriques types des “FaaS” . En faisant un petit focus sur le démarrage à froid vs le démarrage à chaud. Il apporte un éclairage sur l’importance du démarrage à chaud des FaaS et l’impact sur la métrique de type “durée d'exécution”.
Son analyse fine du /proc linux (/proc/meminfo, /proc/cpuinfo, /proc/modules) permet d’observer le type de hardware et mettre en lumière l’implémentation du service FaaS AWS Lambda d’Amazon, telle que l’allocation de ressources, du fait de la colocation des Lambda λ sur une même virtual machine.
Il finit son talk en précisant le cas cible de ce type de service qui convient relativement bien dans le cadre de batch intensif et de traitement scheduler non critique du point de vue de la latence. La popularité grandissante des “FaaS” comme Aws λ Lambda est pour lui indéniable. Le ServerLess a de beaux jours devant lui.

Ulf Adams, lead of Bazel, nous a présenté le système de build créé par Google pour répondre à leurs problématiques d’augmentation exponentielle des temps de build.
À la recherche du build le plus court, Ulf nous expose les difficultés rencontrées au sein de Google ainsi que les méthodes utilisées pour y répondre. Le changement du système de build, l’ajout de code spécifique, mais surtout l’implication des développeurs est la clé de la réussite. Un focus est fait sur une bonne pratique, le développement de code dans des librairies les plus petites et indépendantes possibles.

Pour clore la session du matin, Mitchell Hashimoto, fondateur de Hashicorp est venu nous parler de sécurité à l’échelle. Il nous a exposé les avantages de Vault, le “coffre-fort” de la suite Hashicorp. Pour ce faire, il a réalisé 3 descriptions dédiées suivant les métiers de Dev, Ops et Sec, chacun ayant ses propres contraintes et problématiques. La philosophie de l’outil est de donner aux équipes le pouvoir de construire des architectures sécurisées avec un minimum de contraintes.

Lightning Talks

Les lightning talks sont ouverts à tous. Leur but est de présenter les sujets dans un format très courts (3-5 minutes) :

• Pierre Chapuis, core engineer chez Lima, nous a parlé de l’implémentation de l’Interval Tree Clock
• Un speaker d’Algolia nous montre qu’il est intéressant, sinon nécessaire, de rendre notre application agnostique du cloud provider pour pouvoir la déployer rapidement sur plusieurs cloud providers. Cela présente deux avantages majeurs : ne pas être dépendant de la résilience / disponibilité d’un seul hébergeur, et pouvoir choisir la meilleur solution par rapport au Coût / Performance.
• Omar Qunsul a présenté son projet d’ajout de graphs dans Redis.

Conférences de l’après-midi

Marco Slot de Citus Data, nous démontre qu’il est possible de scaler le SQL en utilisant le sharding de PostgreSQL.
Une requête SQL peut généralement être décomposée en sous-requêtes effectuant le plus gros du travail et qui seront distribuées sur les shards du cluster, ainsi la requête principale sera la plus légère possible et aura le seul rôle d’agréger les résultats.
citusdata.com propose de le gérer pour nous en s’intégrant dans le système d’extensions de PostgreSQL.
Vous pouvez retrouver sa présentation ici.

David Mazieres nous a expliqué le protocole ILC (https://www.ietf.org/mailman/listinfo/ilc). Internet Level Consensus est utilisé par Stellar (https://www.stellar.org/) pour authentifier et gérer les paiements.
Il y a une similarité forte avec la blockchain, et le protocole utilise les mêmes mécanismes que Bitcoin.

Aish Raj Dahal de chez PagerDuty, a partagé un retour d'expérience sur le management du chaos lors d’un incident majeur, et nous livre les enseignements qui en ont été tirés. Le rôle de commandant d’incidents est très important pour coordonner la gestion du problème, répondre aux parties prenantes, aux clients, et tracer les évènements. La communication est essentielle car il explique que dans ces situations l’effervescence fait que tout le monde agit dans l’urgence et que les acteurs se gênent les uns les autres.

James Cammarata, lead maintainer d’Ansible, nous parle d’automatisation ainsi que de la philosophie devOps.
Son slogan “Keep calm and automate all the things” nous rappelle qu’il faut chercher à automatiser l’ensemble des actions que nous pouvons réaliser.
Il est aussi revenu rapidement sur les bonnes pratiques dans l’utilisation d’Ansible :

• Utiliser les modules built-in d’ansible
• Toujours préfixer les variables pour éviter les conflits entre différents rôles.
  Une information importante est aussi apparue, Ansible Tower serait sur le point d’être ouvert en open source !

Benjamin Hindman co-créateur d’Apache Mesos, et fondateur de Mesosphere, nous a présenté sa vision des systèmes distribués, et le besoin d’avoir une interaction entre les applications et l’infrastructure.
Le parallèle à été fait entre les systèmes d’exploitation classiques et les programmes, ces derniers communiquent à l’OS leurs besoins, et qui leur répond en ajustant la mémoire vive, le temps CPU, les IO stockage, réseaux, et les autres ressources disponibles.
Cela devrait être possible pour les systèmes distribués et c’est l’objectif d’Apache Mesos et Mesosphere de le permettre. La solution Mesosphere se présente comme étant un OS pour Datacenter, et permet aux applications de faire des callback au cluster pour s’adapter à leurs besoins.

Conclusion

Ce compte rendu illustre quelques conférences que nous avons suivies lors de l’édition 2017 de dotScale.

Le public n’était pas invité à poser des questions a la fin de chaque talk, mais celles-ci étaient posées par l’organisation. Ainsi, la journée a été extrêmement bien cadencée et rien ne pouvait la déranger.

Vivement la conférence dotScale 2018 !