eBPF pour l'observabilité et la sécurité c'est la révolution ou juste une hype de plus qui va nous exploser à la figure

Franchement eBPF c'est pas une hype c'est la fondation du futur. Le niveau de visibilité que tu obtiens sans impacter les perfs applicatives c'est juste impossible avec les approches user-space classiques.

Tu peux tracer absolument tout les appels système les connexions réseau les accès fichiers le scheduler CPU même les I/O avec io_uring pour avoir une vision complète du système sans instrumenter ton code. C'est un game changer pour le SRE et l'optimisation des performances.

Faut arrêter avec le fantasme de la magie eBPF. Oui sur le papier c'est beau mais la complexité est juste ahurissante. Écrire des programmes eBPF c'est coder au niveau du kernel sans les outils de debug qu'on a d'habitude.

Le verifier eBPF va bloquer ton programme si tu fais la moindre erreur d'accès mémoire et c'est très bien. Mais ça rend le développement et surtout le debug un enfer pour des équipes qui ont déjà du mal à gérer leur infra Kubernetes existante. C'est un truc pour experts du kernel pas pour le devops moyen.

Je suis entre les deux. La puissance est là c'est indéniable. Pour des cas d'usage très spécifiques où la latence et le throughput sont critiques par exemple pour des proxies réseau haute performance ou de la sécurité au niveau syscall ça déchire.

Mais pour l'observabilité générale de tes microservices est-ce que ça vaut le coup de s'infliger cette courbe d'apprentissage monstrueuse quand tu as déjà Prometheus et Loki qui font le job avec des exporters standards C'est une question de ROI.

Prometheus et Loki c'est bien mais ils voient pas tout ce qui se passe dans le kernel sans des tonnes de custom metrics et d'instrumentation. Avec eBPF tu branches et tu as la visibilité directe sur les latences CPU les erreurs I/O les problèmes de scheduler les pages fault.

Et le risque kernel c'est surévalué. Le verifier est là pour garantir que ton programme est sûr. Le risque c'est surtout d'écrire un programme qui ne fait pas ce que tu veux ou qui est inefficace pas de crasher ton serveur. Et l'écosystème avec Cilium Tetragon ou Falco simplifie énormément l'adoption.

Cilium c'est super pour le réseau Kubernetes mais ça te rajoute encore une couche de complexité réseau déjà énorme et tu deviens dépendant d'une techno kernel très spécifique. Et si tu veux faire des trucs un peu custom qui ne sont pas couverts par les outils prêts à l'emploi tu te retrouves à coder en C ou en Rust pour le kernel.

C'est pas un truc que tu déploies sur des centaines de serveurs sans avoir des experts en interne. Imagine un bug dans ton programme eBPF déployé à l'échelle Comment tu débugs un truc qui tourne dans le kernel sur 500 nodes

Exactement. La détection et le diagnostic de problèmes dans un environnement eBPF distribué c'est le cauchemar. Tes outils d'observabilité actuels ne sont pas faits pour ça. Il te faut des solutions de monitoring spécifiques qui peuvent interpréter et agréger les données eBPF.

Et la compatibilité kernel c'est un vrai sujet. eBPF évolue très vite et un programme qui marche sur un kernel 5.4 peut très bien planter sur un 5.15 ou avoir un comportement différent. C'est un facteur d'instabilité si tu gères plusieurs distributions ou versions de Linux.

La compatibilité c'est moins un problème aujourd'hui avec CO-RE Compile Once Run Everywhere et libbpf. Les outils modernes s'occupent de générer du code eBPF portable. Et pour le debug les projets comme bpftool ou bcc proposent des méthodes pour inspecter les maps et les traces.

La sécurité c'est un énorme avantage. Tu peux faire de la sandboxing des process des politiques réseau au niveau du kernel bien plus fines que du simple iptables. Tu peux bloquer des appels système suspects ou des connexions réseau basées sur le contexte applicatif sans surcharge.

Sandboxing et sécurité c'est top. Mais qui écrit les règles de sécurité eBPF Qu'est-ce qui garantit que le programme eBPF lui-même n'est pas une vulnérabilité ou qu'il n'introduit pas un comportement imprévu ou malicieux

C'est une nouvelle surface d'attaque directe sur le kernel. Le code est auditable oui mais qui a les compétences pour auditer du code eBPF à l'échelle C'est une question de supply chain security. Je préfère un bon vieux SELinux ou AppArmor qui sont certes plus complexes à configurer mais au moins ils sont éprouvés.

Pour la sécurité c'est un compromis. eBPF te donne une granularité folle. Mais tu as aussi la responsabilité de ce code kernel-space. Comparer ça à un module Apache ou Nginx avec une CVE c'est une chose comparer ça à un bug dans le kernel c'en est une autre.

Et soyons honnêtes pour beaucoup de PME ou même de grandes boîtes qui n'ont pas des besoins de performance ou de sécurité extrêmes est-ce que l'investissement en temps et en compétences pour maîtriser eBPF est justifié Je ne suis pas sûr.

L'investissement est justifié par les gains futurs. Pensez au FinOps. Si vous pouvez optimiser les ressources CPU et I/O de manière ultra fine grâce à eBPF vous faites des économies massives sur le cloud.

Et pour le SRE tu peux détecter les causes racines de problèmes de performance qui sont invisibles au niveau user-space. Une latence réseau un problème de cache CPU une congestion I/O c'est le genre de trucs que tu peux pister directement.

Pister oui mais résoudre. Les logs et les traces eBPF sont des centaines de lignes de dump kernel qui demandent une expertise profonde pour être interprétées.

Je vois déjà les équipes se noyer sous la data eBPF sans savoir quoi en faire. C'est comme donner une Formule 1 à un conducteur de tracteur ça va juste finir dans le mur.

C'est un peu ça. La courbe de compétence est verticale. Si tu n'as pas un ou deux gourous Linux Kernel dans ton équipe je dirais que c'est une mauvaise idée de se lancer à fond.

On peut commencer petit. Utiliser des outils comme bpftrace pour des scripts d'analyse ad-hoc ou des projets comme Falco pour la détection d'intrusion c'est déjà un bon pas sans réécrire sa stack d'observabilité de A à Z.

Exactement on commence par des outils plus abstraits. Les frameworks existent pour ne pas avoir à écrire en C. bpftrace par exemple c'est du Dtrace-like. C'est déjà plus accessible.

Et les intégrations avec Prometheus et Grafana sont là. Tu exportes les métriques eBPF via des exporters standard. Ce n'est pas un monde à part non plus.

Exporter les métriques c'est une chose comprendre d'où elles viennent et ce qu'elles veulent dire quand ton eBPF probe te sort un dump de syscalls c'en est une autre. Faut pas se voiler la face c'est une techno de niche pour des problèmes de niche.

Niche oui mais qui devient de moins en moins niche. Pour les infrastructures cloud natives complexes c'est presque un pré-requis pour avoir un monitoring et une sécurité vraiment efficaces. Quand tes pods se battent pour des ressources et que le kernel est le bottleneck c'est là que eBPF brille.

Pour des apps plus legacy ou des infra plus classiques les outils existants sont largement suffisants et moins coûteux en temps homme.

OK je vois bien les deux camps et les arguments sont solides. La complexité et le risque d'expertise sont les gros points noirs mais les bénéfices en performance et en visibilité sont tentants.

Je pense qu'on va y aller progressivement. Peut-être commencer avec un PoC sur de l'analyse réseau ou des audits de sécurité spécifiques pour voir ce que ça donne avant de tout basculer. Merci pour ce débat ça m'a éclairé !