On 3 nov. 2012, at 21:35, Julien Boussu <d...@xgs-france.com> wrote:
> Désolé de m'immiscer dans votre échange Pro/anti. Avec plaisir, pour une fois ça ne troll pas beaucoup, il y a eu des tentatives, mais bon ,c'est Frnog hein :) > Je me permet de donner mon point de vue sur un débat qui aura aussi peu de > réponse qu'un autre troll mondiale dans le monde des smartphone. > > J'ai pendant longtemps déployé des solutions basées sur du BSD (Quagga, PF, > racoon and co ….) et depuis 3-4 ans je déploie principalement du constructeur > (Juniper, Cisco principalement). > Je n'ai pas le sentiment d'avoir plus ou moins de support avec l'un ou > l'autre. Je peux pas dire que les constructeurs soient plus réactifs à mes > problèmes quotidien que ne l'est la communauté Opensource autour de BSD. > Sachant, dans le cas de Juniper par exemple, que Junos doit pas mal à Freebsd. > Je crois que la question et donc le choix finale ne se fait pas autour de ça > mais plutôt autour de la fameuse question : Intégration verticale ou > horizontale ? > (D'où ma référence au troll mondiale ….) > > La première problématique que l'on a rencontré avec les solutions BSD est > leur industrialisation et la capacité à le faire avec une croissance soutenue > ainsi que la capacité à avoir une solution homogène et parfaitement intégrée > à tous les niveaux. Avec ces solutions on récupère des briques à droite, à > gauche en espérant que chacune respecte les RFC, les standards, appelez ça > comme vous le voulez. > Et là, malgré que ce soit de l'Opensource, vous pouvez avoir de franche > surprise et de sacrée crises de nerf. > Ajoutez à cela que chacune des briques n'évoluent pas toutes au même rythme > et vous pouvez vous retrouver bloquer pendant pas mal de temps sur un > problème parce que la brique d'à côté n'a pas évolué depuis une éternité. > Donc oui les solutions Opensource fonctionnent très bien mais leur > intégration avec le reste du monde peut parfois laisser à désirer. Leur > industrialisation peut s'avérer être aussi un vrai casse tête. Mais ce que > j'aime bien dans l'idée de ces solutions, c'est la nécessité de recruter des > gens "avec une tête bien faite" et pas simplement des gens ayant passé une > certification constructeur et ne jurant que par ce constructeur parce qu'ils > sont incapable d'utiliser autre chose. C'est pour cela que les certifications haut niveau que ce soit chez Juniper ou Cisco sont un peu plus sélectives que les certifs pourries de M$ Je parle bien sur des certifs un peu haut niveau, pas la junos de base ou le ccna/ccnp qui n'ont mais pas une once de valeur lorsque je recrute qqn ! > Ce qui ne veut pas dire que dans les pro constructeurs, on ne trouve pas des > gens "avec des têtes bien faite". Oui, les certifs d'experts dénotent des mecs qui maîtrisent la partie protocole et partie soft/HW du constructeur. > Il ne faut pas me faire dire ce que je n'ai pas dit. > Mais avec l'Opensource c'est un pré requis indispensable. > > Le côté agréable des solutions constructeurs est justement leur intégration > et leur industrialisation. Soit parce que le constructeur développe une gamme > complète de solutions sur toutes les couches, soit parce qu'ils ont de bons > partenariats permettant de faire évoluer toutes les briques au même rythme. > En revanche, je les haie quand ils m'expliquent que je dois de nouveaux > m'affranchir d'une license pour rajouter la moindre fonctionnalité basique !! > Et ce phénomène est plus ou moins énorme en fonction du constructeur. Suivez > mon regard …. Oui, j'aime bien Juniper, mais bon sur certains équipements, pour avoir de l'ipv6, il faut payer car des gens super bien pensant ( sûrement du marketing hein ) ont décidé de mettre l'ipv6 dans les licences de routage avancées... Ça fait juste 4 ans que je me bats avec eux. Dernier truc à la mode, tu veux avoir des stats ipv6, il faut une licence ipfix sur les MX, et .... C'est payant et pas genre 100 euros, mais plusieurs milliers de k€. Si l'ipv6 n'a pas encore bien avancé, c'est aussi en grande partie à cause des constructeurs. > Dans le monde Opensource, ce qui va vous limiter, ce sont vos compétences, > pas une stratégie commerciale à se jeter dans la Seine …. Ne pas être lié à > une histoire de license permet bien plus de réactivité et de créativité pour > répondre à une nouvelle problématique. Créativité ne veut pas dire bidouille, > on peut l'être tout en respectant les règles de l'art. > > Pour le côté bidouille, on peut tout aussi bien en faire avec une solution > constructeur qu'avec une solution Opensource. On fait de la bidouille quand > on ne maîtrise pas la techno. Et il suffit de regarder l'implémentation de > solutions constructeurs dans certaines entreprises pour s'apercevoir que la > bidouille est fortement présente ….. PME et entreprises du CAC 40 confondues > …. > > Bref, ça ne fait qu'un éternel débat supplémentaire. > > Le 3 nov. 2012 à 20:42, Jérôme Nicolle <jer...@ceriz.fr> a écrit : > >> On 03/11/2012 20:22, Raphaël Maunier wrote: >>> Encore une fois, si ton business en dépend, ne bidouille pas, si c'est du >>> POC ou oui tu peux t'amuser. >>> Je pars du principe que si ça ne "scale" pas avec un support "pro" et >>> constructeur, et aussi en perf, je passe mon chemin. >> >> Pour moi ça dépend de la confiance relative que tu apportes à des >> constructeurs plutôt qu'aux développeurs et intégrateurs de solutions >> logicielles. >> >> Pour ma part, étant donné l'opacité des constructeurs et leur mauvaise >> volonté à assurer un niveau de qualité et d'efficacité satisfaisant sur >> leurs gammes logicielles, l'open source est un choix pragmatique. >> >> Je prends pour exemple quelques cas concrets de bugs dont l'identification >> et la résolution a pris tellement de temps (en local, hors contrat de >> support, mais toujours moins cher que l'assurance appelée contrat de >> support) qu'il eut été plus rapide de patcher et/ou documenter une >> implémentation open source que de s'obstiner dans la voie du 100% >> proprio-cher-garanti. >> >> Je comprends parfaitement ton point de vue "service provider" : tes besoins >> ne permettent pas ces alternatives, que tu ne connais donc pas faute >> d'utilité. Pour certains de tes clients, tu pourrais être à la limite de >> rentabilité mais tes accords avec les constructeurs, ou ton habitude de >> bosser avec eux fait que le jeu n'en vaut pas la chandelle. >> >> Par contre en aucun cas tu ne peux critiquer la fiabilité de solutions open >> source. Le code est accessible, généralement assez simple dans les morceaux >> qui nous concernent, pour une compréhension de la logique de la solution, et >> assez documentée par des gens qui ont un état d'esprit plus propice aux >> échanges constructifs que les commerciaux de tes constructeurs. >> >> La différence que tu sembles ne pas saisir est qu'on est pas là uniquement >> dans une logique de service provider mais aussi dans une logique >> d'intégrateur. Qu'un de tes employeurs ne soit pas staffé pour se faire >> chier à intégrer du très spécifique et préfère composer avec des briques sur >> étagère, c'est une évidence. Mais il y a des gens dont le métier est de >> faire du sur mesure, et qui travaillent plus efficacement, par la faute même >> des constructeurs, avec de l'open source qu'avec du cisco/juniper/whatever. >> >> Les service provider et les intégrateurs sont complémentaires, c'est une >> évidence dès lors qu'on sort des sentiers battus. Et ta position tendant à >> ignorer cette évidence m'amène à me demander si ta stratégie est de >> t'adapter à ton client ou d'adapter ton client à ta logique. Un peu comme >> SAP dans le monde du progiciel, avec sa longue liste de cadavres >> d'entreprises mortes de la marche forcée vers le conformisme industriel. >> >> Il y a de la place pour tout le monde, tu ne peux pas dénigrer le travail >> des intégrateurs sans te couper d'un pan entier du marché et de la >> compétence. >> >> Pour ma part, je respecte les orfèvres de l'open source qui ont crée une >> vaste logithèque, très bien documentée, capable aujourd'hui de répondre à >> quasiment tous les besoins de nos clients, dont l'accès à Internet. >> >> Et quand bien même tu aurais raison quant à la fiabilité relative de >> certaines solutions eu égard au coût des assurances quasi obligatoire, >> vendues comme contrats de supports, tu peux admettre qu'on peut faire le >> choix de gérer le risque d'exploitation inhérent à toute technologie en >> interne, en créant de l'emploi pour ça, plutôt qu'en se rendant >> volontairement dépendant de son constructeur. C'est un business model >> différent, que tu n'est certainement pas en position de critiquer sur ce >> point. >> >> -- >> Jérôme Nicolle >> 06 19 31 27 14 >> >> >> --------------------------- >> Liste de diffusion du FRnOG >> http://www.frnog.org/ > > > --------------------------- > Liste de diffusion du FRnOG > http://www.frnog.org/ > --------------------------- Liste de diffusion du FRnOG http://www.frnog.org/
