Un retour d'expérience sur l'utilisation de GPT4 pour un usage modéré (500M tokens sur 6 mois).
Les retours d'expérience que je partage:
- Langchain et LlamaIndex ça apporte une couche d'abstraction supplémentaire difficile à maitriser alors que le SDK simple suffit
- le streaming pour faire attendre les utilisateurs est indispensable
- GPT4 a du mal à ne pas halluciner plutôt que de se taire lorsqu'il n'a pas d'info suffisantes
- la fenêtre de contexte de 128K c'est que en input, pour l'output ça n'a pas bougé et c'est toujours 4K tokens seulement
- les bases de données vectorielle sont inutiles dans la majorité des cas
Retour d'expérience sur le développement de Github Copilot et donc d'une véritable application LLM en prod depuis plusieurs années et avec un trafic conséquent
Retour d'expérience sur une sortie de cloud par Hey/Basecamp.
Sans changer la taille de l'équipe Infra, ils ont mis 6 mois à tous migrer et ils vont maintenant économiser 1.5 millions de dollars par an
Un retour d'expérience sur comment organiser son process de recrutement.
Les conseils en plus de Fabien Ducher:
En amont
- l'organisation de la tech est suffisamment claire
- on est à l'aise sur la salary grid (qu'elle soit affichée publiquement ou non)
- on est sur d'avoir les ressources pour accompagner l'onboarding et rampup
- Les personnes qui font passer des entretiens sont formées à le faire (posture, ce qui est ok ou pas ok de dire, comment on le mène, les entretiens eux même, etc.)
- Checklist d'onboarding avec toutes les composantes (RH, IT, manager, newcomer) déjà existante.
L'offre
- inclusive! exemple: pas un empilement de compétences (soft et hard), mais un message clair sur le fait que c'est un repère et qu'il ne faut pas cocher toutes les cases pour candidater
- La description du process : les entretiens, avec qui, la durée et à quoi ils servent
Le process de validation
- s'il y a des tests / questions techniques, ce sont les mêmes pour tout le monde et on assess les résultats
- On liste à l'avance les red flag qu'on ne veut pas voir
- Max 2 semaines entre la prise de contact et la décision
- J'aimerai beaucoup tester aussi l'idée que la personne qui candidate vient avec un cas technique qu'elle discute avec des personnes de l'art. (ca brise le test commun à tous, mais c'est au moins un contexte que le candidat maitrise et qui sera moins stressant)
- Feedback clair et factuel après chaque entretien, surtout en cas de nogo à une étape
- Lors du dernier entretien, on est en situation d'échange libre où on répond à toutes les questions de la personne qui candidate, on ré-explique l'onboarding, le carreer path, la période d'essai, les attentes, etc.
- un comité d'évaluation à la fin avec toutes les personnes ayant réalisé un entretien
La proposition
- Salaire en comparant avec la grille, les stats de salaire à poste équivalent en interne (incluant l'équité homme / femme) et des bench extérieur (à noter ici que Figures est canon comme outil)
l'onboarding
- Welcome 1-1 où on présente la checklist d'onboarding, on cale les 1-1 hebdo,
- On présente les obj de PE la première semaine
- On s'assure que l'équipe l'accueil bien dans le day to day
Période d'essai
- on fait des 360 pour avoir le max d'avis et pas uniquement l'avis du manager
- On refait a minima un point à mi PE, voir tous les mois avec le newcomer
- Ou on coupe ou on valide, le renouvellement ne sert que pour des doutes mineurs qui n'auraient pas pu être levé dans le délai. Avoir une boule noire nuira à terme plus à votre organisation que n'avoir personne.
Une histoire d'optimisation d'un cluster Elasticsearch.
Le problème chez Netflix venait d'une mauvaise allocation des shards des indices, tous les indices avaient le même nombre de shards et donc certains noeuds se retrouvent à héberger des shards contenant des millions de documents.
Leur stratégie a été de distribuer les documents non pas par type mais par date de création (time buckets) en utilisant des index template pour la création automatique et des alias pour la recherche (comme pour l'ingestion des logs donc).
Un retour d'expérience de Cloudflare sur la ré-écriture d'un module Nginx en Rust.
Un retour d'expérience sur l'utilisation de Cassandra à un très haut niveau chez Discord.
Des problèmes de maintenance majoritairement liés à la manière dont ils utilisaient Cassandra car des ralentissements en lecture sur un noeud impactaient tout le cluster car la lecture/écriture se fait en quorum.
La "compaction" (réindexation) des tables par Cassandra et le GC de la JVM causaient aussi des problèmes de latence.
Ils ont décidé de migrer toutes leurs DB vers ScyllaDB qui est compatible Cassandra mais en C++ donc plus rapide et pas de GC!
Il n'ont pas réglé leur problème qu'avec une nouvelle base de données mais aussi avec des middleware de cache écrit en Rust pour la performance C++ et la sureté mémoire.
La migration fut aussi très compliqué et les premières prévisions étaient extrèmement longues (3 mois) mais la encore un rewrite du connecteur en Rust sauve la mise (9 jours!)
Conclusions:
- plus de stabilité
- 177 noeuds Cassandra à 72 ScyllaDB
- latence p99 40-125ms avec Cassandra et 15ms avec ScyllaDB
Un retour d'expérience sur un passage de iOS natif à Flutter.
Les points forts:
- le langage Dart
- la rapidité d'exécution des tests
- grande diversité de widget embarqués
- hot reload <3
- performances
- courbe d'apprentissage douce
Les points faibles:
- moins de ressources et librairies car ecosystème "jeune"
- 🕸️
Flutter est le langage de l'avenir pour le frontend et (j'espère) un jour aussi du backend.
Le prochain langage fullstack pour remplacer Javascript?
Un retour d'expérience sur un passage au JT de TF1 et les préparations de scaling associées.
Ce qu'ils ont fait:
- landing page dédiée, complètement statique pour la conversion vers installation de l'application
- scaling vertical des DB (plus simple je suppose)
- scaling horizontal applicatif 7
- préparation d'une page d'erreur avec Google Form au cas ou
Leur infra a fait x10 lors de la diffusion du reportage avec 250K requêtes /minutes!
L'histoire de l'adoption de Kafka chez Cloudflare en tant que message bus inter-services.
Ils l'ont déployé pour optimiser le développement de leur architecture micro-service (découplage) mais aussi:
- réduire les silos de données
- rendre les communications inter-services plus claires
- avoir un format de communication auto-documenté
Pour cela, ils ont notamment développé un client Kafka interne qui abstrait la plupart de la configuration et de la logique compliqué.
Le schéma de communication n'est pas JSON ou Avro (ouf!) mais l'excellent Protobuf qui en plus d'avoir une taille réduite, assure le typage fort de chaque champ afin d'identifier les breakings changes.
Niveau observabilité, le plus important pour eux est le "lag", qui est le temps entre le dernier message produit et le dernier message lu.
Cette seule métrique permet d'identifier de nombreux problèmes:
- le consumer est down
- le consumer n'arrive pas à ingérer tous les messages
- un nombre inhabituel de messages est produit
- le consumer n'acquitte plus les messages
Bref, un super retour d'expérience et pleins de bons conseils pour construire son infrastructure applicative avec Kafka.
Un REX sur les limites de MongoDB.
Concrètement dans le cas de Malt, MongoDB leur a permis d'itérer rapidement au début mais par la suite son utilisation a ralenti les développements et le fonctionnement de l'application.
A noter que l'article porte beaucoup sur les anciennes versions de MongoDB, sans les transactions ou le mot clé $lookup
.
Dans les problèmes rencontrés:
- le langage de requête en JSON qui n'est pas aussi clair que du SQL
- la modélisation nosql qui implique beaucoup de dénormalisation et de duplication
- la cohérence des données et les jointures qui doivent se faire dans le code
Bref, comme d'habitude il faut utiliser la bonne base de donnée pour le bon problème et lorsqu'il s'agit de la modélisation d'un système relationnel (90% des applications) alors une base de données relationnel est de mise.
Un REX sur la gestion des pics d'affluence à L'Équipe pendant les coupes du monde.
Plusieurs conseils:
- code freeze: aucun déploiement avant la coupe de monde
- auto-scaling: entre 10 et 120 pods sur leur cluster Kubernetes
- observabilité: Application Performance Management (APM) et une suite Elasticsearch, Logstash, Kibana (ELK)
A certains moments, ils ont encaissé plus de 1 million de pages vues à la minutes!
Un retour d'expérience sur l'utilisation de Rust plutôt qu'un autre langage dans une startup qui développe un produit de type SaaS.
Sans surprise, c'est moins efficace de développer un SaaS en Rust qu'en Node.js ou en Python.
L'auteur met en avant les points qui freinent le développement de sa startup:
- la courbe d'apprentissage très longue de Rust
- le modèle de mémoire (borrowing) qui ralentit le développement et empêche de faire des "brouillons"
- la difficulté de trouver des développeurs
- la documentation et les lib qui manque de maturité
La moralité: don't jump over the hype train et surtout il faut utiliser les techno pour les usages ou elles ont du sens.
Un super retour d'expérience sur l'utilisation de Flutter Web pour créer une PWA !
Les équipes ont décidé de faire une PWA pour éviter le problème de gestion d'anciennes versions d'une app mobile dans leur parc.
A part quelques difficultés autour de l'utilisation de l'appareil photo, ils n'ont pas rencontré de problème.
C'est vraiment encourageant pour Flutter Web car la techno est en production depuis seulement 1 an et semble déjà à la hauteur des promesses.
Ce genre de choix permet de tester rapidement un concept avec une PWA et de publier plus tard des applications natives sur les stores.
Un REX du gouvernement Britannique qui a enlevé JQuery de ses pages (32Kb compressé).
Ils ont observé une amélioration de 17% des performances en moyenne!
Par contre, ils n'ont pas utilisé d'autre lib JS à la place non plus :-)
Un très bon retour d'expérience sur RabbitMQ pour un système de queuing robuste, scalable et surtout maintenable.
- Réalisez une expertise de votre solution pour en comprendre les limites (2000~3000€ bien investis)
- Configurez le cluster pour qu'il mette en pause les nœuds de la partition minoritaire en cas de désynchronisation réseau
RabbitMQ reste une très bonne alternative à la grosse usine à gaz Kafka qu'on sort à toutes les sauces.