Table-ronde : Cloud Network/SDN - it's someone else's router/firewall avec Jerome Fleury, Steven Le Roux, Raphael Maunier, Thomas Soupault
#FRnOG
#FRnOG
Category
🤖
TechnologieTranscription
00:00 Bonjour, je m'appelle Stéhan, je suis situeux au Clamour Cloud.
00:06 Bonjour, Thomas Soupault, Criteo, manager des équipes réseau.
00:11 Bonjour, Raphaël Bonnier, je fais plein de trucs.
00:15 Bonjour, Jérôme Fleury, je suis VP Network Engineering chez Cloudflare.
00:22 Très bien, laissez-moi charger les questions.
00:30 Il fallait faire la version longue, les mecs, vous m'aidez pas.
00:39 Il faut tenir une heure sur le SDN ?
00:46 Tu verras, ça passe vite.
00:52 C'est bon, je l'ai.
00:56 Alors, on s'est dit qu'on allait faire une petite table ronde.
01:00 C'est marrant, parce que celui qui a eu l'idée, malheureusement, n'est pas là.
01:05 C'est Nicolas Strina, je ne veux pas le dénoncer.
01:09 On allait faire une petite thématique, si les astres ne sont pas avec moi.
01:17 Sur Cloud Network et SDN, et sur les limites du modèle,
01:26 ou en tout cas les inconvénients qu'il pourrait y avoir à terme.
01:30 Je veux lire des questions qu'on a préparées en random, en termes d'ordre.
01:36 Tout comme un certain nombre de développeurs ne savent plus ce qu'est un package par rapport à un container,
01:45 ça commence fort.
01:48 Est-ce que le Cloud Network et le SDN ne vont pas invisibiliser les technologies sous-jacentes ?
01:54 C'est comme Soch, celui-là il est dur à...
01:58 Est-ce que cela peut amener à une perte de savoir-faire, à terme ?
02:03 Allez-y !
02:06 Ça suppose que les développeurs aient un jour su qu'elles étaient les couches sous-jacentes.
02:14 (Rires)
02:17 (Applaudissements)
02:22 Il y en a des biens, comme on dit.
02:25 Après, il y a un premier point, un deuxième point, on pourrait dire que...
02:33 On faisait les équipes on-prem et versus cloud.
02:37 Je vais parler pour le cloud, mais ce n'est pas parce que tu as l'impression de voir ou de comprendre un Overlaid Cloud Provider
02:43 que tu sais comment ça fonctionne en dessous.
02:47 Le Cloud Provider peut très bien t'exposer un L2,
02:51 mais en fait ça n'a rien à voir avec du L2, c'est du L3 qui est émulé et n'étend pas grand-chose.
02:58 Si je vous demande comment est fait le réseau d'Amazon,
03:01 je ne suis pas sûr qu'ici il y ait beaucoup de gens à pouvoir me dire comment c'est fait.
03:04 Parce qu'en fait c'est des implémentations propriétaires de réseaux complètement virtualisés en software, etc.
03:12 Globalement, il y a des équipes internes qui développent ça.
03:18 Et la problématique d'intégration pour les utilisateurs qui sont dessus,
03:22 en fait elle est assez loin.
03:24 On pourrait poser la question des impacts que ça a effectivement
03:28 entre un modèle standard d'implémentation réseau et un modèle Cloud Provider.
03:33 Mais voilà, tu as une vraie distance entre les deux.
03:37 Le troisième point, c'est qu'il y a aussi des limites au modèle standard.
03:44 C'est-à-dire que l'implémentation d'un réseau standard,
03:50 c'est quelque chose qui est assez lent à synchroniser.
03:56 Je m'explique.
03:59 Chez nous, une fonction Azure Service, ça boot en une milliseconde à froid.
04:03 Une virtuelle machine.
04:05 En une milliseconde, je n'ai pas du tout le temps d'aller converger du réseau,
04:08 d'aller créer une interface dans une DB, synchroniser les équipements, etc.
04:12 C'est-à-dire que la virtualisation du réseau,
04:16 elle ne peut pas se faire au niveau des équipements et des choses traditionnelles.
04:19 Donc on doit le faire en soft, et on doit le faire de manière hyper flexible
04:23 pour justement atteindre ces latences-là.
04:26 Est-ce que c'est grave que les utilisateurs de notre plateforme
04:30 ne sachent pas comment c'est fait en dessous ?
04:33 Je ne suis pas sûr, parce qu'encore une fois, ils sont développeurs,
04:35 donc ils ne savent pas comment ça marche et ils s'en foutent.
04:39 Wow, c'était long.
04:42 Bon, on ne va pas jouer à la compétition.
04:44 Est-ce que je peux faire plus vite que toi en on-prem par rapport à du cloud ?
04:48 Je pense que la question de Philippe, elle est surtout sur les compétences.
04:50 Le client du SDN, ce n'est clairement pas les ingéts réseau.
04:54 Donc si tu utilises du cloud network, oui, pour te répondre,
04:58 oui, tu vas perdre de la compétence.
05:00 Nous, chez Criteo, le SDN, on en consomme un petit peu,
05:03 on en produit pas mal.
05:05 Mais surtout, les clients, c'est des développeurs,
05:07 ou vous savez, les gens des serveurs.
05:10 Nous, on voit ça comme un aboutissement de l'automatisation
05:13 qui nous permet de rationaliser la façon dont on travaille
05:16 avec ces gens des serveurs et les développeurs.
05:19 Donc nous, on ne perd pas de compétence.
05:21 Maintenant, si je devais exploiter ce genre de service progressivement,
05:24 clairement, je perdrais des compétences dans l'équipe
05:26 et ça m'inquiéterait beaucoup.
05:28 Pour nous, l'on-prem, on sait pourquoi on en fait
05:31 et je dois garder ces compétences en interne.
05:34 Alors, de côté d'une infra assez grosse,
05:37 comme on avait pu faire chez F5 avant que je parte,
05:40 je dirais que c'est un peu ce qu'on a vu
05:45 sur la présentation de Robin ou de Pierre-Yves.
05:48 On est sur deux mondes totalement différents
05:50 où, de toute façon, le besoin d'infrastructures redondées,
05:53 on part du postulat quand un dev,
05:55 lui, ça marche en fait, il s'en fout.
05:57 Après, de savoir si le dev a besoin de connaître ce qu'il y a dessous,
06:00 je dirais peut-être pour sa culture personnelle, oui.
06:02 Après, c'est plutôt l'inverse que moi je dirais,
06:05 c'est si un mec du réseau ne comprend pas du dev,
06:07 pour moi, il est obsolète.
06:09 Je partirais plutôt de ce sens-là que de l'autre sens.
06:11 Je pense que le mec du dev, c'est pas très grave,
06:13 mais le mec du réseau, s'il ne connaît pas du dev,
06:15 là, c'est plus problématique.
06:17 Moi, je dirais que si la question c'est
06:22 est-ce que ça va abstraire les fonctions réseau,
06:27 je dirais oui, et c'est le but en fait.
06:29 Le but, c'est que pour le développeur,
06:31 tout ça soit transparent, qu'il puisse faire des accès
06:33 à une database, qu'il puisse aller contacter
06:35 un serveur Redis, peu importe,
06:37 sans qu'il se pose même la question
06:39 où ça se trouve, quelles sont les capacités
06:41 du système en place, etc.
06:43 Parce qu'au final, le but, c'est vraiment
06:45 d'abstraire tout ça pour qu'il puisse se concentrer
06:47 sur son application qu'il doit développer.
06:49 Donc, je pense que c'est plus une feature
06:51 qu'un bug.
06:53 C'est pas vraiment une perte des connaissances,
06:55 c'est une dilution des compétences, ou en tout cas,
06:57 une répartition des connaissances vers des gens
06:59 qui vont être spécialisés dans ces infrastructures
07:01 bas niveau, et puis des gens qui vont être
07:03 spécialisés dans l'applicatif
07:05 et comment on peut interconnecter tout ça ensemble.
07:07 - Alors, une question qui est relativement liée,
07:11 avec toutes les API
07:13 et les empilements invisibles,
07:17 le potentiel de services,
07:19 on va dire de la born wifi,
07:22 services DNS, VPN, Firewall,
07:25 WAN, enfin SD-WAN,
07:27 quid de la résilience ?
07:29 Si tout est cloud,
07:31 personne n'est responsable de rien ?
07:33 Ou comment vous voyez ça ?
07:36 - Je vais commencer.
07:40 Je pense que quand un développeur va chez un fournisseur de cloud,
07:45 je pense qu'effectivement, c'est une forme de sous-traitance.
07:47 Tu transfères à ton fournisseur de cloud
07:50 certaines compétences,
07:52 notamment peut-être la résilience de ton application,
07:54 dans certains cas, ou en tout cas, par exemple,
07:56 de ta base de données, ou des choses comme ça.
07:58 Il y a une forme de confiance.
08:00 Tu sais pourquoi tu signes,
08:02 tu sais pourquoi tu payes,
08:04 et donc quelque part, tu attends un certain niveau de service,
08:06 que peut-être tu n'es pas en mesure de t'offrir,
08:08 mais que ton fournisseur de cloud va pouvoir t'offrir.
08:10 Moi, ça m'est déjà arrivé d'être,
08:14 d'aller expliquer à un régulateur de banque en Asie,
08:17 mon système de résilience,
08:19 parce que mon client avait des problèmes,
08:21 avait eu des incidents,
08:23 et comme nous étions le fournisseur de cloud,
08:25 c'était à nous d'aller répondre à l'instance de régulation
08:27 qui est sur nos modèles de résilience.
08:29 Donc, il y a vraiment une forme de sous-traitance.
08:31 Alors, comment tu disais ?
08:38 Personne n'est responsable de rien ?
08:40 Oui, c'est ça.
08:42 Si tout est API,
08:44 y compris avec des empilements,
08:46 c'est-à-dire un cloud qui fait appel lui-même
08:48 à un autre service,
08:50 un cloud de borne wifi qui fait appel
08:52 à du Zscaler derrière,
08:54 à force d'empiler,
08:56 il y a un moment, tu vois...
08:58 Si plus personne n'est responsable de rien,
09:00 en fait, le client est responsable de tout.
09:02 C'est comme ça qu'il faut voir.
09:04 Si tu mets tout dans le cloud, tu prends tes responsabilités.
09:06 C'est bien toi qui vas faire ton debug.
09:08 Je pense que ça pose plutôt la question de savoir
09:10 quelles compétences tu gardes en interne.
09:12 Donc, tu n'as plus d'ingénieur réseau,
09:14 tu n'as peut-être plus d'ingénieur d'infrastructure.
09:16 Tu as plus de compétences,
09:18 tu as plus de compétences pour faire des choses.
09:20 Et puis, tu as plus de compétences pour faire des choses.
09:22 Donc, tu as plus de compétences pour faire des choses.
09:24 Et puis, tu as plus de compétences pour faire des choses.
09:26 Donc, tu as plus de compétences pour faire des choses.
09:28 Et puis, tu as plus de compétences pour faire des choses.
09:30 Donc, tu as plus de compétences pour faire des choses.
09:32 Et puis, tu as plus de compétences pour faire des choses.
09:34 Et puis, tu as plus de compétences pour faire des choses.
09:36 Et puis, tu as plus de compétences pour faire des choses.
09:38 Et puis, tu as plus de compétences pour faire des choses.
09:40 Le fait d'avoir effectivement l'architecte,
09:42 c'est lui qui va aussi être capable de dire,
09:44 par rapport à tes enjeux métiers
09:46 et à la résilience que tu veux atteindre,
09:48 comment tu vas implémenter le Cloud Provider ou l'OSDN.
09:50 comment tu vas implémenter le Cloud Provider ou l'OSDN.
09:52 Parce que, si on prend un exemple d'une choix,
09:54 tu dois faire une convergence d'IP flottante ou je ne sais quoi,
09:56 et que si tu veux faire une bascule d'IP,
09:58 c'est un call d'API,
10:00 derrière c'est asynchrone.
10:02 Donc, tu n'as pas de garantie que ça bascule vite.
10:04 Et si tu as besoin d'une résilience rapide,
10:06 et si tu as besoin d'une résilience rapide,
10:08 les modèles traditionnels de routage vont t'apporter cette reconvergence.
10:10 les modèles traditionnels de routage vont t'apporter cette reconvergence.
10:12 Si tu veux basculer une IP,
10:14 avoir une annonce ARP dans un L2 ou ce genre de truc,
10:16 encore une fois, si tu passes par une API,
10:18 tu n'as zéro garantie que ça aille vite.
10:20 encore une fois, si tu passes par une API,
10:22 tu n'as zéro garantie que ça aille vite.
10:24 Donc, le rôle des architectes,
10:26 c'est effectivement de mettre la corrélation
10:28 entre le besoin métier,
10:30 mais tu as des besoins métiers qui sont aussi trivial.
10:32 Si c'est du HTTP avec un load balancer et que tout roule,
10:34 je t'en fous de ta résilience.
10:36 Il peut y avoir une appli qui tombe,
10:38 tu n'as pas de problématique de bascule.
10:40 Par contre, la question est un peu large,
10:42 parce que tu pars du Wifi à la maison jusqu'à...
10:44 Donc là, tu as différentes couches,
10:46 mais après, chaque couche est responsable à son niveau.
10:48 mais après, chaque couche est responsable à son niveau.
10:50 Normalement, si chacun dans les étages
10:52 fait le boulot comme il faut,
10:54 après, tu as des redondances qui s'ajoutent.
10:56 après, tu as des redondances qui s'ajoutent.
10:58 Tu peux avoir du BGP sur ton ingress,
11:00 plus du DNS, enfin...
11:02 Pour moi, tu as toujours un responsable quand même.
11:04 Le plus gros souci que nous, on a pu voir,
11:06 Quand tu as une société qui fait 6-7000 personnes,
11:08 Quand tu as une société qui fait 6-7000 personnes,
11:10 je savais où j'étais avant,
11:12 je vendus ma société,
11:14 c'est que tu as des équipes
11:16 qui sont complètement déconnectées
11:18 l'une des autres,
11:20 et chacun a mis un bout de projet en place,
11:22 qui a connecté parce que c'était la procédure,
11:24 mais il n'y a pas de QA.
11:26 Le QA se fait quand ça tombe en panne.
11:28 Et du coup, tu te retrouves à dire
11:30 "Bon, il y a Joe qui a fait ça à 4h du matin,
11:32 et ça a impacté Michael, etc."
11:34 Et là, il dort,
11:36 et la responsabilité,
11:38 ils vont aller vers le Cloud Provider
11:40 pour dire "T'as merdé, du coup répare."
11:42 "Oui, mais lui il a merdé,
11:44 mais dans le CSAD, il a le droit de merder,
11:46 il s'en fout, il paye."
11:48 Le problème, c'est que quand tu fais du service chaining,
11:50 il y a la chaîne,
11:52 aujourd'hui, n'est jamais testée.
11:54 Ce que fait un peu Netflix,
11:56 qui éteint n'importe quoi à n'importe quel instant,
11:58 aujourd'hui, la plupart des boîtes ne le font pas.
12:00 Parce que ça va être en métier sans compte pour avant-hier.
12:02 Et le souci, c'est que les gens pensent que
12:04 le Cloud Provider doit être up 100% du temps,
12:06 mais du coup, s'ils enchaînent 5 services en même temps,
12:08 ça ne marchera pas pareil.
12:10 C'est exactement ce qu'ils venaient dire,
12:12 c'est le gros problème que tu vois vraiment.
12:14 Donc la responsabilité est vraiment sur le client,
12:16 comme disait Thomas.
12:18 Après, les problèmes que tu décris sont les mêmes en on-prem,
12:20 ce n'est pas spécifique au Cloud,
12:22 mais la résilience, c'est une affaire de design,
12:24 et pas du SLA d'un composant donné.
12:26 Ça, c'est prendre des risques,
12:28 donc c'est le design,
12:30 et c'est peut-être quelque chose qui est mal fait des fois
12:32 sur des déploiements en Cloud.
12:34 Alors le Cloud lui-même peut être extrêmement résilient,
12:36 est-ce que tout le monde utilise les Availability Groups,
12:38 est-ce que tout le monde regarde comment sont physiquement
12:40 faits les déploiements derrière, même pour un clou de flaire ?
12:42 Il faut regarder un petit peu tout ça,
12:44 mais est-ce que c'est fait ?
12:46 Si tu le fais bien, tu peux designer quelque chose
12:48 de résilient, y compris en cas de sinistre.
12:50 Encore une fois, pour illustrer,
12:54 on a un client qui a eu une expérience aussi
12:56 chez un autre Cloud Provider,
12:58 et autant quand tu pousses une appli dans Clever,
13:00 le Load Balancing est inclus,
13:02 tu ne gères rien, on automatise tout l'infra,
13:04 et ce concurrent-là, tu prends ton Load Balancer.
13:06 Et ce que tu dis bien sur la différence
13:08 des SLA par composant, c'est important
13:10 parce que lui, il avait son composant de Load Balancer,
13:12 il avait ses apps en dessous,
13:14 et quand le Load Balancer était off,
13:16 down,
13:18 l'SLA, c'était juste l'indispo du Load Balancer.
13:20 Mais en fait, l'impact, c'est qu'il n'y a plus
13:22 aucune application qui était disponible en dessous.
13:24 Donc ce n'est pas juste
13:26 "ah oui, il était juste down quelques minutes",
13:28 mais ce n'est pas juste l'impact
13:30 de ce service-là qui n'est pas là,
13:32 c'est toute la chaîne derrière
13:34 que tu n'as plus et qui peut avoir un impact
13:36 majeur.
13:38 - Alors une petite question
13:40 qui devrait être
13:42 rapidement évacuée.
13:44 Est-ce que le SDN,
13:46 c'est plus fiable et sécurisé ?
13:48 - Alors,
13:52 c'est vrai que l'humain
13:54 est complètement
13:56 étanche aux erreurs.
13:58 Il n'y a jamais d'erreur humaine, on va dire.
14:00 Mais en fait,
14:02 dans l'approche "SDN",
14:04 c'est que tu as aussi
14:06 le déterminisme du logiciel.
14:08 C'est-à-dire que ce que tu codes une fois, tu peux le tester,
14:10 tu peux le valider, et normalement,
14:12 tu as quand même
14:14 assez peu d'erreurs qui découlent de ça.
14:16 Tu peux en avoir, mais
14:18 tu peux aussi faire en sorte de limiter
14:20 ces erreurs-là.
14:22 En tout cas, c'est ma croyance. Je pense que plus tu fais
14:24 des choses à la main, plus tu es error-prone,
14:26 et plus tu vas te mettre dans des situations
14:28 où...
14:30 On s'en souvient du tweet d'Octave Klaba
14:32 qui a fait sa conf sur Twitter,
14:34 et juste il avait oublié la dernière ligne qu'il avait mangée,
14:36 et du coup, il avait mis tout le réseau down.
14:38 Bon, voilà.
14:40 On était dans un cas de choses à la main
14:42 qui peuvent mal se passer.
14:44 Donc, moi je pense que oui,
14:46 ça fiabilise,
14:48 ça purise après, ça dépend de l'un blême,
14:50 mais au moins ça fiabilise.
14:52 Après, il y a un exemple,
14:54 je crois que c'est chez...
14:56 chez toi,
14:58 il y a eu un exemple où même
15:00 quand c'est automatisé, tu vois, il suffit que dans la ligne
15:02 il y ait un truc qui...
15:04 et puis ça peut tomber aussi.
15:06 Là, tu ne comparais pas
15:08 le SDN versus
15:10 l'on-prem, tu compares l'automatisation versus
15:12 le manuel. Tu peux faire de l'automatisation
15:14 en on-prem, hein ? C'est pas forcément...
15:16 Après, dans ta question, il y avait fiabilité
15:18 et sécurité, je pense que c'est deux choses quand même différentes.
15:20 Fiabilité, c'est plutôt ce qu'on a dit avant
15:22 sur la résilience, le availability.
15:24 Sur la sécurité, moi perso, je ne vois pas vraiment de différence.
15:26 Je n'ai pas de religion par rapport à
15:28 est-ce que le cloud est plus sécure que l'on-prem.
15:30 Mieux vaut que ce soit bien fait sur un cloud
15:32 plutôt que mal fait sur de l'on-prem,
15:34 on peut faire n'importe quoi dans les deux cas.
15:36 Après, il y a des risques spécifiques quand même
15:38 sur des expositions particulières sur le cloud,
15:40 je ne vais pas détailler ici, mais il y a des choses
15:42 notamment au niveau
15:44 de la gestion des secrets,
15:46 la gestion des droits, où traditionnellement
15:48 sur des réseaux on-prem, il y a de l'AOB.
15:50 Donc on a tendance à moins sécuriser
15:52 les secrets, dès qu'on bascule des secrets
15:54 dans des robots, sachant que les contrôles
15:56 pleines qu'on attaque sont
15:58 publics, il y a quand même des risques assez particuliers
16:00 mais qui sont les mêmes que le cloud, ce n'est pas lié
16:02 particulièrement au SDN. Et nous, on voit des choses
16:04 assez rigolotes comme ça.
16:06 En fait, c'est comme si tu disais
16:08 globalement, quand tu
16:10 sécurises ou pas, quand tu veux faire
16:12 des infras qui sont par exemple
16:14 PCI DSS,
16:16 tout connement, des fois c'est plus
16:18 simple d'aller chercher un cloud provider qui a la certification
16:20 que tu n'as pas, que tu n'as pas envie de faire
16:22 et c'est beaucoup plus simple pour toi de le faire.
16:24 Par exemple, tu veux faire un...
16:26 Tu prends un cloudfair qui a sa certification,
16:28 au lieu de le mettre en interne pour toi, pour toutes tes
16:30 cartes, etc., tu vas prendre un fournisseur
16:32 qui le fait pour toi. Donc on va dire que
16:34 dans certains cas, c'est beaucoup plus simple d'aller chercher
16:36 à l'extérieur que de le faire
16:38 on-prem. Par contre,
16:40 tu regardes le cas, la présentation
16:42 de Romain de Créteau
16:44 qui montrait bien qu'aujourd'hui,
16:46 pour chaque société,
16:48 les besoins que tu peux acheter
16:50 sur le marché en tant que produits étrangers,
16:52 ça ne marchera pas pour eux. Donc du coup, ils vont devoir
16:54 le construire et du coup, le
16:56 retour d'expérience est peut-être très court,
16:58 un an, deux ans. Donc en fait, aujourd'hui, tu ne
17:00 peux pas savoir encore aujourd'hui si c'est vraiment
17:02 encore le cas, c'est-à-dire que tu es quand même obligé
17:04 de le faire en interne. Donc je dirais
17:06 transférer des fois
17:08 certaines fonctions à l'extérieur
17:10 du SD quelque chose,
17:12 c'est intéressant pour gagner du temps
17:14 pour ce qu'on appelle ton "time to market"
17:16 en fait. Mais après, c'est encore
17:18 je pense que
17:20 moi j'estime que ça va
17:22 les on-prem cloud
17:24 aujourd'hui, on ne peut pas être
17:26 à 100% d'un côté et 100% de l'autre
17:28 quand il y a une infra qui devient conséquente.
17:30 Petite infra, oui, mais grosse infra,
17:32 c'est compliqué.
17:34 Alors, est-ce qu'il y a des
17:36 bonnes implémentations SDN
17:38 open source ?
17:40 Alors désolé, je ne sais pas du tout,
17:46 peut-être la nôtre, mais elle n'est pas encore open source.
17:48 On a publié la semaine dernière AFK,
17:50 je vous laisserai regarder.
17:52 Il n'y a pas de contrôleur SDN, celui-là
17:54 on ne l'a pas encore publié, mais vous verrez
17:56 la partie automatisation, première fois
17:58 qu'on publie ce genre de choses.
18:00 Et peut-être dans l'année, un peu plus tard,
18:02 on verra si on arrive à publier la partie
18:04 SDN API. Je ne prétends pas qu'on ait
18:06 comparé beaucoup de solutions, je ne suis même
18:08 pas sûr qu'il y en ait vraiment beaucoup.
18:10 Donc je ne peux pas répondre plus.
18:12 Pour avoir dans le passé, essayez de faire un inventaire
18:20 de trucs, non, il n'y en a pas en fait.
18:22 Tu as des projets, mais ils sont tous pétés.
18:24 Ok.
18:28 Alors on va passer aux
18:30 questions un peu plus
18:32 basiques. Quand le
18:34 Firewall est tenu par une entreprise US,
18:36 est-ce que le client est conscient
18:38 que ses flux de données sont
18:40 potentiellement soumis à un Cloud Act
18:42 ou des choses comme ça ?
18:44 Ok.
18:50 On va laisser
18:52 Cloudflare commencer.
19:00 Moi, je ne fais pas du Cloud Act,
19:02 je ne fais pas du legal, tu vois.
19:04 J'aurais du mal à répondre à cette question.
19:06 Pour avoir travaillé dessus,
19:10 je dirais
19:12 à la défense des boîtes US que quand
19:14 le GDPR est sorti,
19:16 je sais que les boîtes US
19:18 sont très fortement travaillées dessus
19:20 et avec beaucoup de sérieux parce qu'elles
19:22 ont extrêmement peur de la régulation
19:24 européenne et de perdre du
19:26 business en Europe. Et j'ai même
19:28 l'impression que les boîtes US, en tout cas,
19:30 ont mieux travaillé sur le GDPR
19:32 que peut-être même des boîtes
19:34 européennes, mais je ne voudrais pas trop mouiller là-dessus.
19:36 Est-ce que le Firewall
19:40 est soumis au Cloud Act, les logs ?
19:42 En fait, je ne sais pas.
19:44 Je ne travaille pas sur les requêtes
19:46 légales au niveau de Cloudflare,
19:48 donc j'aurais vraiment du mal à dire
19:50 les tenants et les aboutissants
19:54 de ça. Je sais qu'on a une équipe Legal
19:56 qui est extrêmement bien fournie
19:58 en lawyers dans tous les sens
20:00 et qui serait capable de répondre
20:02 longuement à cette question, mais certainement pas moi.
20:04 En fait, il a bien couvert
20:08 le sujet.
20:10 Moi, j'ai eu le sujet
20:12 quand Benjamin
20:14 et moi, on a fondé à Corus, on était une boîte française
20:16 et donc du coup, on avait les logs de tout, etc.
20:18 On était
20:20 uniquement à l'heure européenne, on va dire.
20:22 On a fusionné avec une boîte américaine
20:24 qui s'appelait Zone de Gris.
20:26 En fait, on avait 50% de la boîte française
20:28 et 50% en US.
20:30 Qu'est-ce qui s'applique ?
20:32 On a gentiment parlé à nos avocats
20:36 et on leur a dit que si il se passait un truc,
20:38 ils allaient en première ligne.
20:40 Et puis, on a fait best effort,
20:42 parce qu'on ne saurait pas faire.
20:44 Par contre, on a très rapidement
20:46 s'est fait racheter pour une boîte américaine
20:48 où là, on nous a dit
20:50 que de toute façon, ce n'est plus votre ressort,
20:52 c'est le log de Google. Et globalement,
20:54 quand la loi anti-Google est sortie en Europe,
20:56 parce que c'était une loi anti-Google, clairement,
20:58 sur la partie des logs, etc.
21:00 Là, c'est des équipes de 15-20 personnes
21:02 qui bossent tout le temps dessus
21:04 et on n'a pas le droit de communiquer sur rien.
21:06 Donc c'est difficile de répondre à cette question
21:08 mais je dirais que sur un cas d'un firewall,
21:10 si c'est une VM, en fait,
21:12 le constructeur fait une licence,
21:14 ta licence n'est pas sous le summeux cloud act.
21:16 Mais par exemple, si tu as du trafic
21:18 qui est chez un fournisseur tiers en SaaS,
21:20 je dirais que techniquement,
21:22 aujourd'hui, il y a quand même une zone de...
21:24 C'est compliqué.
21:26 Personne ne peut répondre comme ça, honnêtement.
21:28 Ok. Dernière question
21:32 avant de passer aux questions de la salle.
21:34 Est-ce que la virtualisation
21:36 au réseau, c'est écologique ?
21:38 Elle inspire cette question.
21:48 Oui, bien sûr.
21:50 Non mais je reprends mon exemple des VM
21:56 qui ont pop en une milliseconde.
21:58 L'avantage de ça, c'est que si ta workload
22:00 que tu fais tourner,
22:02 elle te prend 10 millisecondes
22:04 de "workload utile",
22:06 ça veut dire que l'overhead est court.
22:08 Le fait d'avoir la virtue du réseau
22:10 à l'exécution,
22:12 n'impacte pas plus.
22:14 En vrai,
22:16 on est quand même au pouillème.
22:18 Ce qu'on a évité, c'est un call dans une DB,
22:20 etc.
22:22 De toute façon, tout ça tourne déjà,
22:24 c'est matérialisé. Est-ce qu'on économise quoi que ce soit ?
22:26 Non, on est juste meilleur pour les gens,
22:28 pour l'expérience utilisateur.
22:30 Est-ce qu'il y a des choses
22:32 écologiquement à éviter ?
22:34 Franchement, je pense que si tu prends un exemple
22:36 assez simple,
22:38 tu prends du firewall
22:42 virtualisé,
22:44 concrètement,
22:46 je pense que là, on peut parler
22:48 vraiment d'écologie.
22:50 Une bas-basse à 100 GB
22:52 ou à 1 fois 100 GB,
22:54 combien de firewalls elle peut faire tourner ?
22:56 Forcément, si tu mets en face
22:58 même du 1U pas cher,
23:00 c'est évident que la VM gagne.
23:02 Oui, mais ça dépend de son implème.
23:04 Si tu as la bonne implème
23:06 avec les bons accélérateurs sur la VM,
23:08 oui, tu vas avoir des perfs
23:10 qui font que tu vas amortir le truc.
23:12 Si c'est pour avoir un truc vraiment que soft
23:14 avec des perfs bien pourris et que tu dois
23:16 faire x10 dessus pour amortir
23:18 ta charge,
23:20 tu perds un peu.
23:22 Après, il y a aussi une tendance aujourd'hui
23:24 dans la virtualisation des services réseau
23:26 qui est de faire des VNF ou des trucs dans des containers
23:28 avec, en fait,
23:30 plus du tout de mutualisation
23:32 des flux et des traitements.
23:34 Et ça, très concrètement,
23:36 encore une fois, c'est potentiellement
23:40 un détail, mais c'est à la fois
23:42 pas optimisé, d'un point de vue d'ingénierie,
23:44 c'est quand même assez honteux.
23:46 C'est clog.
23:48 C'est clog.
23:50 Et donc, pour répondre à ta question,
23:52 ça, clairement, c'est pas du tout écologique.
23:54 Vaut mieux un équipement
23:56 qui mutualise très bien le traitement des flux
23:58 à très haute performance
24:00 et là, t'es bon.
24:02 Le plus gros problème
24:06 que moi, j'ai vécu,
24:08 c'est quand tu veux
24:10 virer un firewall avec un CPU poussif
24:12 des années twist
24:14 et que les constructeurs
24:16 n'ont pas changé encore,
24:18 tu te dis "super, je vais prendre un gros serveur
24:20 avec plein de CPU ou autre", sauf qu'il va te limiter
24:22 ce nombre de coeurs, il va changer sa licence
24:24 quand AMD sort un nouveau CPU,
24:26 il te dit "ah non, on te compte fait CPU, CPU,
24:28 mais c'est au nombre de VCPU, donc du coup, etc."
24:30 Et en fait, tu te retrouves, au final,
24:32 il te fait un prix qui est beaucoup plus intéressant
24:34 sur de l'hardware parce qu'à un moment donné,
24:36 par rapport à la bourse, la bourse fait
24:38 "ah, en fait, ils ont pas besoin de faire de l'hardware, trop de licence,
24:40 faut qu'ils vendent plus de hardware,
24:42 du coup, ils vont faire des remises qui vont aller
24:44 d'un côté ou de l'autre." Donc aujourd'hui,
24:46 je dirais que les constructeurs sont
24:48 contrefiches complètement d'écologie, même s'ils vont te dire
24:50 "ouais, super, je fais moins de watts, etc."
24:52 mais ils en ont rien à foutre
24:54 et le principe, c'est que par rapport à la bourse,
24:56 ils vont régler plus ou moins
24:58 leurs remises. Donc techniquement, je dirais
25:00 oui,
25:02 on va dire, mais clairement, l'industrie n'en a rien à foutre.
25:04 Voilà.
25:06 Moi,
25:08 le coût principal
25:10 chez un fournisseur de cloud,
25:12 en tout cas, le premier coût
25:14 après les employés,
25:16 c'est les coûts de data center
25:18 et en particulier, tout ce qui est
25:20 électricité, puissance électrique.
25:22 C'est le coût numéro un.
25:24 Donc les fournisseurs de cloud,
25:26 ils ont un intérêt énorme
25:28 à essayer d'optimiser l'usage
25:30 de leur machine.
25:32 Nous, on a toute une équipe
25:34 performance qui ne fait que ça.
25:36 Qui regarde la performance software,
25:38 le tour, on a des serveurs qui tournent
25:40 à 60-70% CPU
25:42 en permanence.
25:44 Donc quelque part, on peut dire que c'est probablement plus
25:46 optimisé que du on-prem ou comme
25:48 disait Raphaël, on va acheter des machines surpuissantes
25:50 et les utiliser à 10%.
25:52 Donc, avec cet argument-là,
25:54 on peut facilement dire "oui, c'est écologique".
25:56 Bon, après, est-ce que c'est un argument de vente ? Est-ce que c'est vraiment écologique ?
25:58 Je ne sais pas.
26:00 En tout cas, d'expérience,
26:02 je sais que les fournisseurs de cloud
26:04 font énormément d'efforts sur
26:06 la performance électrique.
26:08 Le driver,
26:10 c'est la mutualisation.
26:12 La mutualisation est un
26:14 enabler de la mutualisation.
26:16 Donc, en fait,
26:18 en on-prem, on fait bien de la mutualisation aussi.
26:20 Sur du réseau, sur des machines,
26:22 on peut empiler des choses,
26:24 que ce soit des routers ou sur des serveurs.
26:26 Nous, on fait ces calculs en interne,
26:28 on ne met pas les chiffres sous la main.
26:30 Mais oui, évidemment, virtualiser, mutualiser,
26:32 tu réduis ton empreinte carbone
26:34 en on-prem aussi, on sait le calculer.
26:36 OK, eh bien merci.
26:40 On va passer aux questions de la salle.
26:42 Est-ce que quelqu'un a une question ?
26:44 Hop là ! Ne bougez pas, j'arrive.
26:50 Je vous préviens, c'est un troll aussi.
26:52 Qu'est-ce qui vous arrive à autant parler de Firewall en 2023 ?
26:54 Il me semblait que c'était un composant du passé.
26:56 Alors, en fait, nous, on n'en a plus.
27:08 Donc, je ne sais pas trop de quoi tu parles, Mathieu.
27:10 C'est pas un problème.
27:12 C'est un problème.
27:14 C'est un problème.
27:16 C'est un problème.
27:18 C'est un problème.
27:20 De toute façon, on est tous sur Double Lancer.
27:22 Donc le Firewall, c'est juste pour la hot-off-band.
27:24 C'est vrai, on en a sur la hot-off-band.
27:28 Personnellement, c'est un de nos produits stars.
27:32 Donc, je trouve que le Firewall est toujours là.
27:34 Est-ce qu'il y a une autre question ?
27:42 Je vois là.
27:44 C'est pas là.
27:46 On entend beaucoup parler de SD-WAN,
27:52 mais souvent pour remplacer des liens MPLS,
27:54 parce qu'on dit "SD-WAN, c'est moins cher, blablabla".
27:56 La raison, ce n'est pas juste
28:00 certains qui se gavent,
28:02 ou d'autres qui préfèrent mettre des FTTH
28:04 pour faire de la merde, plutôt ?
28:06 Le sujet,
28:10 quand Pierre-Yves
28:12 a fait sa présentation,
28:14 c'est qu'au bout d'un moment,
28:16 il y a de l'infra dessous.
28:18 Il y a des mecs qui construisent de l'infra,
28:20 et qui se disent "3 liens, c'est pas bon,
28:22 4 liens, c'est pas bon, 5 liens, ça commence à être bien,
28:24 des fois il en faut 6".
28:26 Donc quand tu achètes du MPLS,
28:28 si la personne a fait bien son taf,
28:30 elle va te garantir
28:32 la CAPA que tu as commandé
28:34 en sécurité à 100%.
28:36 C'est-à-dire que quand tu vas commander
28:38 un gig en APAC,
28:40 si ça passe par 5 POP,
28:42 il va y avoir 5 fois 4 ou 5 fois 5 liens
28:44 qu'il doit avoir pour ramener ton trafic.
28:46 Donc le prix du MPLS
28:48 ou de ces réseaux privés,
28:50 il a un vrai coût, parce qu'il y a une vraie
28:52 ingénierie derrière, et ça coûte vraiment beaucoup d'argent.
28:54 Donc je ne dirais pas que...
28:56 Bon, après, ça dépend de qui tu prends, il y en a qui vont se gaver,
28:58 et il y en a qui... Pour moi,
29:00 c'est un mauvais coupable, le mec MPLS
29:02 avec ses prix élevés, parce qu'il y a
29:04 de l'ingénierie derrière, et nous,
29:06 je pensais exactement la même chose que toi,
29:08 que je construise l'APAC, et que je demande
29:10 à Pierre-Yves de construire l'APAC, il la construit tout seul,
29:12 mais globalement, en fait,
29:14 pendant 2 ans, c'était du boulot, et c'est
29:16 beaucoup d'ingé, et c'est des liens que tu commandes, etc.
29:18 Donc,
29:20 dire que c'est remplacer le MPLS
29:22 parce que c'est cher,
29:24 c'est pas le même produit.
29:26 Tu as vu la présentation de Robin Chetavant,
29:28 pour pouvoir
29:30 faire ça, il y a quand même
29:32 une ingénierie derrière, en plus,
29:34 par rapport aux liens de transit qu'ils achètent, ils vont augmenter la carte-pain, etc.
29:36 Et comment va se gérer
29:38 la qualité ? Est-ce que ça va être la même, pas la même ?
29:40 Voilà, donc du coup, ils ont dû mettre des coûts,
29:42 est-ce que je vais passer par là, par là, etc.
29:44 Donc, je dirais, c'est 2 choses différentes.
29:46 Si tu es une banque, et tu veux quelque chose
29:48 qui soit 100% de la même
29:50 qualité tout le temps,
29:52 tu vas prendre ce MPLS, tu vas prendre peut-être 10 mecs ou 15 mecs,
29:54 mais tu vas être quasiment, entre guillemets,
29:56 quasiment sûr. Et là, tu as l'ESLD qui s'applique
29:58 sur le lien MPLS,
30:00 parce que du coup, c'est pas de l'infra que tu achètes,
30:02 c'est le lien, donc le mec, il le fait. Bon, ça va pas que
30:04 si tu perds des millions, t'en fous du MPLS,
30:06 du SLD, parce que le SLD, c'est basé sur
30:08 le pourcentage du prix de ta ligne. Donc,
30:10 tu payes une ligne de 10 000 balles, mais t'as peut-être 2 millions, le mec, il te dit "Tiens, voilà 10 000."
30:12 "Super, t'es content, mais tu vas rien faire avec, quoi."
30:14 Mais globalement, je dirais,
30:16 c'est un mauvais coupable,
30:18 le coût du MPLS
30:20 que les gens passent sur l'SD-WAN, c'est parce que
30:22 du coup, c'est pas le même usage.
30:24 Oui, mais, effectivement,
30:32 je comprends ce que tu dis, par exemple,
30:34 sur l'APAC, etc., mais parlons
30:36 sur notre marché, la France.
30:38 En France,
30:40 clairement, un lien MPLS
30:42 ou un lien normal, ça devrait pas forcément coûter plus cher.
30:44 Donc, c'est souvent,
30:46 il peut y avoir de l'ingénierie, tout ça,
30:48 mais c'est quand même un faux problème.
30:50 Alors, non,
30:52 le problème, c'est que, c'est un peu
30:54 le sujet de, plus ou moins,
30:56 de la table ronde, c'est que globalement, les gens,
30:58 ils ont plus de compétences en interne.
31:00 Les mecs, ils vont te dire, "OK, on va faire de l'EJRP
31:02 sur notre backbone." Ça existe encore, des mecs
31:04 qui font ça, quoi, tu vois. Donc, le problème qu'il y a,
31:06 c'est que tu as des gens qui n'ont pas la compétence
31:08 et acquérir cette compétence,
31:10 c'est plus cher que d'acheter des liens super chers,
31:12 en fait. Donc, tu arrives
31:14 des fois sur des gars, tu te dis, "Mais attends,
31:16 les mecs, ça sent le formol, cette boîte." Oui, ça sent le formol
31:18 parce que les mecs, en fait, ils en foutent, en fait.
31:20 C'est pas leur but. Donc, embaucher 5-1G
31:22 réseau, c'est pas leur besoin.
31:24 Leur besoin, c'est que ça marche
31:26 et que voilà. Donc, en fait, toi,
31:28 t'es juste pas le bon client de ce produit-là, en fait.
31:30 C'est parce que, du coup, t'as la compétence,
31:32 tu sais le faire, t'en as rien à foutre.
31:34 Et il ne faut pas oublier un truc,
31:36 globalement,
31:38 dans le métier de l'IT en général,
31:40 c'est le software qui crée la valeur.
31:42 Si, effectivement,
31:44 ton besoin de SD-WAN,
31:46 il est, on va dire,
31:48 un peu simple, basique,
31:50 et que tu le compares à
31:52 2 MPLS avec une équipe pour l'opérer,
31:54 ok, tu vas peut-être
31:56 te dire que
31:58 la rationalité des coûts, etc.,
32:00 t'amène vers "je vais faire moi-même ce que je sais faire".
32:02 Très bien. Mais si,
32:04 derrière, dans le SD-WAN, ce que tu veux
32:06 à l'exploiter, c'est des services qui s'ajoutent
32:08 ensuite. C'est ce genre de choses.
32:10 Mais c'est pas tes 10 personnes qui vont
32:12 gérer ton parc de liens.
32:14 En fait, c'est aussi les équipes de développeurs
32:16 qui vont s'ajouter pour développer les solutions,
32:18 puis les opérer.
32:20 Et puis, on parle d'une solution, puis peut-être
32:22 une deuxième fonctionnalité, une troisième, etc.
32:24 Et à la fin, ça dépend de ce que tu consommes.
32:26 Donc, ta question est légitime.
32:28 Des fois, tu peux vouloir faire
32:30 les choses toi-même, mais encore une fois,
32:32 ça dépend de la valeur de ce que tu tires de ça.
32:34 Et si tu veux tirer
32:36 beaucoup de valeur par beaucoup de services,
32:38 là, pour le coup,
32:40 peut-être que si tu fais toi-même, ça va te coûter
32:42 très très cher. Et il y a un time-to-market
32:44 aussi, c'est-à-dire que tu pars de zéro,
32:46 potentiellement,
32:48 t'en as pour des années à aller développer ton service.
32:50 Je me fais l'avocat
32:52 de Cloudflare, du coup.
32:54 Si tu veux
32:56 tirer parti des services que fait Cloudflare
32:58 dans l'accessibilité
33:00 au travers de leur réseau,
33:02 aujourd'hui, là, t'es parti pour une petite mission
33:04 quand même, à la fois
33:06 sur les connectivités, etc.,
33:08 à la fois sur les services.
33:10 Donc, c'est un vrai enjeu.
33:12 Maintenant, si ton besoin est effectivement très basique,
33:14 bon, pourquoi pas ?
33:18 Je pense que
33:20 comme tu disais, je pense que les gens
33:22 qui cherchent à migrer sur SD-WAN, c'est surtout
33:24 pour la partie logicielle. Aujourd'hui,
33:26 tu as, je ne sais pas, imagine un Starbucks
33:28 qui a besoin de 10 000 liens
33:30 dans leur site
33:32 et aujourd'hui, si tu
33:34 vas chez un Sprint ou un Verizon,
33:36 ils vont te...
33:38 certainement, ils vont te livrer tes 10 000 liens
33:40 MPLS, il n'y a pas de problème, mais ils vont te filer aucun
33:42 logiciel par-dessus, que ce soit
33:44 pour déployer, que ce soit pour monitorer.
33:46 Il n'y a rien, je veux dire, ils ne savent pas faire,
33:48 ce n'est pas leur métier, c'est des telcos à l'ancienne.
33:50 Donc, aujourd'hui, les gens, ils vont aller
33:52 acheter du SD-WAN, beaucoup, non pas parce
33:54 qu'ils payent très cher chez leur fournisseur actuel,
33:56 c'est souvent pas le souci
33:58 principal, on parle souvent de boîtes qui ont
34:00 énormément d'argent pour ça,
34:02 mais c'est parce qu'ils ont des vrais besoins
34:04 de simplicité, de déploiement
34:06 et de facilité
34:08 logicielle, des API,
34:10 toute cette sorte de choses que
34:12 les fournisseurs habituels
34:14 ne sont pas capables de fournir aujourd'hui,
34:16 ne veulent pas fournir.
34:18 Est-ce qu'il y a d'autres questions ?
34:27 Quelqu'un a faim.
34:31 Une petite dernière,
34:35 pour ou contre
34:37 le firewalling
34:39 dans le cloud en layer
34:41 2, 3,
34:43 ou layer 3 ?
34:45 Je sais que chez Zeskeler,
34:49 il y a des trucs un peu sales,
34:51 il y a des choses qui se font.
34:53 Pour ou contre ?
34:56 Moi je dis pour.
34:58 Pour la résilience,
35:03 les fournisseurs qui vont monter
35:05 d'infra sur plusieurs continents ou autres
35:07 sont 100 fois meilleurs tout le temps.
35:11 Ok, c'était la dernière question
35:13 un peu trollesque.
35:15 Je pense qu'on a fait le tour,
35:17 à moins qu'une dernière main se lève.
35:19 Avant de passer au beer event,
35:28 deux choses.
35:32 La première,
35:34 c'est qu'on va remercier nos sponsors.
35:36 Netskout, OpenGear,
35:38 Brenax, Celeste,
35:40 Hello ici, Partek.
35:42 Et la deuxième, c'était juste pour dire
35:44 que je vais pour la première fois
35:46 de ma vie être président d'une vraie association
35:48 qu'on est en train de créer
35:50 qui s'appelle Makers Against Mines
35:52 et qui consiste à créer des petits robots
35:54 pour faire du déménage en Ukraine.
35:56 Et je ferai une annonce
35:58 sur la mailing list bientôt
36:00 avec des appels aux dons,
36:02 aux compétences,
36:04 et choses comme ça.
36:06 Vous serez invité à participer.
36:08 Voilà.
36:10 Merci beaucoup.
36:12 (Applaudissements)