Tout le monde le sait et le dit, l'informatique c'est un gouffre énergétique.
Rends-toi compte, cela représente 4,7% de la consommation totale d'électricité de la planète.
Bon, soyons sérieux, le numérique n'est pas une industrie qui pèse le plus sur le changement climatique,
mais c'est pas pour ça qu'on doit pas faire d'efforts.
Le cloud, donc les data centers, sont de plus en plus présents et ils présentent un enjeu majeur.
Ils consomment des matières premières, des métaurars, de l'énergie, de l'eau et j'en passe et ils prennent de la place.
C'est donc un des enjeux pour les entreprises comme Skaalway.
Bienvenue sur Radio DevOps, la balade aux diffusions des compagnons du DevOps.
Si c'est la première fois que tu nous écoutes, abonne-toi pour ne pas rater les futurs épisodes.
C'est parti !
Bienvenue à toi chers compagnons dans ce scène d'épisode d'en appartez l'émission où je montre tiens avec un invité sur un sujet particulier.
Aujourd'hui, on ne va pas parler directement d'écologie mais d'ARM.
Il faut savoir que l'ARM consomme à priori moins de place et moins d'énergie que l'architecture AMD64 qui fait la majorité des serveurs du cloud.
Mais on va justement en parler dans l'interview.
Si tu te poses des questions sur la consommation énergétique que j'annonçais dans l'introduction, j'ai aussi mis un lien en description.
Comme d'habitude, la description est blindée de lien.
Alors aujourd'hui, je le plaisir de recevoir Sébastien Lutringé, qui est, comme il l'écrit lui-même sur LinkedIn,
directeur de la R&D chez SkaLway, développeur et contributeur Arch Linux, bidouilleur de logiciels libres, mais surtout passionné de technologiques.
Bonjour Sébastien et bienvenue dans le podcast. Est-ce que tu peux te présenter en quelques mots ?
Bonjour Christophe. Merci de m'accueillir dans le podcast.
Tu m'as déjà extrêmement bien présenté avec ces quelques lignes volées de LinkedIn, donc je n'ai pas grand chose à rajouter. Tout est dedans quasiment.
Bon, si ton LinkedIn est à jour, alors c'est parfait.
Alors je vais te poser quelques questions rituelles que je pose à tous mes invités. Ça permet de se mettre en marche.
La première question, c'est quelle est ta définition à toi du DevOps ?
Pour moi, le DevOps, c'est quelque part quelque chose qui permet de réconcilier le développement et l'opération, le build and run d'une solution.
Moi, j'entrevois ça plus comme une façon, en tout cas, un ensemble de principes qu'on va mettre en place pour arriver à avoir une continuité
et faire en sorte que le développement logiciel intègre les opérations et que les opérations quelque part soient connectées avec le développement.
J'ai envie de dire, moi, l'analogique chérée, quand je parle de ça, c'est la formule 1, prenez l'espoir automobile.
Le pilote, c'est quelqu'un qui opère la voiture et les mécaniciens sont ceux qui la construisent et la modifient.
Il faut que la communication entre le pilote qui a besoin et que la voiture répond à ce qu'elle est lui, ça s'intègre dans la conception.
Donc le DevOps, c'est l'ensemble des pratiques quelque part qui te permet de faire communiquer les devs et les ops.
Est-ce que j'ai aimé ?
C'est très bien.
Et du coup, comment toi, tu as rencontré le DevOps ?
Quand est-ce que j'ai rencontré le DevOps ?
Ça date un peu, parce que c'est un courant qui a émergé, je dirais, à la fin des années 2010.
Je me souviens que j'étais chez SmartVogue à l'époque.
C'est arrivé pour arriver à faire travailler ensemble les équipes d'opération, qui étaient recevées les livrables des équipes de développement.
Et d'arriver à mettre en place les premiers CI-CD qui permettaient de faire en sorte que le développeur puisse avoir quelque chose qui teste, qui soit très proche de ce qu'on allait avoir en production.
Je l'ai rencontré un petit peu comme des bonnes pratiques, mais ça évoluait la définition même de DevOps, puisque c'était en construction.
Et les outils, aujourd'hui, ce qu'on en perçoit avec tout ce qu'est la chaîne de build automatisé, à l'époque, c'était vraiment d'essayer de trouver des solutions pragmatiques entre les équipes de devs et de run dans la boîte où j'étais.
Du coup, tu l'as rencontré très tôt dans l'émergence du DevOps, en tout cas dans la formalisation du nom.
C'était un artifice de mémoire qui permettait, quand on s'adressait à un développeur ou à un mec de run, de les faire travailler dans la même équipe.
C'était pas les gens qui étaient des DevOps, c'était vraiment les équipes où on constituait des équipes un peu mixtes.
Nous, c'était notre approche où on allait mettre des gens qui étaient devs et des gens qui étaient ops.
Et donc on avait une équipe qui, du coup, était capable d'elle-même d'avoir la partie devs et la partie ops au même endroit de mémoire.
Ok. Et qu'est-ce que ça a changé, finalement, dans ta vie, le DevOps ? Est-ce qu'il y a eu un avant et un après ou pas du tout ?
Je n'ai pas identifié ça comme étant quelque chose qui était à la croisée des chemins, un endroit où j'ai marqué ça avec le fer.
C'est quelque chose qui est très intéressant parce que ça a permis de faire changer pas mal les mentalités.
C'est surtout quelque chose qui permet de faire travailler des métiers qui avant étaient parfois antagonistes et ça les a quelque part rapprochés.
Et donc juste utiliser les bons termes et en faire quelque part quelque chose de natif.
Aujourd'hui, on n'a plus... Enfin moi, je ne ressens plus en tout cas quand je discute avec des gens.
Il y a l'ingénieur DevOps, encore ça c'est un sujet qu'on ne va pas lancer parce que ça ne fait pas consensus du tout.
Mais l'idée étant vraiment que ça permette de rapprocher ces deux univers comme la formule.
J'y vois plutôt quelque chose de l'ordre, de l'idée et ça n'a pas changé fondamentalement, Maddy, parce que c'est quelque chose qui me paraissait dès le départ très naturel.
On va pas lancer le débat, j'ai justement fait un tweet et un post link coding tout à l'heure à ce sujet-là précis.
Mais c'est pas grave pour rappeler le mouvement etc.
Mais bon, on a déjà assez traité ça dans le podcast, je pense que de toute façon on sera obligé d'y revenir régulièrement sur ce poste ou pas.
Moi je voudrais qu'on parle aujourd'hui des ARM, parce que début mars 2023, en fait, Scalway annonçait le retour des serveurs ARM à la demande avec la gamme Emperor Ultra.
Alors moi ça m'a étonné parce qu'en 2020-2021, Scalway annonçait justement qu'ils arrêtaient cette architecture.
Pourquoi est-ce que ça a été arrêté selon toi, selon les infos que tu as et qu'est-ce que aujourd'hui nouveau se retourne ?
Parce que finalement c'est encore très proche 2021-2023. Il y a un truc qui s'est passé je pense.
Alors oui, il y a quelque chose qui s'est passé et je vais un peu tricher pour répondre à ta question.
En fait Scalway n'a pas vraiment arrêté l'architecture ARM parce qu'on a maintenu une gamme d'architecture ARM sur une plateforme qui est celle d'Apple.
Donc il y a l'arrivée des Apples M1 à The Service qui sont arrivés en février 2021 qui ont permis justement de maintenir la gamme.
Mais par contre je sens ce qui a derrière ta question, c'est-à-dire que historiquement Scalway s'est construit autour d'un,
le nom Scalway qui était une division d'online au début, s'est construit effectivement autour d'une première offre qui était les C1.
C'était des petits socs ARM V7 qui permettait d'avoir quasiment un ordinateur ARM à basse consommation avec beaucoup de densité et donc à très faible coût.
Et ça c'était vraiment quelque chose de, moi à l'époque je le vivais comme client, je n'étais pas salarié de Scalway donc c'était quelque chose d'assez révolutionnaire en soi.
Et c'est vrai qu'avec le temps il y a eu une deuxième expérimentation avec des offres virtualisées, ça s'appelait le VCA en interne.
Et à la fois les VCA qui ont été arrêtés, si je ne dis pas de bestige je vérifie mes notes en parlant, elles ont été démarrées en juin 2017 c'est ça.
Et les VCA ont été arrêtés fin 2020, annonce d'arrêt début 2020 et fin d'arrêt effectivement fin 2020.
Il y a plein de choses à raconter sur ce sujet-là.
C'est le hardware qui a poussé Scalway à aller vers l'ARM pour des questions de densité et de prix, prix qui est construit par le fait que le prix du processeur était bas et que l'énergie que consommait ce processeur était plus raisonnable.
Et après avec la virtualisation avec les VCA toujours la même équation, vouloir aller sur cette architecture-là.
Sur les C1, il n'y a pas eu de problématique particulière en termes de hardware, c'est un matériel très fiable, un matériel qui a été fabriqué en France en partenariat avec des équities de Scalway.
C'est juste qu'entre le début de l'idée, c'est 2011, il y a des discussions en interne entre Harmo, Biringham et Grégoire de Turquene, qui sont les deux personnes qui feraient l'origine de ces machines.
Et le moment de la commercialisation en 2014, puis la fin de la commercialisation en 2021 pour les C1, le matériel était devenu un peu obsolète au sens de sa puissance et de ce que les gens pouvaient en attendre.
Néanmoins, il a fallu fermer le service avec des clients qui étaient encore dessus, sans être capable de proposer d'alternatives.
C'est pour ça que la question revient souvent de savoir pourquoi est-ce que maintenant on revient sur l'ARM.
Et par contre, les VCA, qui eux ont été lancés plus tard 2017, ont été fermés plus tôt parce qu'on a eu un problème de stabilité sur le processeur.
Des informations que j'ai eu en interne, il y avait une vraie croyance d'être capable de résoudre les problématiques techniques sur ces processeurs via des correctifs logiciels,
que ce soit Fiermoire ou dans le kernel Linux, qui n'a pas été le cas et ce qui a mené Skaelway à abandonner les processeurs Kavium, qui étaient derrière les VCA.
Ce qui se passe, c'est qu'on a un fabricant qui est en péricomputing, qui depuis quelques années a travaillé sur un processeur ARM.
Il y a eu un partenariat qui a été noué en 2020 avec Skaelway, donc il y a des discussions et on accompagne la société en péricomputing sur ces nouveaux processeurs.
On voit qu'ils arrivent à maturité et en milieu d'année dernière, ils sont arrivés à un stade de maturité,
où on s'est dit que c'est peut-être l'occasion de se relancer sur ce segment-là, parce que ça consomme moins,
parce qu'il y a aussi quelque chose qui change un peu la donne, c'est qu'Apple est arrivé sur le marché en amenant en quelque part,
en faisant de l'ARM, non pas ce que la plupart des gens en avaient l'habitude, c'est-à-dire une architecture pour les téléphones portables,
qui était efficient, elle consommait le rapport entre quelque part la capacité de calcul et l'énergie consommée par le processeur Hetebone,
mais là on a quelque chose, dans le cas des téléphones qui est limité à de la puissance, on va dire, petite,
alors que dans le monde des serveurs, dans le monde des data centers, souvent on va essayer de faire tourner des algorithmes,
des calculs qui sont plus, quelque part la recherche de la puissance et de la vitesse maximum de traitement est le point important,
et donc on a tendance sur du X86 à délaisser la sphénérothique, ça vaut bien quelque part, le calcul vaut bien l'énergie consommée,
et là l'intérêt c'est que la position marchée de ce processeur, c'est-à-dire on va aller permettre d'attaquer des calculs compliqués,
l'on puissant en essayant d'avoir l'efficacité énergétique, le rapport entre le calcul et la consommation d'énergie,
de ces fameuses plus ARM qui sont un peu plus intéressantes, et empêrer et sortir des processeurs aujourd'hui avec 128h,
3 GHz, garantie, chaque heure est capable de tourner à 3 GHz, et en fait quand on a vu ça sur le papier,
on s'est dit, il y a peut-être un truc à faire, nos clients ça peut les intéresser,
ça peut peut-être justement être un vecteur d'intérêt pour avoir quelque chose de plus raisonné en consommation énergétique,
pour rebondir un petit peu sur le contraint d'introduction.
Oui merci, du coup justement on va parler un peu de ces processeurs, en fait dans l'article de blog il est indiqué donc la gamme AMP2,
qui est la gamme du coup de serveur basé sur ces processeurs, elle n'est pas destinée aujourd'hui à la production,
elle bénéficie pas du niveau de support traditionnel, et donc c'est bien précisé, ne peut pas être adapté au change de travail critique.
Est-ce que ce disclaimer est fait parce que c'est encore une bêta en cours, et aussi la deuxième partie de la question,
c'est quel pourrait être les usages actuels de la gamme selon vous justement ?
Alors c'est un disclaimer, il faut savoir que c'est un discalway, moi je suis responsable de la R&D en partage en charge de ce qu'on appelle les Scalway Labs,
c'est une entité, une division de Scalway qui se charge justement de faire un petit peu des opérations sur des sujets un peu plus risqués,
donc on est là pour prendre un certain nombre de pari et de risques et d'essayer de les valider avec une approche plus expérimentale,
qu'une approche produit classique, et ce disclaimer il est sain au sens où on a essayé d'aller au plus vite pour ramener cette innovation à nos clients
et en la validant de façon à ce que on fait passer des tests en laboratoire, on industrialise à minima la chose pour s'assurer d'avoir un SLO identique
à ce qu'on va faire avec les autres offres, donc ce qu'on ne met pas et ce qu'on dit c'est que la SLA effectivement n'est pas garantie,
comme on n'est pas sûr à 100% on ne veut pas mettre les gens en difficulté en leur disant écouter à les illes, les yeux fermés,
donc on n'annonce pas de SLA, en interne les SLO sont les mêmes, les équipes qui opèrent, les plateformes sont les mêmes,
la stack technique et logicielle dessus sont les mêmes et on est intégré avec les plateformes de production,
mais pour des questions d'expérimentation, de savoir aussi comment est-ce qu'on construit ces offres-là,
on a préféré prendre un chemin plus rapide, ça permet de moins se poser de questions, ça permet de délivrer de la valeur à nos clients plus rapidement,
c'est quelque chose qu'on a voulu inaugurer avec ces processeurs en péril.
Aujourd'hui on a assez heureusement les clients qui ont un très bon taux d'utilisation,
c'est à dire qu'on a fait entre guillemets les 92% d'utilisation du matériel à mise à disposition,
il y a vendredi, et ce qui est assez intéressant dans les usages qu'on voit, assez étrangement,
il y a deux gros patterns qui se démarquent, il y en a un avec des petites VM,
ceux qui ont un cœur quelque part et qui cherchent en fait à avoir quelque chose d'assez, on pense, éficient économiquement,
par contre on a aussi beaucoup de clients qui prennent des machines avec beaucoup de cœur,
et ça c'est intéressant parce que dans les informations, alors chacun, il faut bien voir que ce que les gens font de leur machine,
c'est un peu comme la net neutralité pour les autres, les cloud providers ne souvient pas de moyens de savoir exactement ce que vous faites sur vos machines,
donc ce n'est que par le truchement d'un dialogue avec eux et des informations qui veulent bien nous partager,
qu'on peut avoir une idée de ce qu'ils font tourner sur leur machine.
Là on a un client qui fait tourner du traitement d'image, lui concrètement il fait tourner, alors ce n'est pas de l'AI,
c'est des filtres à lui, donc il fait de l'analyse d'image sur ces machines-là,
il nous a pris beaucoup et on voit que ça carbure, il en est très content pour l'instant.
On a un certain nombre d'autres usages assez classiques en informatique,
en réalité il n'y a pas l'air d'avoir quelque chose qui se dégage en tout cas pour l'instant,
on n'a pas de l'identification, d'une niche particulière, on voit que tout fonctionne,
on n'a pas d'incident de production, par exemple on peut dire on a ouvert le 15 mars,
on n'a pas eu un seul incident de production sur ces machines, ça c'est déjà très très positif
et les usages sont assez comparables de l'extérieur à l'ensemble des gammes qu'on a généralement pu reposer.
On ne va pas rentrer dans le détail des os et de l'architecture, je sais qu'on en avait par vie en prépare l'émission.
Est-ce que justement vous sentez une demande du marché,
ce que tu as dit c'était super intéressant parce que du coup je ne voyais pas une entreprise comme Skelweig et H-Fall
entre le logiciel et le hard, itérer comme ça comme une start-up, mais du coup vous le faites,
donc c'est super bien et est-ce que je repose la question,
est-ce que vous sentez une demande du marché pour ce type d'architecture
ou ce type de petit serveur économique et écologique ?
Alors oui, en fait il y a deux demandes, la question déjà c'est comment est-ce qu'on sent le marché,
c'est très compliqué de sentir le marché, on a une division produite qui est en train de préparer la suite,
c'est à dire qu'est-ce qu'on fait après qu'on a fait l'expérimentation et qu'on a des premiers retours matériels,
on sait que le matériel tourne, on a plusieurs architectures, ça fonctionne bien, on a fait des hypothèses,
il y a des points qui sont validés d'autres peut-être à retravailler, mais le sentiment marché
on avait avant même de lancer l'expérimentation interrogée, on s'était déjà rendu compte que nos anciens clients,
ceux de la base ARM et qui voulaient le retour de l'ARM, étaient déjà très demandeurs sur ces sujets-là.
Ce qu'on a identifié c'est deux types de clients pour l'instant, ceux qui cherchent effectivement à utiliser le côté prix,
donc c'est des gens qui vont chercher à ce que le fait que quelque part le kilowater a un coût
et que la consommation en kilowater du processeur est limitée fait que si le cloud provider joue au jeu,
il va réimpacter cette économie d'énergie dans son coût et dans la location quelque part du produit.
Le deuxième type de clients qu'on a vu, c'est des clients qui vont chercher à avoir beaucoup de traitement parallèle,
c'est-à-dire qu'une des forces des processeurs d'amperi-computing, comme je disais, c'est que l'on peut avoir jusqu'à 128 threads,
sur 28 heures d'exécution, indépendant les uns des autres à 3 GHz en permanence.
La faible consommation énergétique du processeur permet en réalité de pas avoir ces problématiques qu'on peut retrouver
sur d'autres processeurs, de don-clocking, il y a la température qui est limitée globalement la dissipation thermique des processeurs
et accessoirement il n'y a pas de système de threading donc les problématiques de sécurité qu'on a pu voir avec des systèmes de timing entre les threads,
c'est des choses qui n'a pas non plus. Donc là pour l'instant ce qu'on nous voit en termes de demandes marchés c'est beaucoup.
J'ai besoin de faire du calcul parallélisé et donc là il y a de l'EA, il y a tout un tas de champs qui sont interrégés par cette capacité-là
et la capacité prix. J'ai pas encore identifié même si je pense que ça pourrait être quelque chose d'intéressant en termes de vertu,
c'est à dire le côté, on va pas dire vert mais ça coûte du coup moins cher mais ça coûte moins cher parce que ça consomme moins
et encore personne qui est venu me voir en disant j'ai vraiment envie de passer sur ARM parce que c'est bon pour la plan.
Je t'avouerais que personne qui est venu me dire ça. En tout cas nous on a fait en sorte de raconter, de se mettre dans une dynamique
où si quelqu'un veut faire ça, il sait que nous on est dans cette dynamique-là puisqu'on a placé pour l'instant cette expérimentation sur notre data center
de DC5 par 2 qui du coup c'est celui qui a le meilleur PUE de nos data centers et qui a un refroidissement qui consomme moins d'eau que le reste des data centers du marché.
Donc on a essayé pour cette expérimentation de mettre notre rack d'essai à l'endroit où ça pouvait permettre justement de favoriser cette volonté de prendre des décisions astuciuses pour notre avenir.
Merci c'est très clair. Je me demande si il ne va pas bientôt manquer de place dans ce data center-là parce qu'à force d'y mettre des trucs
en tout cas j'espère que si il me va manquer de place vous allez en construire un comme ça bientôt. Mais bon rassure-moi il y a encore un peu de place.
Pour te répondre à tout ça c'est marrant, j'en discute un petit peu avec Arnaud Futintant et ce qui m'expliquait c'est qu'au début ils avaient du mal à vendre le data center de DC5 parce que la technologie qui est utilisée
pour évaporation de l'eau pour refroidir l'air c'est quelque chose qui était à la fois les infestissements des sociétés qui rentrent dans un data center et qui y mettent du matériel c'est beaucoup d'argent.
Il faut faire ça en étant sûr que pour une raison qu'on ne maîtriserait pas le data center ne va pas se mettre à ne pas respecter ces normes de température
ou va quelque part mettre en difficulté le business pour lequel on va amener dedans. Il y avait une frilosité du fait de cette nouvelle technologie et c'est un peu comme tout quand ça commence
on voit qu'il y a des gens qui arrivent, on voit que ça fonctionne, on comprend c'est solide, ça tient, justement il y a un engouement. Effectivement DC5 se remplit bien, c'est pas encore plein.
Ça me rassure parce que nous ça fait partie de nos arguments auprès de certains de nos clients puisqu'on fait aussi de l'infogérance et on met nos serveurs sur DC5
donc ça me rassure de savoir qu'il y a encore plein de places pour deux serveurs. Il y a encore plein de salles qui ne sont pas construites.
Alors on doit ces serveurs ARM en partie à SqlWelabs, donc c'est toi qui a créé justement cette équipe, est-ce que tu peux nous en parler un petit peu plus de cette équipe, qu'est-ce qu'elle fait et c'est quoi finalement le rôle de SqlWelabs au sein de SqlWel?
Alors SqlWelabs c'est une division de recherche et développement de SqlWel, qui a pour mission un petit peu d'aller travailler sur des sujets à plusieurs niveaux de risque.
L'idée c'est d'avoir une agilité au niveau de la création d'équipe, on appelle ça en interne des équipages, des coups, qu'on mobilise sur des sujets qu'on a envie d'explorer.
L'idée c'est d'avoir quelque chose d'assez léger, un peu comme un conteneur dans l'univers de l'informatique qui nous permet d'aller constituer une équipe composée de personnes qui ont des compétences sur le sujet qu'on veut adresser
et d'explorer avec une méthodologie qui a adapté justement à l'exploration et au fait de pouvoir arrêter.
La chose la plus difficile c'est d'avoir renoncé effectivement à une exploration qu'on a lancée, surtout qu'on a envie que ça marche et d'être capable de se rater en disant bon ce sujet-là c'est peut-être pas pour maintenant, peut-être ça sera pour plus tard.
SqlWelabs c'est un peu moins d'une quinzaine de personnes aujourd'hui et on a pris le sujet des processeurs empérialitrats sous cet angle-là en se disant qu'on allait le prendre comme un sujet, on allait tester le matériel, vérifier que ça fonctionne, prendre des hypothèses
et avancer comme ça au fil de l'eau jusqu'à ce qu'on se mette dans une situation où soit on venait en faire une expérimentation publique et on partageait quelque part le résultat de ce qu'on avait fait plus largement
et on pouvait avoir des retours sur cette expérimentation, ce qu'on a décidé de faire et ce qui va nous permettre de quelque part de conclure sur un rapport de recherche de façon un peu plus concrète que si on était resté que dans un laboratoire.
Voilà.
Et ben merci, ça m'amène une autre question puisque vous êtes dans un mode recherche et développement, si votre recherche donne pas les résultats que vous voulez, si ça échoue pour vous et que ça ne sert pas du coup votre business, est-ce que vous avez envie de rendre vos recherches libres ?
Et donc, le mot échec qui est assez connoté négativement surtout en France est en réalité le chemin nécessaire à la découverte et à être capable d'amener quelque chose de nouveau ou de plus disruptif dans nos environnements.
Mais ce qu'il faut bien être conscient c'est que essayer ce n'est pas du temps perdu parce que souvent ce qui est mis en avant c'est que vous avez perdu votre nom.
Non, on n'a pas perdu notre temps parce que si on documente à la fin, si justement on est capable d'écrire pourquoi ça n'a pas marché, pourquoi nous n'avons pas été capables de faire quelque chose qui marche.
Des fois la problématique est simplement par la méthodologie, les prismes, les billets.
Donc documenter ça c'est aussi quelque chose qui est intéressant, qui peut inspirer d'autres personnes à être meilleure.
Et ta question c'est plus est-ce qu'on va le rendre libre ? Oui c'est l'objectif.
Pour l'instant on est... Alors c'est pas forcément facile de faire écrire des ingénieurs.
C'est pas... Donc la notion de... On a travaillé sur un sujet, publions-le, je pense que c'est très sain, c'est très vertueux.
Donc c'est quelque chose qu'on va essayer de faire. Ça fait partie très clairement de nos objectifs en interne.
Avec sur le monde deux phases, une diffusion interne puis une diffusion plus large après, sous licence libre idéalement.
Donc oui ça fait partie du plan très clairement de communiquer sur ce qu'on fait et ce qu'on a réussi ou pas d'ailleurs.
D'ailleurs ça me fait penser mais nous on fait aussi de la R&D, on demande d'écrire d'un pot innovation.
Je pense que tu connais écrire d'un pot innovation, que tu viens pour recherche.
Ça nous oblige nous à écrire des choses pour justement l'État.
Et je vois très bien ce que tu dis quand on n'a pas l'habitude. Alors moi je ne suis pas ingénieur mais je suis tech.
Écrire ce qu'on fait et le décrire pour des gens qui ne sont pas tech, c'est hyper dur mais c'est super intéressant.
Pour le coup ça t'oblige à te poser des questions je trouve.
Ça oblige à poser des questions et expliquer ce qu'on fait c'est une façon extrêmement puissante de s'obliger à être sûr qu'on est bien compris.
Je vois même en interne qu'on commence à travailler sur un sujet et quand on commence on a un système pour savoir si on avance dans le bon sens.
On a un système de black hole pour savoir si on arrête ou pas le projet.
Et donc au moment où ces points d'étapes sont déclenchés, il faut être capable de produire un explicatif, un tiers qui est pas au quotidien, dans le camboui.
Il faut vulgariser au sens note du terme l'endroit de la recherche et le rendant accessible pour que justement on se rende compte des gens qui ne sont pas dans l'expérience,
sont capables de dire oui ou non il faut continuer, oui ça a du sens de prendre du temps, de l'énergie, de l'argent à avancer sur ce sujet là.
Le moment où les équipes ont leur demande de faire ces présentations et ces documentations, c'est là où on voit quand on les fait, quand on les redit, quand on travaille avec eux,
c'est à dire que écrire expliqué, ça oblige à mettre de l'ordre dans sa pensée donc c'est très très salutaire.
Au-delà de la partie rébarbative des documents du créditien pour recherche, donc tu fais pas.
Oui oui oui c'était juste à parallèle, c'est pas exactement la même chose c'est sûr mais ça nous force à écrire.
Moi je me posais la question, ça fait longtemps que je m'en pose, est-ce que pour les équipes du data center ça fait une différence justement de gérer des serveurs AMD64 ou des serveurs RM ou pas du tout en fait ?
Non aucune, pour les gens qui sont dans les data centers, donc si on parle des artisans qui construisent les serveurs, la partie supply qui déplace les machines et qui les dépose dans les data centers,
les équipes d'essai qui s'occupent du refroidissement de l'induction électrique, des normes incendies, c'est un processeur différent, c'est très standardisé, ça fonctionne exactement pareil.
Je pense qu'ils ne savent que ce soit dans un GPU, un QPU, un GPU ou un GPU qui soit de l'ARM ou pas, aujourd'hui le formfactor est le même, c'est des U, il y a des grands constructeurs, c'est très semblable.
En tout cas il n'y a vraiment aucune problématique sur ces châssis là en interne, c'est standard, il n'y a vraiment rien de différent.
Du coup j'imagine que ça change quand même quelque chose au niveau logiciel, API et tout ce que vous faites à travers la console et des divers clients en fait.
Écoute, même pas, assez peu en réalité, on a eu un certain nombre de problèmes avec les BMC effectivement mais qui ne sont même pas liés si tu veux à l'ARM en soi,
le BMC a toujours été de l'ARM soit dit en passant depuis très longtemps même sur le Vistae 3.6, donc il y a assez peu de différenciations, ce qui va changer par contre c'est toutes les images d'installation,
les OS sont pas, en fait tous les binaire qui s'exécute sur ces machines là sont des binaire compilés pour de l'ARM 64, il faut que les fermes de logiciels soient disponibles,
des versions binaire, des dépôts, moi comme tu le sais par exemple on a mis un certain nombre d'OS à disposition sur ces machines,
donc je suis développeur Arch Linux, Arch Linux n'a pas de version officielle ARM de sa distribution et donc on n'a pas pu d'ailleurs proposer Arch Linux par défaut sur les AMUs,
c'est comme ça mais non globalement c'est assez similaire, ce qui n'est pas le cas par exemple tu vois de l'écosystème Apple,
c'est-à-dire qu'on parle des mac amens, comme je suis un moment où je suis utilisé ça pour te dire qu'il y avait quand même un peu d'ARM chez Skalway,
j'essayais de noyer un peu le poisson mais là pour le coup l'écosystème n'est pas du tout le même,
donc l'interconnexion et le travail qui a dû être fourni par Skalway au moment de la réalisation de la mise en date Ascendor de Mac Studio n'est pas la même histoire
puisque on parle d'un ordinateur qui a la base pour ce pour le bureau, qui n'est pas fait pour supporter des vibrations,
ou même qui a une façon d'appeler le courant quand on l'allume qui n'est pas la même du tout,
là on est sur quelque chose de, c'est des serveurs en péricomputing avec HPE, Gigabyte, ils font un travail remarquable pour avoir du matériel fonctionnel, classique,
donc cette partie industrialisation c'est assez bien passé, réellement.
C'est cool alors, si on parle un petit peu du design des rack serveurs dont à parler,
ça se passe comment le design avec votre partenaire qui s'occupe de quoi, raconte-moi un petit peu comment ça se passe.
Alors qu'est-ce qu'il s'appelle le rack design pour être pour ?
C'est le design d'un serveur, quel ram je vais mettre, combien de ram je vais mettre, combien de puces je vais mettre,
quelle carte mère je choisis, combien je mets de cartes réseaux etc.
Tu vois tout le design de ton rack complet, est-ce que c'est vous qui le faites,
est-ce que c'est Empéry qui le fait et vous fournit des rack tout fait, c'est ce genre de question.
Ok, ce qu'elle ouais on a le savoir-faire et la chance justement de pouvoir faire ça, nous-mêmes on va consulter,
on va avoir un certain nombre de fabricants qui vont proposer des processeurs, des cartes-mères, de la mémoire, des disques-nures,
et nous notre savoir-faire c'est de trouver les meilleures combinaisons,
ça c'est vraiment les équipes de ce qu'elles ont en interne qui font ça, d'être capable de les assembler,
quand je te dis on a des artisans qui assemblent les pièces détachées pour en faire un serveur,
en fonction j'ai envie de te dire de la maturité des fournisseurs,
des fois on peut être amené à acheter des choses très assemblées, d'autres qui le sont moins,
des problèmes dans le cas d'opérer si nous avons assemblé les processeurs sur une partie,
la rame c'est de la rame qu'on a écrite, c'est compatible d'ailleurs, c'est la même rame que sur 1096,
il n'y a pas de différence, donc le design au sens de la réflexion et du choix technique
qu'on fait par Scalway, le nombre de serveurs qu'on va mettre par baie,
ça c'est l'hére de la guerre, parce que de tous ces choix découlent le prix qu'on est capable d'offrir à nos clients,
plus on va avoir un design smart, bien conçu, bien léché,
plus on va être capable d'avoir des prix agressifs auprès de nos clients,
et aussi on parle d'un point qui me blesse, mais on est obligé par transparence de dire qu'on ne fait pas de la sela
parce qu'on est dans une dynamique d'expérimentation,
par contre quand tu mets des serveurs en data center, tu as plein de choix techniques,
comme le fait de savoir dans les data center tu as deux alimentations électriques,
tu as deux lignes électriques différents avec des circuits d'il-joint pour être capable de pallier
à une défaillance d'un circuit, nos serveurs sont double alimenté électriquement,
donc on va avoir un choix qui est d'avoir deux alimentations électriques avec deux lignes complètement séparées
sur chacun des serveurs qu'on met à disposition,
on va avoir la même chose au niveau du réseau avec deux alimentations réseaux,
deux inductions réseaux avec des switches séparées qui permettent justement de pallier à une défaillance du matériel,
au niveau du disque dur c'est pareil, au niveau des disques durs qui sont locaux,
alors on n'a pas activé les fonctionnalités locales sur les embs d'œufs,
mais c'était prévu pour pouvoir le faire, elles sont le faisées, on avait des disques avec du RED
qui nous permettait justement d'avoir de pallier à une défaillance matérielle
de façon à ce qu'on puisse remplacer ces disques à chaud sans que le client voie d'interruption.
Donc je te dis que la SLO est très proche de ce qu'on peut proposer par ailleurs,
on est dans un design qui se veut le plus proche de ce qu'on va proposer à nos clients
sur la version finale ou en tout cas ce qu'on en projette aujourd'hui de la version finale des offraignements chez SQL.
Ok, et du coup en termes de place et d'énergie consommée,
ces serveurs-là, ça a quel gain pour vous par rapport à des serveurs classiques ?
Ah ça c'est le côté un peu sympathique, il faut savoir que là on a fait des choix,
il y a plusieurs gammes de CPU chez Empere, nous on s'est arrêté sur des M12830,
c'est 128h3Ghz, c'est des processeurs avec la machine tout compris,
Z3N1U, ça c'est l'unité standard qu'on met en date à s'amplir,
sur un U on a 128h à 3Ghz et la consommation totale de la machine en pointe est inférieure à 300W,
à 353W par an, et du coup on est sur quelque chose d'extrairement,
déjà que tu t'en mets une dizaine, tu as un 3500W,
tu te rends compte assez rapidement que tu peux remplir ta baie avec une cinquantaine de U,
tu vas pouvoir densifier énormément, donc tu vas rentrer dans des problématiques,
qui sont des problématiques d'apportance, c'est-à-dire que dans les choses qu'il faut considérer en date à center,
c'est l'énergie, donc à la fois la consommation énergétique d'entrée,
mais aussi la dissipation de thermique, c'est un gros radiateur, un ordinateur,
qui est rentré, transformé en énergie thermique,
et donc la partie que ça soit entrée et sortie énergique, c'est un des premiers problèmes,
et quand on arrive à bien densifier, en ayant des bébés à plusieurs dizaines de kilowatt,
on se retrouve à avoir une problématique de portance déplanchée,
c'est-à-dire qu'il y a un date à center, c'est beaucoup de poids,
et donc on a une limitation à ce niveau-là au niveau de la portance,
donc ce que permet les processeurs, enfin, l'architecture ARM et les solutions d'empérée,
c'est d'arriver à densifier un maximum les emplacements en date à center et les bébés.
On a moins de baies vides que on peut voir traditionnellement.
Du coup, faut faire attention aux poids quand même, pas en bête trop,
parce que sinon, tu traverses ton plancher.
C'est ça, mais ça, c'est le savoir-faire des gens qui consorent les décès,
on a la chance en interne d'avoir les équipes de conception de décès avec son premier étage,
et qui s'assurent de tout ça.
Du coup, c'est des serveurs parfaits pour décès 5,
puisque comme justement, il n'y a pas de climatisation,
c'est l'endroit parfait pour les mettre par rapport à décès 3,
ou justement, vous allez les mettre à décès 3,
dans des salles qui sont déjà climatisées,
vu qu'il n'y a pas forcément besoin de les refroidir plus que ça.
Est-ce que justement, à l'avenir, dans les data centers,
si vous allez créer des data centers spécifiques,
ou vous n'êtes même pas encore posés ce genre de questions ?
C'est pas du sang refroidissement, il faut assurer une température,
il y a du refroidissement sur les processus à remperer,
c'est juste qu'ils arrivent à maintenir, ils consomment moins de chaleur,
et donc c'est plus facile quelque part de maintenir la température au sein de la salle.
Dans ta question, il n'y a pas d'ordinateur idéal,
c'est une avancée technologique qui nous permet, avec deux choix possibles,
soit on en met moins, généralement de chaleur, on consomme moins,
soit on en met plus, et on consomme mieux.
Donc les salles des data centers sont dimensionnées,
je ne sais plus, je ne me dis pas de bêtises,
mais ça permet de mettre plus de machines,
ça permet de faire plus de traitement et de les faire mieux.
C'est une technologie qui va vers la consommation
et améliorer quelque part le rendement, on peut voir.
Oui, et réduire la place que va prendre un data center dans une ville,
parce que, amie de Doreien, si on continue à grandir,
les data centers vont commencer à prendre beaucoup de place.
Oui, après il y a des grosses annonces,
si on dit un peu la presse de gros data centers qui sont construits aux Etats-Unis,
l'ARM est une solution effectivement qui est intéressante en termes de rapport,
à partir du GPU, l'NVIDIA est un peu moins.
Ok, est-ce que justement, des serveurs comme ça,
ça peut avoir une durée de vie longue ?
Dans ma question initiale, c'était super rare,
mais en gros, est-ce que ça peut avoir une durée de vie plus longue ?
Est-ce que vous allez les réutiliser ?
Est-ce que vous avez déjà pensé à la fin de vie de ces serveurs ?
Et comment les revaloriser à terme ?
Bien heureux est celui qui peut prévoir le futur.
Je ne sais pas combien de temps ça va durer.
En tout cas, les citoyens ont duré extrêmement longtemps,
il n'y a pas eu de panne de matériel,
ils n'ont pas été arrêtés pour des problématiques de matériel.
Je ne pense pas que quelqu'un puisse dire que l'architecture ARM,
pour une raison quelconque,
durerait moins longtemps que les architectures X86.
Les procédés de gravure et de fabrication sont les mêmes.
On a toutes les raisons d'espérer des durées de conservation identiques
à ce qu'on peut trouver sur l'UX86.
Ce qui veut dire qu'on est largement sur les 10 ans en termes de matériel.
Je sais qu'en Péré, pour en avoir discuté un peu avec eux,
une politique qui m'avait assez plu,
c'est qu'on n'a pas d'ailleurs, peut-être avec Apple,
c'est le cycle de vie des processeurs.
L'objectif n'est pas tous les ans de sortir un processeur nouveau,
plus puissant, qui viendrait rendre le précédent obsolète,
mais plutôt de s'inscrire dans la durée.
Il va y avoir des processeurs sur lesquels ils vont être capables
de proposer du support pendant un long moment
et d'être capables de permettre à des gens comme nous
du coup d'investir sur ces gammes de processeurs
et donc de les faire perdurer dans le temps.
Ce qu'elle oait sur la durée de vie des serveurs,
je suis assez fier de ça, donc ça me permet d'en parler,
mais je sais que les équipes d'opération et d'atacenter
ont un programme en interne, justement,
de prolongation de la vie d'un certain nombre de serveurs.
C'est quelque chose qui est assez peu mis en avant par ce qu'elle oait,
mais il y a certains processeurs qui sont encore
demandés aujourd'hui et sur lesquels on prend les machines,
on va retirer les composants qui ont un peu gésillé,
on va remettre potentiellement des SSD à la place de disque dur,
on va gréler la quantité de RAM et on va être capables
de les réinjecter pour leur donner un nouvel essor et une nouvelle vie,
donc créer des gammes qui vont être basés sur du matériel.
Ça a un vrai impact en termes de vertu écologique
et en printénergetique sur la plaine.
Est-ce que la RAM dure plus longtemps ou pas ?
Je ne sais pas.
En tout cas, aujourd'hui, on espère que ça va durer
aussi longtemps que le reste et on va quelque part,
on n'a pas de raison de douter de ça.
En tout cas, j'espère que comme ça consomme moins,
que ça chauffe moins, ça puisse durer plus longtemps
parce que ça suce moins.
En tout cas, c'est ce que j'espère avec ce genre de puce.
Comme tu le dis, on manque encore de recul.
Je vais te poser une question, je ne sais pas si tu veux me répondre,
mais en tout cas, je vais la poser.
Est-ce que Skelway envisage déjà de faire des services manager
à base d'AM, typiquement des bases de données,
du K3S, etc., qui soient basées sur l'offre ARM, justement ?
La réponse est Skelway, oui.
Les labs aussi.
On a même écrit un article de blog sur le sujet
qui, je crois qu'il est publié, mais pas encore à la ligne,
qui est justement de permettre à nos utilisateurs
d'utiliser Cosmos, donc la solution Kubernetes,
une des solutions Kubernetes manager de Skelway,
qui permet d'avoir des datas pleines qui ne sont pas chez Skelway.
En gros, l'idée, c'est de contrôler le plan chez Skelway
et vos datas pleines peuvent être chez OVH,
ou à Fever, provider qui vous plaît, et surtout, j'espère chez vous.
Cette solution-là permet dès aujourd'hui d'utiliser des nœuds en 2
pour faire justement de la...
On a fait un petit tuto de blog,
c'est un ingénieur qui s'amusait à faire ça,
et qui fait tourner via Cosmos des paternes sur les emplois.
Ça, c'est déjà faisable.
L'intégration d'encapsules est prévue.
Pour l'instant, c'est des équipes qui s'en occupent,
et elles ont déjà commencé le travail dessus,
donc ça devrait plus être très long.
Après, c'est des cycles produits plus classiques.
Après, dans ta question, il y a un truc qui est très intéressant.
Il y a deux types de services.
C'est les services manager qu'on propose à nos clients.
Donc là, oui, très clairement, avec Capsule,
on va faire une démarche permettant aux clients
d'utiliser des machines en ARM.
Il y a une deuxième chose qui est souvent moins visible,
et on sait que nos amis américains font aussi,
c'est que pour fournir du service manager au client,
il y a plein de services internes qui sont exécutés
pour justement supporter quelque part l'infrastructure.
Et là, il y a un vrai intérêt en interne.
C'est plus facile, en plus,
puisqu'on maîtrise en général plus facilement les chaînes logicielles
qui sont sur ces machines-là,
de faire passer un certain nombre de solutions
vers des architectures qui consomment.
Donc la question, la réponse est très clairement oui,
parce qu'elle oeille
à ongy quelque part d'aller sur ces architectures-là
pour réduire ces factures, des services,
on va dire internes qui permettent aux clients
d'utiliser des services manager,
je ne sais pas si tu parles de la base de données.
Quand tu fais une connexion SQL à une machine,
qu'elle soit sur de l'ARM ou du X86,
ça se passe par un pour toi.
Ce qu'il faut, c'est que le moteur de base de données
puisse tourner sur de l'ARM, oui.
Oui, et heureusement, merci OC, qui est un peu vieux,
merci aux langages comme ça,
qui ont à l'époque abstrait la compilation multi-architecture.
C'est quand même aujourd'hui assez facile d'avoir
des logiciels qui marchent sur ARM.
C'était moins qu'en 2014,
et ce n'est pas encore le cas en risque 5.
Oui, je me rappelle, parce que moi je suis développer C,
à l'origine, en fait, je me rappelle qu'à l'époque,
on passait d'une plateforme à l'autre,
donc, d'Ix, de Sun, etc.
Et donc, on était obligé de recompiler,
et de faire quelques ajustements,
mais en effet, ça fonctionnait.
Oui, moi aussi, j'ai des souvenirs douloureux de ça,
de l'école.
On était obligés des fois de rendre des projets
sur 6 architectures différentes,
et ils n'avaient pas les mêmes tailles,
à 2 int, c'était la guerre, mais très bien.
C'est des bons souvenirs en même temps.
Alors, j'ai une dernière question,
pour toi avant de passer à mes questions de clôture,
c'est, parce qu'on vient de parler longuement d'ARM,
est-ce que vous vous êtes penchés sur les puces libres
que sont les risques 5 ?
Alors, c'est...
Oui, on s'y penche, on s'y est penché,
pour l'instant, on regarde.
Vous regardez,
tu ne peux pas en dire plus que ça,
pourquoi vous regardez de loin ou pas,
ou est-ce que c'est le fait que ce sont encore assez jeunes
que l'écosystème logiciel ne soit pas au niveau de l'ARM ?
Je pense que c'est un vrai sujet de R&D.
Par contre, ça, c'est parfaitement pour nous.
Je pense que c'est, en tant que R&D,
c'est vraiment là où on doit être.
En termes d'européens et de français,
il y a un vrai sujet sur la nature du contrôle,
de l'architecture des processeurs,
et le fait d'avoir une architecture ouverte
à non propriétaires,
on a vu récemment des annonces de la société ARM
sur sa rentrée en bourse et des augmentations de frais-dissence.
Tout ça, ça pose des questions
sur la fois le modèle économique
et aussi sur la souveraineté au sens
d'être capable, d'être sûrs
que les solutions qu'on propose
vont perdurer et sont saines
pour les gens qui les utilisent.
Une architecture ouverte de processeurs,
c'est vraiment quelque chose qui est très intéressant
et qui serait vraiment salutaire
pour toute l'industrie.
C'est de ce que moi, j'en sais aujourd'hui,
c'est pas encore nature.
Après, c'est un vrai sujet chez nous
d'être capable, d'être prêt.
Quand on va commencer à avoir des fondeurs
ou des gens qui sont capables de produire des puces ARM,
on va peut-être avoir des surprises.
Il y a un challenger,
le Web Assemblée,











qui n'est pas...
Il faut voir.
Il faut voir.
On en parle de temps en temps du Web Assemblée.
Je n'ai pas encore regardé de plus près que ça.
Alors, je vais te poser
une autre question.
Est-ce que tu as un livre,
un article ou une conférence,
une ressource de manière générale
à conseiller à nos auditrices et auditeurs ?
Un livre, alors je ne suis pas un grand lecteur.
Ça peut être n'importe quelle ressource
ou un article ou quoi ?
Un article, si.
Il y a un livre qui m'a plu
quand j'étais un peu plus jeune,
qui s'appelait
« Il était une fois Linux »
qui a un peu une biographie
mais un peu un livre
qui explique l'histoire de Nus Torvald
et comment est-ce qu'il en est amené à créer Linux.
Ça m'a beaucoup inspiré le jeune moi
à justement m'orienter
plus vers des technologies ouvertes
et à participer, non-destonnant
aux communautés d'Open Source.
Et des ressources, sinon
des ressources non informatiques,
je peux conseiller les chaînes YouTube.
J'ai vraiment adoré, je trouve que YouTube
il y a de tout, mais il y a surtout des trucs géniaux.
Je pense à ScienceClick, par exemple,
qui a un vulgarisateur de physique.
Moi, ça m'a réconcilié
avec mon prof de physique
de Mathup.
Ça m'a permis de vraiment
réapprécier
les problématiques de physique
avec des vulgarisations
sciences étonnantes aussi
d'Avy Dhuapre.
Il y a deux chaînes comme ça
qui sont très bien réténeclins, la conversation scientifique.
Moi j'aime beaucoup tout ce qui est un petit peu...
Ça c'est une radio, c'est un podcast.
Toi c'est le rare, je sais que je ne suis pas très podcast
mais la conversation scientifique
c'est un podcast
que j'écoute de temps en temps
et qui me fait du bien.
Merci, j'ai noté tout ça.
Je trouverai les liens, je les mettrai en description
comme d'habitude.
Si on veut te retrouver
ou si on veut discuter avec toi
ou est-ce qu'on va
sur les réseaux sociaux ?
Ouais, j'ai un site sableu.net
sur Twitter,
sur Mastodont.
Je ne suis pas très compliqué de m'envoyer un...
Je pense que le mail, moi je suis très mail.
Un mail c'est parfait.
Un Twitter, si vous voulez
m'apostropher publiquement.
Ton adresse mail est sur ton blog ?
Elle est sur mon site.
C'est sableu.net, c'est pas compliqué.
C'est même ce que vous voulez à sableu.net.
Bon, bah écoute,
de toute façon je vais mettre le lien
de ton blog,
ton Twitter et ton LinkedIn
comme ça, si les gens veulent te contacter,
ils pourront.
Moi je te remercie en tout cas pour ta disponibilité
et pour toutes ces réponses, c'était super intéressant.
J'espère que
ça va fonctionner et que l'ARM
va revenir
très fort
chez Skaalway.
Merci pour ton temps.
Je vais te laisser un petit mot de la fin avant de faire ma petite clôture.
Un petit mot de la fin,
merci pour le moment,
c'était intéressant, c'est mon premier podcast.
C'est la première fois où je m'exprime comme ça
publiquement.
C'était agréable, je trouve que
l'ambiance est chaleureuse.
J'espère que ça intéressera
les auditeurs
les sujets qu'on a abordés.
Et puis voilà, merci à toi.
J'espère aussi que notre auditrice
ou notre auditeur qui nous écoute
a apprécié,
si il a apprécié, je suis sûr qu'il va nous laisser
un message sur toutes les plateformes.
Mais surtout moi ce que j'ai à te dire,
à toi qui écoute,
tu peux rejoindre la communauté des compagnons du DevOps
parce que ce podcast ou la chaîne YouTube
c'est un tout. Et donc il y a un forum
de discussion qui s'appelle les compagnons du DevOps.
Et tu peux nous rejoindre, on est
déjà plus de 1500.
Donc c'est hyper simple, tu vas sur
compagnons-devops.fr
ou alors c'est le premier lien en description, tu cliques
dessus, tu t'inscrives et tu vas pouvoir
venir en discuter et tu verras, on parle
de plein de trucs,
beaucoup de conteneurs, beaucoup de gouvernétisme,
mais aussi d'ensibles, etc. Et puis aussi
du mouvement DevOps de manière globale.
Et moi je te dis à très bientôt pour un prochain
podcast.