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/

Répondre à