La prévisibilité est la dimension cachée des performances réseau
Les gens qui travaillent sur le réseau au niveau le plus bas aiment parler de TPS, de latence et de bande passante. Ces indicateurs sont bien sûr importants, mais ils ne répondent qu’à une seule question : à quelle vitesse ça peut tourner ? — alors qu’ils répondent rarement à une autre, plus essentielle : quand ça tourne, est-ce que c’est stable ?
Le protocole Kadcast de Dusk m’a fait repenser à cela. Il ne suit pas l’itinéraire habituel de propagation de rumeurs aléatoires, mais s’appuie sur un réseau de couverture structuré qui fixe les chemins de transmission. Le résultat n’est pas juste plus rapide une seule fois, mais à peu près pareillement rapide à chaque fois. La latence passe d’une distribution probabiliste à une constante approximative.
Une fois que cette différence remonte au niveau supérieur, l’impact est énorme. Un réseau imprévisible revient à dire aux développeurs : je ne suis peut-être pas fiable, débrouillez-vous. Du coup, les dépassements de délai, les reprises, le backoff exponentiel, les caches de secours… toute une série de complexités qui devraient appartenir au niveau bas se retrouvent poussées vers la couche applicative. Et pire encore : ce sont souvent les parties les plus difficiles à tester et les plus propices aux bugs.
C’est pourquoi je préfère désormais définir la performance ainsi : un bon réseau ne consiste pas à faire écrire par les développeurs du code plus rapide, mais à leur faire écrire beaucoup moins de code qui ne devrait tout simplement pas exister.
C’est particulièrement fatal dans les scénarios financiers. Dans les systèmes de trading, l’élément le plus coûteux n’est pas la machine, c’est la charge cognitive : quand votre capacité mentale est accaparée par la question de savoir si le réseau va se mettre à trembler, vous ne pouvez plus vous concentrer sur le moteur de matching, les stratégies de gestion des risques, et toutes ces étapes qui créent réellement de la valeur. La plus grande valeur de la prévisibilité, c’est qu’elle permet aux développeurs de supprimer les hypothèses directement du code.
La meilleure infrastructure, c’est celle dont on ne pense presque plus qu’elle tourne une fois qu’on l’a déployée.
@Dusk #dusk $DUSK
Les gens qui travaillent sur le réseau au niveau le plus bas aiment parler de TPS, de latence et de bande passante. Ces indicateurs sont bien sûr importants, mais ils ne répondent qu’à une seule question : à quelle vitesse ça peut tourner ? — alors qu’ils répondent rarement à une autre, plus essentielle : quand ça tourne, est-ce que c’est stable ?
Le protocole Kadcast de Dusk m’a fait repenser à cela. Il ne suit pas l’itinéraire habituel de propagation de rumeurs aléatoires, mais s’appuie sur un réseau de couverture structuré qui fixe les chemins de transmission. Le résultat n’est pas juste plus rapide une seule fois, mais à peu près pareillement rapide à chaque fois. La latence passe d’une distribution probabiliste à une constante approximative.
Une fois que cette différence remonte au niveau supérieur, l’impact est énorme. Un réseau imprévisible revient à dire aux développeurs : je ne suis peut-être pas fiable, débrouillez-vous. Du coup, les dépassements de délai, les reprises, le backoff exponentiel, les caches de secours… toute une série de complexités qui devraient appartenir au niveau bas se retrouvent poussées vers la couche applicative. Et pire encore : ce sont souvent les parties les plus difficiles à tester et les plus propices aux bugs.
C’est pourquoi je préfère désormais définir la performance ainsi : un bon réseau ne consiste pas à faire écrire par les développeurs du code plus rapide, mais à leur faire écrire beaucoup moins de code qui ne devrait tout simplement pas exister.
C’est particulièrement fatal dans les scénarios financiers. Dans les systèmes de trading, l’élément le plus coûteux n’est pas la machine, c’est la charge cognitive : quand votre capacité mentale est accaparée par la question de savoir si le réseau va se mettre à trembler, vous ne pouvez plus vous concentrer sur le moteur de matching, les stratégies de gestion des risques, et toutes ces étapes qui créent réellement de la valeur. La plus grande valeur de la prévisibilité, c’est qu’elle permet aux développeurs de supprimer les hypothèses directement du code.
La meilleure infrastructure, c’est celle dont on ne pense presque plus qu’elle tourne une fois qu’on l’a déployée.
@Dusk #dusk $DUSK