Hello Jérôme,
> Je ne suis pas tout à fait d'accord. Ce genre de produit permet: > - de permettre à plus de gens (il n'y a pas tant que ça d'expert > réseau sur le marché de l'emploi) de mettre en prod des services sur > étagère: > - donc d'accélérer la livraison du service; > - de standardiser le déploiement, donc moins d'erreur, moins > d'échec de livraison, plus de satisfaction client; > - plus d'homogénéité du réseau, une documentation à jour ? Donc > plus aisé de faire du troubleshooting dessus; > - donc de diminuer le coût du service; > - donc d'augmenter le nombre de service pour qu'il puisse profiter > à plus de gens. S'il fallait qu'un ingé télécom travaille 2 heures pour > activer une FTTO/FTTH il n'y aurai pas grand monde qui aurait la fibre à > son travail / à la maison. Oui et non... C'est "pratique" pour mettre en place un service ou le déployer, là dessus on est d'accord, mais laisser des gens qui ont peu ou pas d'expertise a déployer des réseaux de prod, on arrive vite fait à un bordel sans nom, des choix discutables, et aussi des problèmes de sécurité. Allez demander au sysadmin quand ils se battent avec des devoups qui déploient des dockers récupérés je ne sais où, avec des mises à jour de sécurité inexistantes depuis 5 ans... > - en tant qu'expert réseau je préfère travailler sur des sujets > autrement plus intéressants que de déployer des services basique sans > intérêt technique et à travailler à la chaîne au déploiement des > services qui sont toujours les mêmes; Déployer des services basic peut être automatisés *sans* passer par un SDN/SD-WAN proprio. > - le but ultime de ce genre de produit c'est d'arriver à standardiser > des pratiques (que contient le service, son déploiement, sa > configuration, son exploitation ...). Par exemple les emails, jusqu'aux > années 2010 il fallait gérer son serveur mail avec le smtp, l'imap/pop, > le webmail, les anti-spam, anti-virus, les quarantaines et c'était les > admin sys qui géraient le support des utilisateurs. Grâce à l'essor de > gmail, azure, 95% des boîtes mails sont maintenant dans le cloud avec > devant des clickodromes permettant de gérer ces boites mails. Depuis, je > ne gère plus cette partie ! Je peux me concentrer sur de l'admin sys qui > m'intéresse plus ! Et quand gmail ou azure t'as buté ton serveur, tu es aussi dans la merde, pareil... vu le nombre de gens qui ne comprennent pas l'infra du mail et qui pensent que ça doit être immédiat... Je gère encore mon serveur, il y a des solutions qui le permette sans avoir a se taper tout... ceci dit, ca apprends les protocoles et comment débugger les choses quand ça part en couille... (aka expliquer aux devoups ce qu'ils doivent mettre dans un mail pour pas qu'il soit jeté ....). > Et pour finir, je ne pense pas que ni les gros acteurs ni les petits > utilisent ce genre d'outil marketé par les équipementiers, il y a > largement la place pour développer des solutions home-made. +1. Mais attention au SSII^H^H^H^HESN qui aiment bien pousser des solutions chères et privatrices... > Le véritable sujet derrière tout ça c'est la scalabilité que ces outils > permettent de gagner. A la base on est un artisan qui façonnons nos > réseaux, nos outils (bientôt le dernier "dino" des télécom au JT de TF1 > ? :) ). Mais pour passer à la vitesse supérieure, il nous faut une usine > avec des robots que des humains moins expert peuvent piloter et contrôler. *SURTOUT* contrôler... mais ça me fait penser aux générateurs de codes qui ne sont plus trop à la mode... /Xavier --------------------------- Liste de diffusion du FRnOG http://www.frnog.org/
