Bonjour, > Le 28 mai 2021 à 17:15, Kévin CHAILLY <ke...@chailly.eu> a écrit : > > Alors sans doute, il y a le bon et le mauvais SDN, mais j'aimerais bien qu'on > arrête de me vendre un concept magique et qu'on explique quelles solutions > apporte à quel problème un produit donné, et qu'on arrête les management > centralisés obligatoires et autre abonnement > si-tu-le-prends-pas-je-route-plus-tes-paquets, je veux avoir le choix > d'arrêter de payer le vendeur si le service n'est pas rendu, car j'ai déja > payé le produit.
Salut Kévin, dans ce cas ce n’est pas le SDN que tu dois balayer, mais juste le commercial :). SDN n’implique pas de routage centralisé, quant au management centralisé faut rentrer plus dans le détail de ce qui changerait je pense car je trouve que le management des réseaux à toujours été en quelque-sorte centralisé dans la zone Syslog/SNMP/Bastion. > Au final, certaines solutions pourtant pertinentes technologiquement se font > éconduire a la porte car apportant plus de restrictions que d'avancées. > Ouaip, c'est bien de faire du CI/CD et de lâcher la CLI, mais l'obliger, je > veux que ce soit ma décision et pas celle du vendeur alors que rien ne le > justifie technologiquement. Bah là pour le coup je veux bien une explication car je ne vois pas comment l’un peut fonctionner sans l’autre. Du moins, je ne vois pas comment tu peux faire de « Continuous Deployment » dans ce cas. Si tu utilises CI/CD jusqu’au Continuous Delivery, effectivement tu n’est pas obligé de changer tes habitudes de prod en CLI. Mais pour le coup tu n’as rien gagné, et je dirais même que tu as surtout perdu ton temps, car ta phase d’ingénierie restera complètement décorrélée de la vie de ta prod… c’est d’ailleurs le cas de figure qui historiquement a fait émerger la culture DevOps, vu que les XP/Agile/etc sortaient très vite des trucs tout beau tout chaud mais qui ne pouvaient jamais aller en prod. Donc pour réussir in fine à faire du CI/CD jusqu’à la prod, faut respecter le concept de ‘cattle’ qui dit en gros qu’on ne touche à la config des équipements en CLI qu’en phase de développement (i.e. avant les tests). > Moi, j'aime bien openvSwitch, en plus y'a pas SDN dans le titre, ni dans la > description, c'est open, c'est virtual, c'est un switch. même le titre > apporte une réponse a une problématique donnée, c’est marrant comme exemple car openvSwitch a une API pour faire du SDN, et notamment faire de l’openFlow avec OVSDB qui est donc du tout centralisé… mais on peut aussi y faire du SDN autrement (i.e. non centralisé), voire ne pas en faire du tout, comme quoi ce sujet de SDN n’est pas si « noir et blanc » que ça. > Le 28 mai 2021 à 18:28, Michel Py <mic...@arneill-py.sacramento.ca.us> a > écrit : > > C'est une bière très chère, mais quand tu veux ! Salut Michel, noté :) > Fast-forward 3 mois plus tard, le vendeur de pompes usées évidemment ce n'est > plus son problème dès que la commande est passée, et qui c'est qui se > retrouve baisé à essayer de faire marcher la bouse très chère qui non > seulement ne sert à rien mais en plus double la complexité de l'usine à gaz ? > ben c'est David et Michel, entre autres. Malheureusement du Business As Usual dans beaucoup (trop) de boîtes, et ce pour tout type de trucs à vendre, non ? je vois en tout cas dans ton argument plutôt une problématique entre tech et direction qu’une problématique de technologie. Et en témoignage, je peux dire ne pas avoir vu de « double » complexité. Mais il y a bien une complexité à gérer, à savoir celle de pouvoir maîtriser l’ensemble des éléments de routage et de sécurité, voire également de virtualisation. Bref ce qu’on avait avant en plusieurs boîtes, voire réparti sur deux équipes, on l’a ici nécessaire chez une seule personne. Donc un sujet de compétence et donc de formation. > Le 31 mai 2021 à 14:54, Benjamin CALLAR <callar.benja...@gmail.com> a écrit : > > Je suis d'ailleurs curieux (sans trahir de secret), de savoir quelles > solutions techniques sont mises en place ? Ça semble joli à voir :) > > Je suis malheureusement forcé de constater que grand nombres de solutions > "SD-WAN" ne permettent uniquement que de faire du Policy-Based Routing > statique et manuel au dessus d'un VPN IPSec (parfois même, ce n'est pas > compris) ... mais le terme SD-WAN se vends plus cher ;) Cyrille infirmera peut être mes propos, mais cela semble être en grande partie du « standard SD-WAN » avec du DPI pour la catégorisation du trafic, un mécanisme de mesure de SLA des tunnels (type BFD ad-hoc ou mesure OAM des paquets data), et une configuration par l'administrateur de « poids métier » + seuil de reroutage par application. Là où il semble y avoir une fonction que tous n’ont pas, c’est la possibilité de rerouter via un site de transit (i.e. pas un autre provider pour aller de A à B mais de faire A-C-B, où C est un site SD-WAN). -- Grégory --------------------------- Liste de diffusion du FRnOG http://www.frnog.org/
