Le 21/05/2021 à 11:46, Xavier Beaudouin a écrit :
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...
Effectivement le SDN a 2 cibles, autant tu décris un end-user qui va
assembler des briques pour construire un service où il faut normalement
des compétences d'architecte d'infrastructure. Je partage ton point de vue.
Mon argumentaire est vu d'un ISP qui livre des services télécom où le
SDN est la base de l'usine télécom.
C'est vrai que l'usage que l'on peut en faire est bien différent.
- 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é ....).
C'est vrai, j'ai également encore mon serveur perso, mais c'est assez
rare que gmail/azure perdent le serveur, sinon ils ne géreraient pas
autant de boites mails.
Est-ce encore nécessaire d'être un expert SMTP pour réussir à envoyer un
mail ?
Hier où la majorité des protocoles étaient encodés en binaire (pratique
de faire un recv(fd, &ma_structure, sizeof(ma_structure)) et pour parler
avec ce protocole il fallait en devenir un expert. Où aujourd'hui 99%
des protocoles sont du JSON/XML sur de l'HTTP où les lib HTTP/REST/SOAP
(quel gros mot !) sont suffisamment bien faites pour ne pas avoir à
connaître comment fonctionne HTTP 1.1.
Lorsque je vois toutes les difficultés qu'a HTTP 2 à émerger, seules les
grosses boîtes de dév arrivent à faire de l'HTTP 2 car personne n'a
envie de se replonger dans HTTP (en plus pour quel bénéfice ?).
Toutes ces expertises se perdent car elles ne sont plus nécessaires.
Avant les années 2005 à chaque installation d'un linux je me recompilais
le kernel pour l'adapter au hardware, combien de fois il fallait avoir
le module xxx pour la carte raid, pour le chipset réseau ? Maintenant je
ne sais même pas à quelle version de linux on en est, ma ubuntu boot sur
n'importe quel serveur / desktop.
Est-ce que ça serait bien que je garde cette connaissance sur un usage
qui est devenu obsolète ? Je ne pense pas.
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...
Je trouve que les marketeux sont des génies. Comme Sun & IBM qui
vendaient des serveurs "optimisés" pour faire tourner du Java qu'ils
enrichissaient. Les ESN préconisaient Java et recommandaient donc ces
mêmes serveurs.
Si tu veux du Salesforce il faut intégrer un maximum de chose dessus car
c'est plus sympa, d'où sa marketplace qui prend tout son intérêt.
AWS vient avec son écosystème (S3, route53, EFS, EKS, ...), ils ont crée
un marché d'infogéreurs qui recommandent AWS et qui en font acheter à
leurs clients car ils savent en tirer des avantages (uniquement marketing ?)
(déjà vu) Petite pique gratuite sur wordpress by AWS:
https://d1.awsstatic.com/EFS/aws-refarch-wordpress-v20171026.802ed5ccfb10e2274c37f3724b45afabb879ddf4.jpeg
Un peu comme un google qui vend/donne son android et qui se rémunère à
travers les applications qui sont vendues via google play.
C'est merveilleux quand tu as des gens qui recommandent ta solution car
ils y ont leur intérêt, et c'est encore mieux si tu n'as pas à les
rémunérer pour cela !
Et que ça permet d'entretenir ton business.
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...
Tu as bien raison, ça a fait un gros flop, même UML a disparu des radars!
--
Jérôme Marteaux
---------------------------
Liste de diffusion du FRnOG
http://www.frnog.org/
