L'Anycast BGP sur du Cloud public c'est une hérésie ou le futur de l'infra distribuée

Anycast BGP sur du Cloud c'est clairement le futur pour les services de bord. Tu as raison pour la latence et la résilience c'est imbattable. Le trafic est toujours routé vers l'endpoint le plus proche et si une région tombe BGP retire l'annonce et le trafic va ailleurs. C'est du DDoS mitigation par conception.

On l'utilise pour nos DNS primaires et nos endpoints API stateless et ça tourne nickel. Faut juste bien comprendre comment les providers gèrent le BGP et souvent passer par des solutions de type Transit Gateway ou Direct Connect pour avoir le contrôle.

Futur mon oeil c'est un cauchemar FinOps et Opérationnel. Gérer du BGP avec des ASNs publics ou privés sur du cloud c'est déjà une usine à gaz. Et tu parles de latence et résilience mais le debug quand ton Anycast envoie le trafic n'importe où c'est un enfer.

Pourquoi le client à Londres va-t-il sur ton PoP en Californie alors que tu en as un en Irlande Le BGP c'est pas déterministe et sur du cloud tu n'as pas le contrôle fin d'un ISP. Et bonjour les coûts d'egress inter-régions si le trafic est mal routé.

Anycast a sa place mais c'est pas une solution miracle pour tout. Pour des services stateless comme du DNS ou du CDN c'est top. Mais dès que tu as de l'état ou des sessions stickies c'est compliqué voire impossible sans une réécriture complète de l'application.

Et comme dit le monitoring de la santé de tes endpoints Anycast est critique. Il faut que tes systèmes retirent l'annonce BGP instantanément si le service devient unhealthy. Ça demande une intégration très fine entre le réseau et les checks applicatifs.

Les problèmes de routage c'est souvent un souci de conception ou d'implémentation. Si tu annonces tes routes BGP avec les bonnes communautés et les bons poids tu peux influencer le routage. Et les providers cloud ont des solutions type Global Accelerator ou des équivalents qui masquent une partie de cette complexité BGP derrière une API.

Le FinOps par contre oui ça peut coûter cher si tu ne dimensionnes pas bien et que tu as du trafic qui fait le tour du monde. Mais le gain en UX et en SLA peut justifier le coût.

Global Accelerator c'est une option mais tu restes dépendant du provider. Et le BGP même avec les bonnes communautés reste un protocole qui peut prendre des décisions imprévisibles sur internet.

Un Simple Load Balancer avec du GSLB ou même un basculement DNS peut offrir une résilience comparable avec beaucoup moins de maux de tête opérationnels. La latence sera peut-être quelques ms de plus mais la complexité du déploiement et du debug est incomparable.

Le DNS a le problème du TTL. Si ton service tombe il faut attendre que les caches DNS expirent pour que le trafic soit redirigé. Anycast est bien plus dynamique. Par contre la complexité d'un service mesh comme Istio ou Linkerd avec mTLS et des policies d'identité fortes peut interagir bizarrement avec un routage Anycast externe.

Il faut s'assurer que les services internes sont prêts à gérer le trafic venant de n'importe quel PoP sans attentes spécifiques sur l'IP source ou la localité.

La dynamique d'Anycast c'est le point fort. Quand un point de présence est unhealthy tu retires l'annonce BGP et le trafic bascule quasi instantanément. Pas de délai DNS ou de sessions à purger. Pour la fiabilité c'est un cran au-dessus.

Et pour le service mesh ce sont des couches différentes. Anycast gère l'entrée du trafic dans ton réseau global et le service mesh gère le trafic entre tes microservices une fois qu'il est dedans. Ça peut même simplifier le service mesh en lui présentant un trafic déjà bien réparti géographiquement.

Simplifier oui si ça marche bien. Mais si ton BGP fait des siennes c'est tout ton service mesh qui va être perturbé avec des connexions qui partent dans le vide.

Et parlons de la gestion de la configuration. Chaque PoP Anycast doit être une réplique parfaite des autres. La moindre dérive de configuration entre tes régions peut te créer des problèmes monstrueux de routage ou de service. Ça demande un IaC irréprochable et du GitOps poussé.

Oui l'IaC et le GitOps sont des pré-requis absolus. Terraform pour l'infra et ArgoCD pour le déploiement applicatif dans chaque région c'est le minimum. Mais même là il y a des subtilités régionales les AZs ne sont pas les mêmes les quotas différents les ressources parfois non disponibles.

Et la visibilité FinOps est essentielle. Tu dois avoir des outils de monitoring qui te donnent les coûts par région et le trafic entrant/sortant pour chaque PoP Anycast pour éviter les surprises sur la facture cloud.

Les outils existent pour ça. Prometheus avec des exporters BGP spécifiques peuvent te donner une vue sur les annonces et les retraits de routes par PoP. Tu couples ça à des logs BGP et tu as un bon niveau d'observabilité réseau.

Et pour la configuration Ansible ou Puppet peuvent automatiser le déploiement mais le plus simple est de s'appuyer sur des AMI ou des images Docker immutables pour chaque PoP. Moins de chance de drift.

Des exporters BGP spécifiques c'est encore de la complexité. Qui développe ça Qui maintient ça C'est pas plug-and-play. On parle d'un overhead opérationnel massif juste pour un service Anycast.

Et pour des applications critiques qui nécessitent des bases de données répliquées multi-régions comme PostgreSQL ou MySQL avec réplication ça devient encore plus tendu. L'Anycast ne résout pas la latence physique entre les bases. Faut pas tout mélanger.

Non Anycast ne réduit pas la latence physique entre les régions pour la réplication des bases de données c'est clair. Ça aide juste à acheminer les requêtes client vers la base la plus proche si ton application est bien conçue pour ça.

Mais pour une application qui doit écrire dans une base centralisée ou avec un quorum il y aura toujours une latence incompressibles. Anycast est parfait pour du read-heavy ou du edge computing.

C'est exactement ça. C'est pour le trafic d'entrée et les services sans état au bord de votre réseau. La philosophie des systèmes distribués modernes c'est de rendre les applications le plus stateless possible. Si votre app est encore pleine d'état ça va être dur mais c'est un problème d'architecture applicative pas d'Anycast.

Facile à dire. Reprendre une app legacy de 10 ans pour la rendre stateless juste pour du BGP Anycast c'est un projet de 2 ans et des millions d'euros. C'est pas une solution générique. Pour 90% des boîtes le GSLB fera le job avec moins de frais.

Chaque outil a son domaine d'application. L'Anycast BGP sur le cloud c'est une technique avancée pour des cas très précis où les gains en performance et résilience justifient l'énorme complexité. Pour la majorité des infrastructures un bon setup DNS un CDN et des load balancers cloud classiques sont plus que suffisants.

Si on parle de microservices critiques avec des milliers de requêtes par seconde et un besoin de résilience extrême alors oui Anycast devient intéressant.

OK le débat est très clair et musclé. Je retiens que l'Anycast BGP sur le cloud c'est puissant pour la latence et la résilience mais avec un coût opérationnel et FinOps non négligeable surtout pour le debug et la gestion des états.

On va se pencher sur la faisabilité pour nos services edge stateless en priorité et voir si le ROI justifie l'investissement. Pour le reste un bon vieux GSLB fera l'affaire. Merci à tous pour les arguments tranchés et les mises en garde.