Alors quels sont les news du Cloud et du DevOps en ce moment ?
Et bien aujourd'hui on va parler du rachat d'Achicorp,
des vidéos de DevOps qui sont en ligne et puis de Proxmox 8.2.
Tout ça, on va l'aborder dans cet épisode de podcast.
Bienvenue à toi chers compagnons dans ce nouvel épisode de Actu DevOps,
ton émission de veille Cloud et DevOps mensuelle.
Alors comme d'habitude je te le rappelle à chaque fois mais reste bien jusqu'à la fin
parce qu'on a une petite sélection d'outils, aujourd'hui elle est un peu fondue,
mais parce qu'on est en comité restreint et puis voilà,
il y a plein de choses qui se passent en ce mois de mai.
Alors avec moi pour parler actu, j'ai Nicolas, bonsoir Nicolas.
Salut tout le monde.
Et j'ai aussi René, bonsoir René.
Bonsoir à toutes et tous.
Et sans transition, passons au courrier des auditrices et auditeurs
et aujourd'hui j'aimerais vous lire quelques messages qui viennent de podcast ADIX,
ma plateforme de, enfin c'est mon lecteur de podcast préféré,
et justement Radio DevOps c'est une moyenne de 4,7 avec 15 notes
et je vous ai sélectionné les 4 dernières notes.
Alors, il y a Florence CPT qui nous a laissé en janvier 2024 5 étoiles,
il nous dit super podcast pour se tenir informé de ce monde de la tech
dans un format clair, intéressant et digest et il nous dit
continuez comme ça avec les motifs parfaits.
On a aussi Chris LRX qui nous a laissé en janvier 2024 5 étoiles
et qui nous dit podcast au top pour maintenir ses connaissances
dans ce domaine large à large spectre, excusez-moi, je ne les ai pas bien relus,
étant plutôt centré d'EV dans mon travail du quotidien,
j'ai précis de découvrir ce qui se passe de l'autre côté du mur, merci à vous.
Et enfin, le dernier 5 étoiles qui nous a été laissé le 29 avril 2024,
donc il n'y a pas si longtemps que ça, par Gassien Duboc,
Gassien et nous dit hello, je suis un de tes auditeurs sur podcast ADIX.
Déjà, merci à toutes et tous pour le travail de qualité
que vous fournissez pour notre culture et notre veille.
Pour info, je ne suis pas le seul à écouter de tes podcasts
sans jamais interagir.
Et en général, si personne ne se plaint, c'est bon signe,
alors continuez dans ce sens et bonne semaine.
Alors déjà, je tiens à vous dire merci pour votre soutien,
que ce soit sur podcast ADIX ou sur les autres plateformes
ou même sur Youtube ou sur le forum,
ça fait toujours plaisir et ça nous motive à continuer
parce que mine de rien, c'est un travail exigeant
et assez prenant,
même si parfois on a un peu moins de temps comme cette fois-ci,
en tout cas pour ma part.
Donc voilà, je voudrais répondre plus particulièrement à Gassien.
En fait, c'est vrai que du coup, même si les chiffres d'écoute sont bons
et que personne ne se plaint, ça veut dire qu'on fait du bon taf.
Alors pour info, ça me permet aussi de parler de ça,
si tu m'écoutes sur podcast et pas sur la chaîne Youtube,
sache que tous les trimètres, je fais un live sur Youtube
où je parle des stats de la communauté, comment ça se passe,
comment ça évolue,
où c'est un peu les coulisses des compagnons du DevOps
et du podcast Radio DevOps.
Mais on aime avoir des retours et des commentaires
qui soient positifs ou négatifs
parce qu'en fait, on est des humains
et nous on aime bien avoir ce genre de retour.
Alors que ce soit évidemment des questions, des suggestions
ou même des compléments au podcast,
c'est toujours bon d'avoir des commentaires, quelle que soit la plateforme.
Je le dis souvent en fait, un podcast, c'est quand même dur à faire connaître.
C'est pour ça que c'est super important,
si toi tu nous écoutes et que tu nous apprécies de partager le podcast,
ça nous soutiendra et surtout de commenter.
Parce que autant la chaîne Youtube, elle évolue par elle-même,
mais le podcast, lui, c'est plus dur parce qu'il n'y a pas de découvrabilité des plateformes,
sauf peut-être sur Spotify et Apple Podcast,
et encore je ne sais pas comment ça marche là-bas.
Mais si on ne connaît pas un podcast sur les autres plateformes,
on ne sait pas qu'il existe, à moins qu'on ait le chercher.
Bon, et puis aussi, tu peux venir en discuter sur le forum.
Il y a plein de sujets tech à discuter pour toi, Gassien,
si tu nous suis silencieusement.
Donc je vais laisser la parole à mes chers co-out, co-podcasters,
pour me dire ce qu'ils ont pensé.
Je commence par « pardonner ».
Ouais, c'est des bons commentaires, donc c'est sympa.
Après, oui, je suis d'accord, c'est vrai que c'est toujours un effort,
un petit peu, de mettre des commentaires,
ou à la prendre quelques minutes pour aller mettre un like.
Ça aide à faire connaître le podcast, c'est une bonne chose.
Voilà, je laisse la place à Nico.
Oui, effectivement, les podcasts hors YouTube sont difficiles à propager,
parce que les algorithmes ne sont pas franchement les mêmes.
Et si vous avez des choses négatives à nous dire,
on le prend aussi, parce qu'effectivement,
c'est ce qui va nous permettre de nous améliorer.
Donc, continuez à nous écouter activement ou passivement,
et ça nous fera toujours plaisir d'avoir des commentaires.
Tout à fait, et si tu es sur YouTube, tu peux mettre un pouce.
Je ne le dis jamais dans les podcasts, je le dis toujours dans les vidéos.
Bon, tu l'auras compris, si tu aimes nous écouter et si tu veux nous soutenir,
et surtout, nous motiver, bah, laisse-nous un message,
bah, que ce soit sur Apple Podcast, Podcast Addict, YouTube.
Alors, je crois pas que les autres applications ne permettent de laisser le message,
mais il y a aussi le forum, il y a les réseaux sociaux,
puisque chaque épisode de podcasts, il y a une publication,
que ce soit sur mon compte personnel,
ou sur mon compte spécialisé,
puisque tu trouveras un compte spécialisé,
compagnon du devop sur Twitter et sur LinkedIn,
bientôt sur thread, je pense.
Mais, voilà, tu peux commenter.
Moi, je lis les commentaires, et puis je les sélectionne,
et je les fais passer dans le podcast.
Alors, la première news, c'est moi qui vais m'y coller,
et c'est la suite d'un feuilleton.
C'est la suite du feuilleton à Chikorp.
Donc, c'est officiel, IBM a annoncé qu'il rachetait à Chikorp
pour 6,4 milliards de dollars à la fin de l'année a priori.
Donc, c'est évidemment la suite d'une saga qu'on suit
depuis septembre 2023,
puisqu'on a déjà parlé deux fois.
Donc, rappel d'effet, qu'est-ce qui s'est passé ?
En septembre 2023, Terraform a changé de licence,
et c'est ce qu'on soupçonnait à l'époque,
un changement de licence qui visait à améliorer la solvabilité
pour la vente d'Achikorp.
Je ne sais pas comment le dire, mais à part le dire comme ça.
Donc, je te renvoie à l'épisode de podcast de l'époque,
et c'est Nicolas qui nous en parlait à l'époque.
Et puis, il y a eu le départ de Michel H. Motto,
qui a co-fondé à Chikorp en janvier 2024.
Pareil, on en parlait dans Actu DevOps.
Ça marque une ère de transition pour l'entreprise,
puisque son départ souligne quelque chose,
c'est que l'évolution d'une startup a un pilier de l'industrie,
puisque Achikorp maintenant fait partie des murs du DevOps,
on va dire, et du cloud.
Et surtout, ça prouve que Achikorp est capable de fonctionner
au-delà de ses fondateurs.
Et ça, je pense que c'est un autre pilier important pour vendre une boîte.
C'est que la boîte n'est pas forcément liée aux fondateurs.
Donc, IBM nous promet que les produits seront intégrés à Red Hat.
Red Hat, qui a été racheté lui aussi par IBM en juillet 2019.
Mais aussi à Watson X.
Watson X est la plateforme d'IA et de données d'IBM.
Donc, je te laisse des articles pour aller approfondir tout ça.
Mais cette acquisition, en fait, pour IBM,
c'est pas juste un ajout produit dans son catalogue.
C'est un pas stratégique de plus vers une intégration poussée
en fait de l'IA et de la gestion d'infrastructures.
D'après ce qu'on comprend, c'est que IBM veut servir des architectures complexes et dynamiques
avec ça, en fait, avec ces acquisitions.
Et nous, on va continuer à observer ce qui se passe auprès d'Achikorp,
surtout que c'est une société que j'appréciais énormément.
Je ne sais pas si je vais continuer à l'apprécier,
vu que je ne sais pas si elle ne va pas disparaître, en fait, noyée dans Red Hat.
En tout cas, sous la forme IBM, sous la nouvelle R-IBM,
on va suivre les innovations que vont apporter ces trois marques dans l'univers du DevOps.
C'est une chronique un peu plus courte que d'habitude,
parce que je voulais laisser la place à la discussion
qu'on va avoir entre nous, et notamment sur qu'est-ce qu'on pense de ça,
qu'est-ce qu'on pense du futur achat de Achikorp par IBM.
Qui veut commencer ?
Nicolas, peut-être parce que comme tu as fait la première chronique,
je vais te laisser la parole en premier.
Oui, du coup, effectivement, on avait beaucoup...
On s'attendait à ce que Achikorp se fasse racheter.
On savait très bien que le changement de distance
était probablement à cette volonté de vouloir vendre.
Je m'attendais au pire.
IBM, je pense que c'est finalement une bonne solution pour la communauté,
pour l'entreprise et l'industrie.
Parce qu'ils ont racheté Red Hat,
et pour l'instant, je n'ai pas vu de changements notables
qui aillent dans le mauvais sens.
Il y a eu effectivement la partie des sources,
de la partie des Red Hat Enterprise,
où ils ont fermé le code source aux autres distributions.
Mais sur ondcible, par exemple, je n'ai pas vu de changement notable,
je n'ai pas vu qu'ils avaient enlevé des trucs open source dans Teebol,
des choses comme ça.
Et finalement, je me dis que sur du long terme,
ça va permettre d'avoir Achikorp,
qui va pouvoir continuer à vivre.
Et sur la partie open source, je m'inquiétais beaucoup,
parce que quand on voit comment ça se passe pour VMware,
il y a un acteur qui essaye de maximiser énormément ses profits,
qui on aurait pu craindre à peu près la même chose pour Achikorp.
Et finalement, je me dis que le fait que ce soit IBM qui rachète,
ça va limiter la casse,
puisque je ne vous êtes pas forcément au courant,
mais IBM participe entre autres à la Linux Foundation,
qui incube le fork de Terraform et le fork de Volt.
Alors non, le fork de Volt, c'est une autre fondation,
mais où IBM participe aussi.
Et je vois mal IBM continuer à financer d'un côté les forks
et de l'autre côté ne pas laisser en open source
les produits de la maison mère, finalement.
Donc je ne sais pas ce que vous en pensez, vous.
René, t'es peut-être un petit peu en porte à faux par rapport à ça,
par rapport à ton employeur actuel,
mais tu vas peut-être pouvoir nous donner une tornavie quand même.
Oui, en plus ou pas spécialement,
mais je pense que la bonne nouvelle,
et je n'avais pas trop suivi, c'est effectivement que ce soit rataché à Radat.
Bonne nouvelle dans le sens où je ne sais pas ce que l'avenir sera,
mais je pense que c'est quand même le bon endroit
pour maintenir des produits open source, je pense,
si c'était rataché à une autre division d'IBM,
ça aurait peut-être été un petit peu différent,
mais on peut imaginer que ça va être traité au mieux, j'espère,
en étant dans Radat.
Après, une des craintes, mais je ne suis pas sûr qu'il y ait beaucoup de varlapes entre les produits,
c'est vrai qu'il y ait un produit qui soit concurrent, entre guillemets,
ou qui ait beaucoup de similitudes avec un produit existant,
mais je ne pense pas que ce soit le cas.
Je pense que tous les produits Hicorp, il n'y a pas forcément trop d'équivalents en interne,
donc je pense que ça va juste étauffer bien le catalogue,
et j'espère que ça se passera pour le mieux.
Après, on verra, je n'ai pas la boule de cristal pour savoir,
mais c'est effectivement comme tu le dis,
peut-être pas la pire des choses qui pouvaient arriver à Hicorp en tout cas.
Alors, quand vous dites le pire, j'imagine qu'il aurait pu être acheté par Oracle,
c'est peut-être ce que vous imaginez, ou Microsoft, parce que Azure, ou Google.
C'est peut-être ça le pire.
IBM, je ne sais pas.
C'est vrai que IBM a moins mauvaise réputation que les trois que j'ai cités,
et parce qu'en effet, ça fait maintenant presque cinq ans qu'ils ont acheté Red Hat,
et la marque Red Hat n'a pas pérécrité, il n'y a pas eu de problèmes majeurs.
C'est vrai qu'il y a eu les soucis de licence avec Red Hat Linux Enterprise et CentOS,
mais les autres produits, non.
Donc on peut se poser des questions.
Après, tu dis qu'il n'y a pas de concurrents.
Je viens dans l'IST2 qui sont assez proches,
même si les approches sont différentes,
et je me pose des questions quant à ces produits vis-à-vis de...
enfin, si les produits Terraformes, enfin, si les produits Hicorp, excuse-moi, sont inclus dans Red Hat.
Alors la première chose que j'en pense, c'est...
Du coup, je pense que la marque Hicorp va disparaître,
déjà parce qu'elle est très liée au nom de Michel Hachimoto, Hicorp quand même.
Donc ça explique les questionnements que moi j'avais sur la marque et le fait qu'il partait.
Mais en même temps, ce n'est pas gênant parce que Hicorp, c'est une marque qui est forte,
mais peut-être moins forte que les produits qui développent.
Et ils ont eu une approche produit qui était très bonne selon moi,
puisque chaque produit a une marque forte.
On pense à Terraformes, on pense à Packer, on pense à Vagrantes.
Chacun vraiment a une marque très forte et c'est pas grave si la marque Hicorp disparaît.
Ça, c'est mon premier point.
Le deuxième point, c'est les fameux produits qui se ressemblent.
Il y a Terraformes et Ansible.
Alors je sais, Terraformes, c'est l'infrastructure à SCODE et Ansible, c'est du Config Management.
Néanmoins, Ansible permet d'adresser du cloud et de faire des choses qui sont similaires à Terraformes.
Et je ne sais pas si le rapprochement dans Red Hat va pas... comment dire.
Perturber encore plus les gens qui ne comprennent pas la différence entre les deux produits.
Ou alors ils vont fusionner.
Il y a plein de jaune mot qui ont émergé sur Twitter, je pense que vous l'avez vu,
avec un nouveau produit qui va s'appeler Terrible, c'est la contraction de Terraformes et Ansible.
Je me pose cette question là sur ces deux produits.
Est-ce que ça veut dire que Ansible va abandonner la gestion des parties cloud au profit de Terraformes ?
Est-ce que ça va continuer à rester comme ça ? Est-ce que les deux vont fusionner ? Je ne sais pas.
Je ne sais pas si vous avez un avis là-dessus, tous les deux.
Déjà sur la partie LePierre, moi je pensais à un acteur comme Broadcom qui a racheté VMware et qui double le prix de ses licences, voire plus.
Qui est vraiment en train de sabrer l'écosystème VMware alors que c'est un produit propriétaire.
C'est même pas un produit open source et ils arrivent quand même avant pire, ils aient tout le truc.
Pour moi c'était plus un acteur du type Broadcom, pas forcément Broadcom.
Mais il y en a d'autres qui doivent agir à peu près de la même manière.
Mais après les autres acteurs que t'as cité, ils font de plus en plus d'open source aussi.
Donc ce n'était pas forcément un problème pour moi.
Même si Microsoft, quand ils rachètent, ils ont tendance à plutôt couler les boîtes.
Mais c'est plus par rapport à leur manière de gérer le business.
Microsoft fait quand même de plus en plus d'open source.
On voit aussi avec le fork qu'ils ont fait sur Redis, ils ont une volonté à faire de l'open source.
Ce n'était pas forcément l'acteur qui m'inquiète le plus.
Alors attends, avant que tu continues, parce que le point est intéressant.
Pour moi Broadcom, ce n'est pas le même sujet.
C'est plus en fait, et je pense que Nida va venir nous apparaître un jour parce qu'elle suit ça très près.
Mais c'est plus pour moi quelque chose qui se rapproche de démarches commerciales abusives que l'open source qui va disparaître.
Normalement je vois ce que tu veux dire.
Et le deuxième truc que ça m'évoque, ce qui m'ennuie, et je pense qu'on n'en parlera le mois prochain,
parce que je voudrais faire un sujet là-dessus, c'est qu'en effet,
il y a certaines boîtes qui ont des volontés de faire de l'open source et tu viens de citer des boîtes qui font des forks.
Mais pour moi, ce n'est pas la bonne manière de faire.
La bonne manière de faire, ce serait plutôt de contribuer au produit initial et pas forcément de faire un fork pour faire de l'open source.
Tu vois ce que je veux dire ?
Il y a peut-être une volonté, mais en tout cas, la manière de faire pour certains acteurs est pas forcément la plus vertueuse.
Je te laisse continuer.
On est d'accord.
Et du coup, c'est moi qui ai perdu le fil de ce que je voulais dire aussi.
Mais comme j'avais coupé la chite à renais, je vais le laisser répondre.
Oui, ce que je voulais dire, c'est deux choses.
La première, c'est que dans le pire, tu aurais pu aussi que ce soit un private equity un peu agressif,
qui découpe et vend un petit peu les produits à différents acteurs,
ou qui cherche vraiment à faire du cash très rapidement et quitte à ce que la boîte se retrouve en difficulté un peu plus tard.
Voilà, ça, c'est des exemples de choses qui peuvent arriver et qui sont déjà arrivées à certaines sociétés.
Ce n'est pas super.
Et par rapport à Antsibol Terraform, je pense que les produits sont suffisamment différents.
Ils sont écrits dans deux tecno-différentes.
Il y en a un qui est en pitton, l'autre qui est en goût si je dis pas de bêtises.
Du coup, je pense quand même que ça ne va pas...
Enfin, c'est pas impossible que ça meurt, mais ça me paraît assez compliqué.
Donc, moi, je pense que les deux produits vont continuer, mais encore une fois, je suis pas sûr et je n'ai pas d'infos sur le sujet.
C'était là-dessus que je voulais réagir, effectivement, Terraform et Antsibol sont tellement différents,
comme le disait René, l'engagement, la manière d'apprendre les choses et ainsi de suite,
que je ne vois pas forcément l'intérêt de l'émerger tous les deux.
Et surtout, j'imagine que chez Red Hat, il y a d'autres projets qui sont concurrents,
qui continuent à vivre leur vie, chacun de leur côté, malgré qu'ils aient des sujets sur lesquels ils travaillent,
qui sont quand même assez similaires.
J'imagine qu'il y a des bases de données qui sont relativement concurrentes, des produits de l'autre balancing,
ou je ne sais pas quoi d'autre.
C'est des exemples comme ça.
Pour moi, ces deux outils sont suffisamment différents pour pouvoir continuer à vivre chacun de leur côté.
Tu as essayé d'accord, mais il y a un usage que j'ai vu chez certains clients.
Typiquement, j'ai des clients qui utilisaient Antsibol pour gérer la partie cloud,
donc la partie gestion des machines, toute l'infrastructure, au lieu d'utiliser Terraform.
C'est plus cette partie-là pour moi qui est commune entre les deux outils, qui me pose question.
Et de la même manière, on peut faire un petit peu de gestion de configuration avec Terraform.
Ce n'est pas forcément le meilleur produit pour ça,
mais de la même manière que Antsibol n'est pas forcément le meilleur produit pour déployer de l'infrastructure.
Mais moi, dans une boîte précédente, j'utilisais Salstack pour déployer les machines avant de le faire avec Terraform,
puisque ce n'est pas forcément la même manière d'appréhender l'infrastructure,
et ça ne me paraît pas déconant que chaque produit continue à déployer des shows de chacun de son côté.
Par contre, il y aura peut-être une synergie beaucoup plus forte entre les deux produits.
Moi, pendant quand j'utilisais encore Antsibol, j'utilisais les Dynamics Inventory,
qui étaient quand même assez galères, je ne sais même plus comment ça fonctionnait,
mais ça allait lire le TAFE State pour exporter les ressources dans l'inventory,
mais du coup, c'était hyper lié au tile de ressources qu'on déployait, donc ce n'était pas super pratique.
Là, peut-être qu'ils vont faire des choses un petit peu plus faciles à utiliser pour avoir des inventories dynamiques dans Antsibol,
peut-être qu'ils vont développer des API par-dessus Antsibol qui vont pouvoir discuter avec Antsibol et vice-versa.
C'est plus de ce côté-là où je pense qu'il y a des choses intéressantes qui risquent d'arriver.
Ce sera tellement bien.
Voilà, ce serait trouver de la synergie entre les deux produits pour que ça fressent, je pense.
Je ne souhaite que ça à une once ence, on verra bien.
Et chez Redat, il y a aussi d'autres produits au catalogue pour faire du tube, des choses comme ça,
et peut-être que du roi de d'autres évolutions vont arriver par là aussi.
C'est mon deuxième point, c'est Nomad versus OpenShift.
OpenShift, je le rappelle, pour les personnes qui ne connaissent pas, c'est une distribution cube qui est assez particulière,
c'est la distribution cube de Redat, et pour moi, elle est unée, et presque prode-rédit.
Et il y a Nomad, qui sont deux orchestrateurs de conteneurs qui n'ont pas du tout la même philosophie,
et qui est la même approche, est-ce que selon vous, ça peut être problématique ?
C'est deux produits qui appréhendent l'infrastructure de manière différente.
Moi, je ne vois pas pourquoi il s'abreraient Nomad.
Effectivement, ça rentre un petit peu en concurrence, mais encore une fois,
le fait que ce soit IBM Redat qui rachète Hicorp, ça me rassure sur le futur de tous ces petits produits.
Moi, j'avais peur que ce soit un VMOR ou autre qui rachète Hicorp, et qui mette de côté Consul,
parce que le service Discovery, on s'en fout, qui mette de côté Nomad, parce qu'on s'en fout.
Paker, personne n'utilise, elle est hop, elle est poubelle, et Bundari, ça ne sert à rien.
On vend du VPN et ZOO, c'est parti.
Moi, c'était plus ça qui m'inquiétait dans le rachat d'Hicorp.
Et finalement, comme c'est IBM Redat, je suis quand même un petit peu plus rassuré par rapport au produit existant.
Pour Nomad, c'est vrai que celui-là, c'est peut-être un peu plus compliqué.
Il y a beaucoup d'investissements côté OpenShift, effectivement, comme Ernest F.
Donc, je ne sais pas du tout ce que ça va donner.
Après, je pense qu'on n'a pas tous les éléments pour savoir,
il faut savoir quelle est la part de marché installé,
s'il y a des potentiels clients, s'il y a une base installée importante.
Je dirais effectivement que c'est peut-être le produit peut-être un peu plus en danger, entre guillemets.
Même si c'est assez différent de Kubernetes,
je pense qu'il y a quand même des clients que ça intéresse
parce que c'est quand même vu comme peut-être plus simple ou moins complet.
Là, c'est vrai que c'est un peu délicat et on va venir nous dire ce qui va se passer.
Oui, j'ai l'impression en effet que c'est un orchestrateur plus simple
avec un niveau d'abstraction peut-être moins complexe.
On en parlait déjà dans ton besoin de Kubernetes.
Donc, si tu n'as pas vu l'épisode, je te renvoie à cet épisode.
Il y a une petite fiche qui va s'afficher là, je crois, chez Plu, chez Jaby.
Bref, là quelque part.
Je ne pense pas que ça disparaisse, mais que je suis comme toi, je suis perplexe,
mais on est un peu là pour faire de la prospective.
Et le dernier point dont je voudrais discuter avec vous,
c'est le point évident qui est la concentration des acteurs,
parce qu'avec tous ces rachats dans tous les sens,
on voit qu'il y a une concentration des acteurs.
Les startups qui ont émergé il y a quelques dizaines d'années se font racheter par les gros.
Docker s'est fait racheter.
V-Mware, ce n'est pas vraiment une startup, mais voilà.
Il y a une concentration des acteurs.
Qu'est-ce que vous en pensez, vous de cette concentration,
où on va vers un moment de plus en plus centraliser vers des très gros acteurs énormes de la tech
qui ont un pouvoir de plus en plus démesuré selon moi.
Nicolas, tu hoches de la tête, faciles.
Oui, je pense que c'est des cycles.
Ça va, ça vient.
Régulièrement, les boîtes se font racheter,
et régulièrement, il y a d'autres boîtes qui se créent.
Je pense que c'est juste ça.
Oui, je pense que Nicolas est vrai.
Il y a des cycles.
Après, je pense quand les acteurs sont plus petits et plus...
On a plus d'innovation quand même.
Pour moi, je dirais que c'est peut-être...
J'aime bien quand même qu'il y ait un peu de diversité avec pas mal de solutions,
parce que je pense que ça fait mieux avancer l'écosystème.
Donc, voilà, je ne suis pas à coin de s'y souhaiter une bonne...
Je ne sais pas.
Pas de rachat, on était peut-être mieux,
dans certains points de vue, pour l'innovation.
Après, si j'étais actionnaire à Chicorpe, peut-être que je ne te dirais pas la même chose.
Écoutez, je suis du même à victoire,
je trouve que plusieurs acteurs, c'est bien pour l'innovation.
Moi, ce qui m'inquiète, je ne pense pas, par contre, comme Nicolas, que ce soit un cycle,
parce que le cycle est dur depuis longtemps,
depuis le début de l'ère d'informatique,
on voit une concentration de plus en plus importante des acteurs.
Sauf que l'informatique aujourd'hui est un domaine métier qui a tendance à gagnoter tout le reste, en fait.
On automatise tout.
Et avec l'arrivée de Lila, à mon avis, ça ne va pas s'arrêter.
Donc, la concentration des acteurs, moi, me fait peur,
parce que finalement, ces acteurs-là, qui disent concentration d'acteurs,
disent moins de personnes qui travaillent et moins de salariés.
Et donc, combien on va laisser de gens sur le côté ?
Combien on va laisser d'ingénieurs ou autres sur le côté ?
C'est une question.
Et que vont faire ces grands acteurs et ces géants avec tout chiffre d'affaires qu'ils vont faire ?
Parce qu'à terme, il y a ça, il y a le chiffre d'affaires qui vont être faits par les grandes entreprises.
Moi, c'est ça, ma grosse crainte.
Et puis aussi, le fait que si le monde de la tech est au main de moins d'une dizaine d'entreprises,
c'est quoi le monde qu'on va voir ?
Bref, c'est des questions qu'il va falloir qu'on se file, je pense.
Je te trouve un petit peu pessimiste sur tous les derniers épisodes.
J'étais en train d'écouter sur le trajet tout à l'heure quand tu parlais de la crise climatique des glaciers qui fonder.
Le bon côté des choses, c'est que le chiffre d'affaires des entreprises grossit.
Plus sérieusement, je ne pense pas que le fait qu'il y ait cette concentration-là réduise la part d'employabilité dans notre domaine.
Au contraire, je pense qu'on va avoir de plus en plus besoin de nous.
Et tous les petits jeunes qui arrivent, il y aura de plus en plus de boulot pour eux.
Des boulots un petit peu différents, des manières de gérer les infrastructures différentes, etc.
Les 6 admins, comme on a été, vont disparaître.
Puisque se connecter en sessage sur un serveur, ça va se faire de moins en moins.
Ça fait des années qu'on dit ça, je me connecte toujours en sessage.
Mais comme quoi, je dois être un peu trop vieux.
Et ce que tu disais aussi, c'est la concentration.
Je pense qu'il y a toujours la possibilité qu'il y ait des petits acteurs qui arrivent avec un nouveau produit,
une nouvelle manière de faire les choses.
A Chicorp, quand ils sont arrivés, VMware existait déjà, il y avait déjà différentes plateformes de virtualisation.
Et ils sont arrivés parce qu'il y avait un problème.
Et les startups se créent comme ça.
Il y a un problème, on identifie un problème, on crée un produit, on commence à le vendre.
Et à un moment donné, on se fait racheter ou pas.
Il y a certaines boîtes qui ont tellement gros cycles, c'est elles qui ont racheté d'autres boîtes.
Et finalement, quand je disais cycle, c'est pas forcément un cycle qui se répète pour l'intégralité des entreprises.
Mais les startups, quand ils se créent, il y a deux manières de les financer et de vouloir les créer.
C'est soit, on crée une startup pour se générer du travail.
Et quand on va au travail, on est content parce que c'est notre produit, on le voit grandir et ainsi de suite.
Et il y en a qui montent des boîtes parce qu'ils veulent se faire racheter par une Big Tech et prendre leur retraite anticipée à 30 ans
parce qu'ils ont vendu ça à Facebook.
Si vous êtes du même âge que moi, vous avez connu ces gens-là qui ont créé des boîtes en vouloir absolument les revendre à Facebook.
Je pense que c'est un cycle naturel dans les entreprises.
Il y a des gens qui vont créer des boîtes pour le plaisir.
Et quand tu crées ton produit, c'est toujours gratifiant de voir grossir, de voir des clients satisfaits, d'avoir plus en plus de clients.
Et après, créer une boîte pour la revendre à terme à une Big Tech, c'est aussi une bonne chose parce que ça veut dire que ça a satisfait aussi un besoin.
À Chicorps, ils ont été rachetés, c'est pas pour rien.
Pourquoi c'est une boîte qui a une croissance de folie ?
Quand ils sont créés en 2000, on va dire que c'était il y a une dizaine d'années,
il n'y avait rien qui résolvait les problèmes qu'ils ont résolus à l'époque.
Quand Michel H. Motto a commencé à développer Vagrant, il y avait un réel problème avec la création des images virtuelles
et la mise à disposition d'environnement pour les développeurs.
Il a créé Vagrant, ça a marché, il a monté une boîte, il a créé d'autres produits au fur et à mesure.
Et finalement, ça a résolu des problèmes pour plein de gens.
Au bout d'un moment, il s'est mis à vendre du service par-dessus,
soit avec des licences, des formations, des certifications et ainsi de suite.
Et tout ça, c'est du modèle économique.
Il se trouve que les produits étaient quasiment tous open source.
Il y en a un ou deux qui n'ont jamais été open source, mais l'autre grande majorité a été open source.
À un moment donné, ils ont changé de licence, on en a parlé, la business license.
Est-ce que c'était réellement pour vendre ou parce qu'ils voyaient des parts de marché qui étaient en train de se faire grignoter par d'autres acteurs ?
Ça, on ne saura jamais.
Mais en tout cas, et moi ce qui m'inquiète plus, c'est le business de l'open source qui commence à être compliqué.
C'est plus que ça qui m'inquiète.
Je pense qu'on en parlera le mois prochain, soit le mois d'après, parce que j'ai un sujet là-dessus.
Quelques petites infos à Chicorp.
Ça a été créé en 2013, mais c'était 2012.
Ça a été cofondé par Michel Achimoto, je l'ai dit, et puis Harmon Dadegard.
Il y a 2200 employés aujourd'hui.
Et c'est rentré en bourse, a priori, en 2021.
Et ça a une valorisation, d'après ce que je vois, de 1,2 milliard.
Après, dans tout ce que t'as dit, c'est vrai qu'il y a deux manières de faire les start-ups.
Moi, je fais clairement partie de la première manière.
Quelqu'un qui va créer une entreprise pour y vivre et être bien de ce qu'il fait.
C'est ce qu'on fait avec Frogit et nos autres Sass.
Moi, je trouve que la surreprésentation des start-ups, dans le but, c'est de vendre dans les médias et néfastes pour tout le monde, en fait.
Parce que ça ne montre pas qu'on peut créer des entreprises type start-up pour justement les garder à terre.
Oui, Nicolas.
Je suis dans une start-up qui crée un produit.
Mais pourquoi on ne parle pas de nous dans la presse ?
C'est parce que nous, on ne se fait pas racheter pour des millions de dollars.
Tout à fait.
Donc, on ne parle pas de nous.
Mais ce n'est pas pour autant qu'on n'est pas utilisé.
Tu vois ce que je veux dire ? C'est que la représentation dans les médias, elle ne joue pas en notre faveur.
Et elle ne montre pas que ce business-là est tout aussi intéressant pour les start-ups.
Peut-être que c'est à nous aussi de voir si on peut communiquer sur ces boîtes-là.
Parce qu'il y en a plein, il y en a plein, y compris en France, qui sont des start-ups, qui ne sont pas des grosses boîtes qu'il faut racheter,
mais qui font vivre des dizaines ou plusieurs dizaines de personnes.
Alors, dans les précaisons épisodes, vous aviez parlé de QQuit, qui était une alternative à Lottie.
J'ai rencontré le fondateur Fosdem il y a deux ans.
Lui, je ne pense pas qu'il ait créé le produit pour absolument se revendre à une big tech.
Et finalement, il fait un produit vieil avec.
Par contre, on n'en parle pas dans zéro informatique.
Peut-être un jour.
Après, il y a peut-être un mal un peu franco-français, qui est, ou même un peu européen,
qu'on n'arrive pas à effectivement faire des grosses boîtes comme les US.
On va vraiment passer un certain cap de taille au niveau des entreprises.
Et je pense que c'est un peu culturel.
Et puis, peut-être du sport te dire que par rapport à la concentration,
tu n'es jamais à la brue, qu'il y a un étudiant Finlandais quelque part qui sort un truc
et qui révolutionne une grande partie de l'informatique.
Oui.
Tu parles de Linux ou de SSH ?
Je parlais plutôt de Linux.
On fera peut-être un épisode jour sur Linux Torval.
Et donc, vous voulez vraiment qu'on fasse un épisode open source et en plus un épisode French Tech ?
Non, non, je ne pense pas.
Même si.
Alors, je pense que ce que tu dis, René, il n'y a pas que l'aspect culturel qui fait qu'on n'aura pour voir pas émerger de big tech.
Il y a aussi, à mon avis, le financement et les commandes qui sont fléchées vers les entreprises
et les startups aux États-Unis qui ne sont pas le cas en Europe,
parce qu'on a des contraintes complètement différentes.
Et puis, il faut voir que aux États-Unis, ils sont beaucoup plus nombreux que nous.
Ils ont une culture commune, alors que nous, en Europe,
même si on est potentiellement presque aussi nombreux,
on n'a pas une culture et de longs communes, ce qui ne facilite pas les choses.
Donc, on n'est pas vraiment comme des États agglomérés comme les États-Unis.
Il n'y a pas que l'aspect culturel.
En tout cas, moi, je ne vois pas que le côté on ne veut pas faire des grandes entreprises, etc.
Pour moi, il n'y a pas que ça qui nous freine. Il y a d'autres sujets.
Non, mais par exemple, juste un exemple, c'est que quand même, tu vois qu'en France,
des grosses entreprises sont quand même plus réticentes à utiliser,
parfois des petites entreprises, etc.
Je pense que c'est un peu moins vrai aux US, un acteur, à partir du moment où il est prometteur, etc.
Il mise beaucoup plus, je pense, dessus.
Effectivement, ça revient à ce que tu dis, à la fois en termes d'usage,
mais aussi d'investissement, c'est sûr que c'est différent.
Il y a ça, il y a aussi le fait que les grosses entreprises dont tu parles,
si on parle des entreprises du CAC 40, c'est toutes des centenaires, il me semble.
Toutes les entreprises du CAC 40 sont très vieilles boîtes.
Et donc, elles sont, à mon avis, plus anciennes que la plupart des grosses boîtes aux États-Unis.
Et donc, de fait, elles sont plus frileuses et elles ont une culture qui est complètement indifféente.
Et là, pour le coup, je te rejoins sur l'aspect culturel.
Je pense que l'aspect culturel aux États-Unis est plus vers l'innovation,
testant des trucs qu'en France.
Mais ce que je veux dire, c'est qu'il n'y a pas que ça.
Il y a plein de petites choses qui s'agglutinent pour faire que...
Il y a des petites entités au sein des grosses boîtes françaises qu'il faut en sorte d'innover.
Ouais, tout à fait. J'espère que ça va continuer.
Alors, la suite, c'est la place du sponsor du mois.
T'as pris l'habitude, chaque mois, il y a un sponsor.
Ce mois-ci, je vais te parler de ma nouvelle offre puisque, pour l'instant, c'est encore moi qui sponsorise le podcast.
Donc, la nouvelle offre, c'est l'académie Froguite.
Alors, la transmission, c'est mon Dada et je cherchais à améliorer tous nos services autour de GitLab,
puisqu'avec Froguite, on veut vraiment se spécialiser autour de GitLab.
J'ai donc imaginé l'académie Froguite qui permet justement de maximiser l'efficacité des équipes techniques
en dynamisant leur maîtrise de GitLab avec une académie en ligne.
Alors, si tu crées du code avec GitLab que tu as à apprendre
ou à utiliser plus rapidement pour être plus productif cet outil,
si tu commences simplement à utiliser GitLab ou que tu veuilles te perfectionner,
écoute bien parce que ça pourrait t'intéresser.
Alors, dans l'offre à académie Froguite, il y a trois plans.
Le premier plan, c'est GitLab mentor as a service
où tu poses tes questions sur un forum et tu votes pour celles qui t'intéressent.
Puis, chaque mois, il y a un mentor qui va dédié une heure à répondre en vidéo
aux questions qui ont reçu le plus de votes.
Le deuxième plan, c'est l'école GitLab pour te former en autonomie et à ton rythme,
puisque chaque mois, tu vas recevoir un module vidéo de notre formation continue GitLab.
Avec des exemples concrets, des cas d'usage et un exercice pour t'entraîner.
Et en bonus, de ce plan-là, tu auras le plan précédent, GitLab mentor as a service,
mais aussi un abonnement mensuel, tout compris à Froguite.
Et enfin, le plan le plus élevé, c'est l'accélérateur GitLab.
Je t'en ai déjà parlé.
Ça permet d'accélérer ton apprentissage grâce à un mentor
qui va te partager sa recherche et développement.
C'est un programme de formation et de mentoras collectifs par promotion de cinq personnes,
puisque toutes les deux semaines t'as une session de deux heures en vision conférence avec un mentor.
T'as le replay des vidéos pour faire tes révisions, les notes du mentor,
une transcription complète faite par ya de chaque atelier
et un espace de discussion pour la promo.
Et en bonus, tu as les plans précédents.
Donc l'académie Froguite, c'est vraiment là pour propulser ta maîtrise de GitLab à une vitesse supérieure.
Et comme c'est nouveau en fait, je teste cette offre-là.
Je fais une bêta pendant trois mois,
pendant trois mois du mois de juin au mois d'août de cette année,
donc 2024, je te propose de faire partie de la bêta
avec 50% de réduction sur les prix.
Et en échange, je vais te demander un témoignage et un retour sur la bêta.
Ça me permettra de mieux qualifier l'offre et de voir là où justement je peux améliorer les choses.
Donc tu peux aller sur bref.lydra.fr slashacadémie-froguit
ou alors c'est le premier lien en description et puis tu verras tout ça
et puis si tu as besoin, tu peux m'écrire aussi, tu peux prendre contact avec moi.
Il y aura les tarifs en plus sur cette page-là, tu verras,
comme il y a trois plans, il y a trois tarifs.
Mais là ce que je te propose c'est la bêta au tarif le plus élevé,
mais avec les 50% de réduction.
Et maintenant, René, tu vas nous parler de...
je sais pas comment faire la transition, mais en tout cas, il y a le feu là-dedans.
Oui, en fait c'est...
c'était un peu difficile de trouver des news, moi aussi,
donc j'ai lu un article que j'ai trouvé très intéressant.
Alors en faisant ma veille un petit peu sur Rust, etc.
mais je pense que ce que je vais dire n'est pas lié spécialement à Rust,
ça existe dans les autres langages.
Et en fait c'est en gros un cas d'optimisation de performance pour un SAS.
Mais ce que j'ai trouvé intéressant c'est que j'ai trouvé le sujet et la manière dont c'était abordé.
Accessible, c'est-à-dire que le problème est relativement facile à comprendre.
Et ça montre aussi l'utilisation d'outils, donc des fameux outils comme Flamegraph.
Donc c'est plutôt que ces outils existent dans plusieurs langages
et qui permettent de déterminer où par exemple un programme prend le plus de temps.
Et puis un autre outil qui est dans l'article est Divan,
qui permet de mettre en place des benchmarks.
Mais voilà, il y a plein d'outils pour faire ça dans les différents langages.
Et ce qui est intéressant je pense dans l'article c'est de voir la démarche.
Donc ça part d'un SAS qui est relativement lent,
parce qu'il y a une opération qui est faite.
Donc c'est une entreprise qui travaille dans le domaine de la cartographie.
Et il découvre qu'il y a un filtre qui calcule 6 points dans ce qu'ils appellent un corridor.
Donc en gros l'idée c'est que si on peut essayer d'expliquer très simplement
l'idée c'est qu'entre deux points c'est comme si on mettait un gros coup de stabilo.
Et on cherche à savoir quels sont les points qui sont dans le trait du stabilo.
Et voilà, c'est pour imaginer un peu le truc.
Et il se trouve que ce filtre est très très lent.
Et on passe un petit peu par toutes les étapes pour trouver le pourquoi du comment
et comment est trouvé la méthode pour grandement optimiser les performances
avec un petit peu aussi toutes les perturbations,
enfin les mauvaises influences qu'on peut avoir par rapport à ce genre de cas.
Parce que souvent et c'est ce qui est expliqué dans l'article,
le gain un tweet en se disant c'est la douée de ça qui est lent.
Et en fait la mesure avec le fait de mesurer et de faire un flame graph etc. et de suivre la démarche.
Et bien il se rend compte qu'il ne part pas sur la bonne piste.
Et donc est-ce qu'il y ait quand même quelque chose qui arrive assez souvent.
Et donc voilà cet article est passionnant et j'encourage tout le monde
qui peut avoir ce type de problématique à le lire parce que c'est je trouve une bonne source
et quelque chose de, voilà c'est encore une fois c'est facile à comprendre et à materialiser.
Voilà j'imagine que vous n'avez pas forcément vu cet article mais voilà c'est ce que j'ai réussi à créer un petit peu de teasing
pour que vous alliez y acheter un article.
Nicolas.
Oui alors moi je connais les flame graph depuis un bon moment.
Je les ai assez rarement utilisé parce que ça demande quand même de mettre en place pas mal d'outillages
et j'ai deux choses à dire dessus.
Le premier truc c'est que c'est très marrant l'outil pour visualiser les flame graph.
C'est un outil qui a été écrit par Brenda Gregg.
Donc j'en avais déjà parlé de Brenda Gregg qui a fait un super bouquin sur, enfin même plusieurs,
sur les performances principalement sous les uniques.
Il y en a un sous Linux et il y en a un sur les autres.
Je ne sais plus exactement lesquels mais bon peu importe.
C'est une excellente ressource.
Regardez ce que fait cet homme-là parce qu'il fait un travail fabuleux sur comment trouver les problèmes de perf.
C'est à ce, lors de l'épisode où on avait parlé des problèmes en production que j'en avais parlé avec notamment la méthode use.
Et l'outil flame graph c'est un outil qui en parle donc c'est assez marrant de voir que ça existe toujours.
Et le deuxième truc que je voulais dire c'est le fait d'avoir ces outils à disposition en prod.
Moi je vous conseille de faire en sorte que ça puisse être exécuté sur votre infra.
Parce que le jour où vous aurez un problème de perf ça va être hyper galère pour mettre en place ces outils-là.
Alors que si vous passez du temps au début du projet pour avoir ces outils qui sont activables entre guigmer en un clic,
ça va vous sauver les fesses le jour où vous aurez des problèmes.
Par contre c'est quand vous êtes au début de votre projet, installer ces outils-là mais ne regardez pas forcément le chercher et optimiser votre produit.
Rajoutez les fonctionnalités au fur et à mesure et quand vous aurez réellement des problèmes de performance,
concentrez-vous sur la partie performance mais avant de vous concentrer sur la partie performance, améliorer votre produit.
Mais faites en sorte d'avoir de l'outillage pour pouvoir regarder ces problèmes de perf le jour où vous en aurez.
Je ne sais plus dans quel épisode on avait parlé des piliers de DevOps et notamment l'observabilité.
Et Christophe tu m'avais repris sur la partie ligne.
Donc le ligne c'est faire les choses qui sont importantes au moment où elles sont importantes
et ne pas gaspiller de temps là où vous n'avez pas besoin de l'y passer du temps.
Et là typiquement c'est ça.
Si vous faites du ruste, regardez pour activer la possibilité de faire des flammes graphes dans votre code
mais ne regardez pas le résultat du flammes graphes avant d'avoir des soucis de performance.
Et toi Christophe, est-ce que tu aimes mettre le feu dans tes applications ?
Oui j'adore ça.
Alors moi j'aurais une autre approche que toi étant donné que je suis très pro déploiement continu à ces mondanas.
À partir du moment où on peut déployer une nouvelle application, une nouvelle réalise rapidement,
je pense qu'on peut rajouter des briques de monitoring ou d'APM.
Parce que c'est là dont on peut... Je ne sais pas si dans l'article j'utilise des APM
mais en tout cas pour voir des problèmes de performance dans le code, il faut utiliser des APM
ou des applications de supervision de performance en français.
Ou alors en effet faire comme tu le dis, moi je ne le ferais pas comme toi, je la jouterai au moment où j'en ai besoin
parce que ça me prendrait une semaine peut-être pour l'activer.
Mais ça nous prouve bien, oui.
Mais si tu le fais au moment où tu as le problème, tu n'as pas suffisamment de recul sur témétrique
pour voir quand est apparu le problème et ainsi de suite.
Alors oui, moi je fais quand même une différence entre les APM et les outils de supervision de manière globale,
parce qu'en effet il faut mettre des outils de supervision quoi qu'il arrive.
Et l'APM, comme c'est en plus un truc qui consomme quand même plus que juste un peu de supervision,
l'activer au moment où ça arrive c'est bien.
Mais oui, c'est ce que je vais dire, ça nous prouve bien que la supervision
et mettre en place une supervision c'est important.
C'est important pour savoir ce qui se passe et pour savoir quand ça arrive.
Comme tu le dis, s'il y a des dégradations de performance
qu'on peut monitorer, genre une page internet ou une requête spécifique qui dérive dans le temps,
c'est bien de le voir avec des outils de supervision.
Oui en fait je ne voulais pas trop spoiler les articles, c'est des gens en effet de le voir.
Mais en fait là il y a vraiment la démarre justement, ça part entre guillemets de la supervision.
Oui ils arrivent, ils font un premier graphe avec les percentiles, donc ils voient qu'il y a un certain type de requête
qui prend plus de temps.
Donc ça se fait vraiment avec les outils de supervision et les temps de réponse simplement des requêtes
et donc ils arrivent à affiner en fait jusqu'à tomber sur entre guillemets le processus
ou le type de fameux filtres qui pose problème.
Et ensuite ça passe dans un deuxième temps où là effectivement ils basculent sur les outils de...
enfin entre guillemets sur un poste plutôt développeur, ils installent le flamerafe, ils déterminent...
ils voient effectivement que le filtre... ils analysent la fonction du filtre et ils regardent ce qui prend le plus de temps dans le filtre.
Et il trouve une optimisation, je ne peux pas décrire tout l'article, mais voilà il y a vraiment ce démarge qui...
pour ça que l'article je pense c'est vraiment intéressant et encore une fois ça reste...
enfin moi j'ai trouvé que ça restait vraiment...
pour le coup ce cas là, il n'arrive pas partout mais d'habitude c'est quand même des choses assez pointues, etc.
assez difficiles, là je trouve que c'est vraiment palpable et compréhensible.
Et aussi dans la manière dont c'est écrit, il n'y a quasiment pas de code dans l'article,
c'est vraiment des explications et presque un rex en fait de comment il a fait quoi.
Moi je voudrais remonder sur quelque chose qui est proche, souvent quand on parle de DevOps,
vous savez on a eu beaucoup de débats sur OK, c'est un dev qui fait de l'ops, ou c'est un ops qui fait du dev,
parce qu'on est capables de faire les deux aujourd'hui.
Et en fait moi ce genre d'article ça prouve bien qu'en fait on a deux métiers différents,
il y a les devs qui en effet produisent du code et conçoivent des solutions logicielles
et il y a les ops qui les exploitent et qui sont à même d'investiguer et de trouver avec les devs,
évidemment parce que tout ça c'est compliqué, mais c'est les ops qui ont la capacité et l'expérience
pour gérer la volumétrie. Quand t'es dev et on l'a vu tout à l'heure, il y a un message de quelqu'un qui est dev,
quand t'es dev tu n'as pas l'habitude et tu n'as pas conscience que la volumétrie peut être énorme
et quand tu développes une application, en fait ce n'est pas ton problème de faire face à la volumétrie,
c'est quelque chose que tu vois en production, c'est sûr, tu ne peux pas au moment où tu développes une appli,
te dire OK je vais avoir 10 000 personnes en simultané qui vont faire tel requête,
non ça c'est vraiment le rôle de l'ops, de OK j'ai des problèmes de performance, qu'est ce qui se passe,
j'ai combien d'utilisateurs, ma base de données, les surchargés, j'ai combien d'enregistrement,
enfin tout ces trucs là, c'est le rôle de l'ops de mener ces investigations et avec ou pas l'aide des devs
de trouver des solutions. Et pour moi c'est un des aspects du métier dont on ne parle pas assez,
qui est à la partie que moi j'adore parce que l'investigation, j'ai toujours l'impression d'être cher recol,
quand je fais ça, j'ai un problème, je vais aller voir, je vais remonter mes logs, je vais voir mes métriques
et donc je trouve la solution du problème et après une fois que j'ai fait l'analyse et que j'ai trouvé où était le problème,
je filme mon analyse à mes petits potes les devs et je leur dis, moi j'ai trouvé ça, il y a a priori un problème ici,
est-ce que vous pensez pouvoir résoudre le problème, je suis prêt à vous aider et puis on en parle.
C'est normal parce que tu as besoin d'avoir aussi une connaissance métier des trois assez profondes
en tant que hop, ce n'est pas forcément ou par sément et donc là où je ne suis pas tout à fait d'accord
ce que tu dis c'est qu'il y a un niveau du développement par rapport à la complexité suivant ce que tu fais quand même
le développeur il doit quand même avoir une notion de ce qui va un petit peu fonctionner ce qu'il écrit,
ce qui risque de se passer, c'est-à-dire que s'il fait vraiment un code avec une complexité importante, forcément ça ne va pas se quitter
alors si c'est sur un produit complètement nouveau dont tu ne sais pas quel va être l'usage et le nombre de personnes que tu vas avoir
là oui effectivement c'est difficile de prévoir par contre si c'est par exemple une modification sur une appli existante
ou tu connais un peu la volumétrie, là tu peux quand même estimer un petit peu voilà si tu t'embêtes à faire un nouveau un peu meilleur
ou pas quoi. Oui mais tout ça vient avec l'expérience plus t'as de l'expérience, plus tu penses à ce genre de choses
mais comme il y a quand même beaucoup de développeurs qui sont nos vices qui nous écoutent, c'est pour ça que j'en parle aussi.
Nicolas, dernier truc à ajouter ?
Pas d'optimisation prématurée.
Ouais, surtout qu'en plus on pourrait se planter si on optimise trop d'où.
D'où le côté contre-intuitif justement le gars qui analyse au début se plante complètement, c'est-à-dire s'il avait fait l'optimisation sans mesurer
clairement un biais qui fait que l'humain est très mauvais pour prédire les problèmes de performance.
Ce que j'ai tendance à dire et ce n'est pas valable que pour l'informatique, c'est valable pour les entreprises et je le dis aussi
en tant qu'amble du CS à ma direction, on ne peut améliorer que ce qu'on mesure correctement.
Donc si on veut améliorer quelque chose que ce soit un programme informatique ou des process dans une organisation
il faut mesurer les choses avant, pendant et après.
Et si on voit une évolution dans la mesure, c'est qu'on a réussi notre amélioration et sinon c'est qu'on s'est raté quelque part.
Mais de la même manière pour les APM, si tu les mets dès le début de ton projet, si on te dit c'est lent tu peux répondre, oui mais c'est aussi long qu'avant.
C'est clair que si tu le mets au tout début, il n'y a pas de problème de performance, il y a ton APM.
Bon, je vous propose qu'on passe à la suite et avant de passer à la suite, si tu aimes ce podcast et tu veux t'assurer qu'il continue
et si tu veux l'écouter encore longtemps, le meilleur moyen pour nous soutenir c'est via un don, comme l'a fait Rodan.
Rodan il a fait un don sur LibèreAPE, tu trouveras un lien en description et je remercie du coup Rodan qui a fait un don de 1€ par mois pendant 13 mois.
C'est l'un des premiers donateurs qui n'est pas secret parce que sur LibèreAPE, l'avantage c'est que tu peux faire des dons secrets
même si je connais certains de mes donateurs secrets, mais comme ils ont décidé d'être secrets je ne dirai pas qui c'est.
Mais tu peux aussi faire des dons nommés, en tout cas tu peux faire comme Rodan et nous soutenir ça nous aidera à payer les outils informatiques qu'on utilise
justement pour enregistrer et héberger ce podcast.
Nicolas, tu vas nous parler de la nouvelle version de Proxmox, si j'ai bien suivi.
Oui, donc Proxmox Virtual Environment est sorti en version 8.2 en avril, le 24.
Les nouveautés c'est basé sur la DBN 12.5 de Bookworm, ça intègre les nouvelles versions de QMU, LX, CSF et ZFS.
Si vous voulez les versions, allez lire dans les notes de l'épisode, vous aurez un lien vers la release note de Proxmox.
Ce qui a d'intéressant dans cette nouvelle release, c'est qu'ils ont amélioré l'assistant d'import pour VMware et SXY, on se demande vraiment pourquoi.
Ils ont aussi fait en sorte que l'installation soit encore plus facile quand vous voulez l'automatiser.
Ils ont fait pas mal de choses ou quand vous avez un parc énorme, vous pouvez réinstaller vos Proxmox de manière entièrement automatique.
Ils ont aussi amélioré une partie sur le backup, notamment quand vous voulez backup vos machines virtuelles pendant qu'elles seront utilisées.
Et notamment si vous avez beaucoup d'aillots sur votre VM, ça ne va pas la ralentir, même si votre serveur de backup est un petit peu trop loin
car pas dans le même site géographique, avec une bande passante réduite et ainsi de suite.
Ce qu'ils font, c'est tout simplement bufferiser les données dont on a besoin sur la VM.
Ça envoie tout d'un coup au serveur de backup comme lui Paulin Gérée, mais ça ralentit pas la VM pendant le backup.
En tout cas, ça réduit le ralentissement.
Il y a aussi une prévio sur la partie Firewalling, puisqu'aujourd'hui c'est encore avec Ippetables.
Ils ont fait une prévio sur la partie NFTable, c'est le successeur de Ippetables.
Personnellement, j'utilise toujours Ippetables parce que ça fonctionne bien, mais a priori NFTable améliore pas mal les performances.
Je ne sais pas si tu avais vu cette sortie-là, René, est-ce que ça t'inspire ?
Non, je n'avais pas spécialement vu. Je ne suis pas trop trop le produit.
Je sais que c'est une bonne solution et qu'il y a des aficions à dose.
Je suis très content qu'il y ait des alternatives à VMware et pour le coup, c'est une solution qui tient bien la route.
Le fait qu'elle progresse, je trouve ça chouette. Mais je n'ai pas forcément plus à ajouter.
Avant que je commence, je rappelle à notre auditeur qu'on avait fait un épisode de podcast sur Proxmox en Prod.
J'avais interviewé quelqu'un qui gérait plus de 200 VM. Je te mets une fiche si tu es sur YouTube quelque part.
Si tu écoutes ce podcast en audio, dans les notes, plutôt dans l'article de blog, parce que maintenant nos notes sont tellement grosses que ça ne rentre pas.
Tous les liens sont dans les articles de blog. Je vous profite pour le dire pour les gens qui cherchent.
Vous avez le lien de l'article de blog dans chaque description et sur l'article de blog. Vous avez tous les liens de tout ce qu'on dit.
Proxmox, j'ai l'impression que ça prend de plus en plus d'ampleur et notamment depuis le rachat de VMware.
A mon avis, ça ne va pas s'arrêter là. Ça fait partie des solutions de virtualisation qui sont de mon point de vue assez simples à mettre en place pour commencer à avoir notre propre décès virtuel.
Je pense que ce qui est plus simple à mettre en place que OpenStack, que j'aime beaucoup aussi.
Mais OpenStack, ça reste vraiment à des choses un peu plus envergues.
Proxmox, c'est quelques centaines de machines. Après OpenStack, c'est vraiment des data centers entiers.
Oui, ce n'est pas comparable.
Mais en tout cas, dans les solutions de virtualisation, ça se pose là. J'ai l'impression que ça marche très bien.
J'ai plusieurs personnes avec qui je discute qui me disent que Proxmox, ça marche super bien.
Alors moi, je suis un peu éloigné de Proxmox parce que j'ai décidé plutôt de m'orienter sur les conteneurs que sur la virtualisation.
Mais ça, c'est plus à titre perso. Mais il n'est pas dit qu'un jour, je n'utilise pas Proxmox pour divers besoins.
Pour ne pas faire de jalous, on va juste mentionner que c'est PNJ, qui est une autre alternative potentielle, qui est fait par une petite boîte française agronome.
Tout à fait. Mais est-ce que ça s'installe aussi facilement ?
Je crois que oui. J'ai jamais vraiment beaucoup investi de temps dessus, mais je crois que c'est assez facile.
Ils ont beaucoup travaillé en sens là. Et c'est de rendre les choses faciles à mettre en place.
Ça s'appelle Turnkey Solution. Donc, l'idée, c'est comme un coup de clé.
Pour moi, il n'y a pas de miracle. Si on veut que ces solutions-là soient utilisées, il faut qu'elles soient faciles à installer et qu'elles aient une API qui soit facile à utiliser et qui s'intègre avec Terraform.
On en a parlé tout à l'heure. Mais si on a une solution de virtualisation qu'on ne peut pas adresser automatiquement, on ne va pas trop les utiliser.
N'est-ce pas, Nicolas ?
Merci René d'avoir retrouvé le nom parce que j'étais en train de chercher.
Oui, effectivement, Christophe Tarezon, il faut que ça puisse être automatisé, automatisable et autant la partie d'éploiement que la partie d'utilisation.
C'est là où cette release-là sur la partie automatisation de l'installation est intéressante.
C'est quand vous avez 3-4 serveurs qui se battent en zone du L, ce n'est pas intéressant d'automatiser.
Mais quand vous commencez à avoir un parc avec une centaine d'hyperviseurs, tout ce qui est installé à la main, ce n'est pas possible.
Je sais qu'il y a des boîtes qu'il faut encore, mais ce n'est pas très dévops de faire encore des choses comme ça à la main.
En fait, Proxmox, le gros intérêt que j'y vois, c'est que c'est un petit peu comme les outils HECore, justement.
C'est facile à installer au début quand on n'y connaît pas grand chose.
On prend la galette de Proxmox, on installe son serveur, on a une URL en HTTPS, le guide d'un mot de passe.
Et à partir de là, on peut commencer à jouer avec.
Pour monter un lab ou un hyperviseur en entreprise, c'est parfait.
Mais vous avez aussi la possibilité de monter en gamme progressivement, que ça soit sur la partie sécurité.
Ce qui m'améliore, c'est le fait de pouvoir créer automatiquement des règles de sécurité entre vos machines et la reste du réseau.
Vous avez la possibilité de créer des velanes, vous pouvez mettre des sécurité groups.
Et ce qui est intéressant, c'est que vous pouvez aussi faire des règles tous vos Proxmox et créer des règles de sécurité.
Les sécurité groups, ils reprennent un petit peu la terminologie des autres clubs.
Et vous avez la possibilité de créer des règles au niveau de votre pool de serveur Proxmox.
Et finalement, les règles vont se propager une manière automatique dans tout votre pool de Proxmox.
Vous pouvez créer des data centers, c'est un petit peu dans tous les sens.
Et c'est ça qui est super intéressant, c'est que vous pouvez vraiment jouer à plusieurs niveaux.
Et quand vous voulez aller encore plus loin, vous pouvez mettre du stockage safe pour stocker vos machines virtuelles de manière distribuée pour faire du live migration et ainsi de suite.
Et Christophe, t'as interviewé une personne qui utilise du Proxmox à grande échelle.
Et ce podcast est super intéressant pour ceux qui voudraient en savoir un peu plus sur Proxmox.
Exactement, c'est celui que je mentionnais. Il est vraiment très intéressant. Il faut aller l'écouter.
Même si vous connaissez déjà Proxmox.
Ouais, parce qu'il y a des choses vraiment innovantes, je trouve.
Bref, je vous propose que l'on avance et pour avancer, il faut partager ce podcast.
Parce que, comme tu le sais ou pas d'ailleurs, ce podcast, il est libre lui aussi.
C'est un produit en licence libre puisque j'utilise la licence CC by SA.
Tu peux prendre des bouts, tu peux le diffuser, tu peux en faire ce que tu veux.
Par contre, tu dois citer la source. Tu dois dire que ça vient de Radio DevOps ou d'écompagnante du DevOps.
Si en plus tu viens nous faire un petit message soit sur YouTube, soit sur le forum en disant
« Hey, j'ai utilisé le podcast pour faire ça, ça nous fera énormément plaisir. »
Donc, je t'encourage à partager le podcast. Il est là pour ça.
Alors, René, c'est toi qui a la dernière news.
Ah, puisque, du coup, tu as deux news, ce mois-ci.
Ce que je n'ai pas vu une mois précédent, c'est pour ça que j'ai une deuxième news.
Non, on va essayer une toute petite news pour s'y signaler que les captations de DevOps sont en ligne.
Donc, DevOps, grosse conférence française sur Paris, on va dire plutôt orientée d'EV, mais on va dire tech assez généraliste.
Il y a l'air d'avoir des conférences intéressantes.
Par exemple, la présentation de Trify, je crois, pour savoir un peu ce qui arrive dedans.
C'est divers et variés. Je vous conseille d'aller voir, surtout pour découvrir par exemple des sujets.
Je pense que c'est intéressant.
Je trouve cool que cette grosse conférence fasse vraiment cet effort de publier les captations.
Alors, il y a plein d'autres conférences qui le font, mais là, je pense qu'il y a quand même un programme vraiment conséquent.
Et je pense que c'est un gros boulot pour ceux qui n'ont pas pu assister à DevOps,
ou qui n'aiment pas trop peut-être des conférences aussi grosses et aussi de masse.
C'est une manière de voir certaines conférences qui peuvent être chouettes.
Alors, j'ai des questions à poser. Déjà, est-ce que tu es déjà allé toi à DevOps ?
Nicolas, est-ce que tu es déjà allé à DevOps ? A moi, je n'y suis jamais allé.
Je ne sais même pas ce... J'en entends souvent parler, mais je ne sais pas quelle est l'ambiance là-bas.
J'ai pas encore eu l'occasion d'aller à DevOps, malgré l'envie assez importante.
Et pour être organisateur du Brest Camp, je vous confirme que mettre les vidéos en ligne, c'est pas facile.
Ça prend beaucoup de temps, c'est beaucoup de préparation, le jour j'ai beaucoup de problèmes à gérer.
Nous, Brest Camp, on a sous-traité une entreprise renaise qui nous aide énormément pour faire cette partie-là.
Et les années d'avant, on le faisait nous-mêmes et c'était encore plus galère.
Donc je confirme que faire des captations de qualité, c'est hyper galère et pour les mettre en ligne.
Donc merci à l'équipe de DevOps de faire cet effort-là parce qu'on apprécie énormément leurs vidéos qui sont de très bonne qualité.
Et toi, René, tu es déjà allé ?
Non, je suis jamais allé à DevOps et j'avoue que c'est un peu ce que je disais, c'est vraiment une grosse machine.
Bon, alors tu vas me dire que je suis jamais allé, donc c'est peut-être un peu baisse que je vais dire.
Mais j'ai l'impression que je trouve des conférences peut-être un peu plus petites, plus à taille humaine.
Je préfère peut-être ce format-là, ça se fait un peu... Il y a vraiment beaucoup de monde.
Il faut aller à Paris en plus.
Donc ça m'attire un peu moins que peut-être d'autres conférences un peu plus petites et un peu moins...
Enfin je ne sais pas si on peut dire mainstream mais peut-être il y a des acteurs un petit peu qu'on n'a moins l'habitude de voir.
Et puis, quelque part, comme ils font ces captations et les mettre en ligne, c'est aussi peut-être un moyen de voir les choses sans forcément y aller.
Après, c'est vrai qu'il y a l'aspect socialisation qui peut être sympa, mais voilà, sur une conférence aussi grosse.
Voilà, je suis un peu... ça me sent un peu moins.
Et qu'est-ce qui, selon vous, explique le succès de DevOps ?
C'est parce que moi j'en entends beaucoup parler. C'est une conférence de dev, on est d'accord, de développement.
De toute façon, il y a très peu de conférences plutôt orientées.
Il y en a vraiment peu. Il y avait DevOps Rex, qui n'existe plus.
Il DevOps d'Ed et à Marseille.
Mais qu'est-ce qui explique, selon vous, qu'on en parle autant ?
Ou de le fait que ça fasse 12 ans, je pense que ça existe.
Après, je sais pas, j'ai l'impression que toutes les cons ont vachement de succès.
A Grenoble et la Snow Camp, ça part très vite.
À DevOps, à l'origine, c'est pas mal orienté Java, mais ça aussi, c'est beaucoup ouvert.
Il y a quand même des sujets... aujourd'hui, je pense que ça parle de cubes, d'observabilité.
Je pense qu'il y a vraiment des sujets d'Ed.
On va dire, pur, il y a quand même des sujets plus ou moins infrarops.
Il y a aussi des sujets un peu sociétés autour de l'Atec.
Donc, non, je pense que même en tant qu'obs, on peut trouver des sujets.
Aujourd'hui, c'est suffisamment généraliste pour trouver un peu de tout.
Historiquement, DevOps, c'était Belch, le mémoire.
C'était une grosse conférence en anglais où beaucoup d'orateurs voulaient pouvoir aller.
Ça s'est disséminé un petit peu partout en Europe, notamment DevOps à Paris.
C'est une grosse, grosse conférence. Ils ont grandi avant, c'était au Marriott.
C'était pas assez grand. Ils ne sont pas les décongrés.
Ils n'ont qu'une partie du palais décongré à Paris, mais chaque année, ils rajoutent encore des salles.
Je ne sais plus combien il y a de participants, mais c'est énorme.
Je pense que si je dis 10 000 personnes, ce n'est pas déconnant.
Et pourquoi ça marche bien ? Parce que c'est une aura assez importante.
L'autorateur là-bas, c'est quand même assez prestigieux parce que la sélection est dure.
Il y a énormément de monde, ceux qui veulent se mettre en valeur pour eux ou pour leur société.
C'est un excellent endroit où ils y allaient.
Et après, il y a beaucoup de conférences qui essaient de reproduire à peu près la même chose un petit peu partout en Europe et en France.
T'as été ceux qui étaient à côté de chez toi, mais il y a Rivière-Adève qui fait toujours le plein.
Il y a le Breiscamp. Cette année, on rajoute quelques centaines de personnes parce que c'est toujours un petit peu dur de trouver des locaux et les logistiques qui va avec.
Mais on fait toujours carton plein aux taux de côté sponsor, orateurs, participants.
Et en fait, c'est un excellent moyen pour rencontrer les gens avec qui tu aimerais pouvoir discuter.
Parce que s'il t'aime voir les conférences, aller discuter avec les orateurs, c'est encore plus intéressant.
Parce que la question que tu vas poser sur YouTube, tu as assez peu de chance d'avoir la réponse.
Si tu oses aller voir l'orateur et lui poser la question, tu auras la réponse en direct.
Et c'est ça qui est super intéressant.
Et surtout, tu as tout l'écosystème qui ravait tout autour avec tous les participants.
C'est des gens qui font de même bouleaux que toi mais dans d'autres boîtes.
Et pour toute la partie networking, c'est super intéressant.
Moi, j'adore aller dans les conférences. Quand je vais dans une conférence, j'en vois aucune.
Par contre, je discute avec tout le monde.
Mais vu que j'aime bien parler, c'est l'endroit idéal pour moi. Je crois plein de gens.
Et René, l'année prochaine, on se retrouve au Fosdem.
C'est encore plus gros que D-Vox.
Et du coup, l'année prochaine, on pourra s'enregistrer un petit Radio DevOps en direct de Paris à D-Vox.
Mais pourquoi pas.
En tout cas, moi, je remercie aussi les organisateurs et organisatrices de ces conférences.
Puisque je ne me déplace pas souvent en conférence et de moins en moins.
Parce qu'à titre perso, je n'y trouve pas un plaisir grandiose à aller en conférence et voir plein de monde.
René, tu le disais, tu as des chiffres. Je vais te laisser la parole après pour que tout ne les annonce.
Mais moi, quand il y a trop de monde, je me sens mal à l'aise.
Et en plus, me déplacer pour aller à une conférence.
Typiquement, D-Vox, à Paris, je fais quatre heures de train.
Allez, quatre heures de train retour.
J'ai plus trop le temps. Mon boulot actuel ne me permet pas.
Par contre, aller voir les vidéos qui m'intéressent et aller picorer sur les vidéos, c'est vraiment super bien.
Et je remercie toutes les confes qui font ça.
Parce que, il ne faut pas oublier les gens qui sont loin et qui ne peuvent pas venir au moment ou qui ne peuvent pas ne serait-ce que prendre un ou deux jours
pour aller à la conférence mais qui sont intéressés par une ou deux vidéos.
René, t'as trouvé des chiffres. Est-ce que tu veux bien nous en parler ?
Oui, alors j'ai juste cherché très rapidement mais apparemment, tu as été un peu fort.
Je suis avec les 10 000 mais c'est 4 720 personnes sur trois jours.
La première vue est au 309 orateurs.
Ce qui se passe aussi, c'est qu'il y a un podcast, les podcasteurs.
Un podcast plutôt orienté de Java.
Les cascodeurs.
Merci.
Il y a beaucoup des cascodeurs, des présentateurs dans les cascodeurs.
Ils sont aussi organisateurs DevOps, des VOX.
Du coup, il y a une espèce de connexion.
Je pense que ça joue aussi sur un petit peu le succès de l'événement.
Quoi tu peux dire tous ?
Oui, je pense quasiment tous.
Après, il y a des personnes qui organisent, qui ne sont pas forcément dans les cascodeurs.
Mais en plus, qui sont des membres très actifs.
Mais je ne souviens pas de cascodeurs qui ne soient pas organisateurs de DevOps.
Je... peut-être.
Lançons un jeu triste si tu nous écoutes et que tu trouves un cascodeur qui n'est pas organisateur de DevOps.
Dis-le nous en commentaire.
Est-ce qu'on a encore autre chose à dire là-dessus ?
Si, juste un petit tout petit truc et une conférence.
Je ne suis jamais allé mais peut-être que c'est le hack aussi qui est assez intéressant.
Tu es connu et assez intéressant.
Et peut-être que comme Nicolas proposait qu'on a des VOX, on pourra aller aussi au hack.
Ou alors on se retrouve tous à Snocompt.
Parce que René et moi, on est dans Renalp.
On est un peu plus proches.
Et Nicolas, je sais que tu viens de temps en temps nous voir.
Peut-être qu'on se retrouvera ici.
En tout cas, toi, chère auditrice et auditeur qui nous écoutent,
sache que si tu veux discuter sans forcément aller vers ces grandes messes ou ces grandes conférences,
tu peux tout simplement nous rejoindre sur le forum des compagnons de DevOps.
Puisque c'est un endroit où on discute déjà depuis 6 ans.
Il existe depuis 2018.
Il y a de plus en plus de monde. Il y a TTF, il y a des Ops.
On papote de tout et de rien, de Kubernetes.
Surtout, on papote beaucoup de Kubernetes et de Docker.
On papote aussi pas mal de Terraform et de l'encibler de plein d'autres trucs.
Donc tu peux nous rejoindre.
Il suffit pour ça d'aller sur le site internet compagnons-devops.fr.
Tu t'inscrives et tu recevras ton invitation à créer un compte sur le forum.
Bon alors, ce que tout le monde attend, c'est les outils.
Et je vois qu'on a 3 outils alors qu'on a commencé l'épisode en enregistrant avec 2 outils.
Il y a un nouvel outil qui est venu s'ajouter au milieu.
Nicolas, le roi de la procrastination.
Écoute, Nicolas, c'est déjà mieux que moi qui en ai zéro.
Mais on va laisser la parole à René pour son premier outil.
Oui, le premier outil que j'ai trouvé assez sympa, c'est une API site web
qui s'appelle grep.app.
Et apparemment c'est un grep sur GitHub.
Donc avec une réactivité juste incroyable.
Je sais pas comment on s'est fait, je ne sais pas regarder plus que ça.
Mais voilà, c'est pour que nous aions un grep après en rajoutant des filtres, etc.
Pour sortir une chaîne de caractère, enfin, même un pattern, régulière expression.
Sur une grande partie de GitHub, je sais pas si il y a tout exactement,
mais il y a beaucoup de projets et j'ai fait quelques tests, ça marche assez bluffant.
Et ça peut être assez plutôt utile.
Je ne sais pas si vous connaissiez ce site, mais ça a l'air assez pas mal.
Non, je ne connaissais pas. En effet, c'est assez réactif.
J'espère qu'il va s'étendre à GitHub, parce qu'il y a quand même pas mal de choses sur GitHub.
J'ai à GitHub, c'est déjà bien. En effet, c'est très très réactif.
Effectivement, c'est hyper rapide. Il y aura encore un truc qui doit être développé en reste.
Je ne sais pas. En tout cas, c'est sûr, il doit utiliser la API,
faire avoir un moteur d'addexation, des trucs comme ça.
J'aime beaucoup la présentation.
J'ai beaucoup de bruitades sur le fait que ça soit un métier proposé par Roné.
J'avais bien compris, mais bon, je voulais pas relever le truc.
Justement, puisque tu as la parole, Nicolas, par toute ton outil.
Oui, je voulais vous...
Roné veut intervier.
Je voulais dire que pour une fois, je ne sais pas si c'est un outil restaupar.
Je n'ai pas pris exprès un outil. C'est plus un site web. Je ne sais pas ce qu'il y a derrière.
Je voulais vous parler d'Apetely, qui est un gestionnaire de repositorie et,
ou miroir, débian et ou Ubuntu.
Ça gère, en gros, les points d'oeuvre.
Si vous avez le besoin de gérer votre repositorie privée,
ou un repositorie publique, pourquoi pas.
Moi, je l'utilise dans pas mal de cas.
Ou même pour faire des miroirs de manière publique ou de manière privée.
C'est exactement ce qu'il vous faut.
Ce qui est super intéressant, c'est que, bon, il est développé en go.
Et comme tous les outils en go, il fait...
C'est le même binaire qui sert pour tout.
Vous avez la possibilité de vous en servir, comme d'une API,
soit juste un outil en ligne de commande.
Vous pouvez l'utiliser pour servir le repositorie,
ou alors gérer le repositorie que vous allez synchroniser ailleurs.
Ce qui fait que la partie qui génère le repositorie
est totalement découplée de celui qui sert les fichiers.
Bref, c'est un outil que j'ai rajouté dans ma boîte Outils.
Je m'en sers de plus en plus.
Je sais pas si vous connaissiez Christophe,
tu vois qu'il y a plein de machines dans tous les sens.
Tu dois bien en avoir un qui-chasse.
On n'est pas tant que ça.
Je connaissais parce que je m'étais intéressé au packaging, justement, débian.
Il y a longtemps pour une distribution,
mais je n'avais jamais mis en place de aptly.
Et c'est vrai que si je devais mettre en place soit un miroir, soit un dépôt,
j'utiliserais aptly.
René, tu connaissais toi ?
Non, pas spécialement.
Moi, je suis un peu plus du côté RPM.
Ben oui, on ne t'en veut pas.
Ah, écoute ça, qu'est-ce que tu veux ?
Eh ben, René, parle-nous de ton outil.
Dernier outil.
Alors, c'est...
Comment dire ?
C'est une espèce d'excuse juste pour faire mentionner la personne
qui a par qui j'ai eu ce lien.
Donc, en l'occurrence, c'est un tweet de Denis Baudor,
qui est le Redhack en chef de pas mal de petites résiditions Diamon.
Donc voilà, c'est pour te faire une petite promotion
des bouquins GNUG Linux Magazine, A Cable, etc.
Parce que je trouve que ça...
J'en avais déjà parlé à un moment,
je trouve que c'est des magazines de qualité.
Et cet outil, ça sert pas tous les jours,
mais donc c'est indispensable.
En fait, ça retrace, ça donne les câbles sous-marins
autour de la planète.
Alors, forcément, c'est pas hyper utile tout le temps,
mais ça donne une idée un petit peu des câbles sous-marins
qui relient les différents continents,
qui sont les potentiels propriétaires.
Pour connaissance ce personnage,
je trouve que c'était un site bien foutu, assez sympa,
et on a vite fait d'y passer un peu de temps
et à regarder.
Je trouvais sympa, donc j'avais envie de mentionner ici.
Tu fais bien, j'étais déjà tombé sur ce site, je sais plus comment,
et c'est en effet très éclairant de voir tous ces câbles sous-marins
et à voir quelles sont les connexions
entre les différents pays au niveau des câbles internet.
C'est effectivement impressionnant comme site.
J'aime beaucoup le fait que tu puisses faire transiter,
faire bouger ta map vers la gauche ou vers la droite,
et que ça soit un espèce de scroll infini à l'horizontale.
C'est intéressant, et c'est bien parce que j'avais un trou à faire
ce week-end dans mon jardin.
Je vais regarder si j'ai un câble sous-marin qui passe dessous.
Plus sérieusement, c'est marrant parce que tu parles des boutines
des éditions Diamond et j'ai failli en parler comme outil de l'épisode
parce que je lis très régulièrement Linux Magazine,
Rockabbles, c'est plus tout ce qui est IoT,
mais c'est intéressant aussi.
Et Myst pour la partie sécurité,
c'est pas toujours super intéressant,
j'ai été un petit peu délicieux ce mois-ci,
mais ça vous apporte une culture générale.
J'avais fait ma bonnée il y a quelques années,
et puis je m'étais dit, oui, mais en fait,
quand je veux creuser le sujet, je trouve les articles sur Internet,
et en fait, je me suis rendu compte que ça m'a porté aussi de la veille,
parce que les sujets abordés sont quand même assez divers,
et je trouve ça intéressant comme magazine.
Bon, et René, tu voulais finir ?
Non, bon, toi qui nous écoute, si tu apprécies nos outils,
sache qu'on en a parlé de tout un tas d'autres,
je ne sais pas combien on en a, mais beaucoup.
Et justement, on les a en grande partie référencés sur le site,
on doit continuer le référencement sur le site Internet.
Donc, si tu vas sur le site Internet,
compagnons-tiretdvops.fr,
tu trouveras le petit onglet pour aller voir les outils,
et normalement, tu tomberas sur tous les outils dont on a parlé.
C'est une base de données assez intéressante pour toi,
pour trouver des outils à utiliser,
qui soient plus ou moins gros, ou quelques petites choses aussi.
Et là, on essaie de les classer par type.
Donc, les choses avancent petit à petit.
Et le dernier truc que j'ai à te dire,
si tu nous regardes sur YouTube,
tu peux avoir le swag des compagnons.
Si tu ne nous vois pas,
tu ne vois pas le super suite que j'ai,
c'est le suite classique.
Je suis en train de chercher les noms
des divers produits qu'on va vendre.
En tout cas, on va lancer la boutique cette année,
tu peux t'inscrire à la liste d'attente,
et tu auras une réduction au lancement de la boutique,
tu seras prévenu avant tout le monde.
C'est justement le premier lien en description.
Tu vas pouvoir y arriver,
et tu pourras plus tard regarder ces t-shirts,
ces suites et autres petites choses.
Alors, moi je te remercie pour ta patience,
toi chère auditeur et auditrice,
puisque mine de rien,
on pensait que ce serait encore un épisode court,
parce qu'on s'est dit,
oui, il n'y a pas de grosse news cette fois-ci,
on est encore à 1h25,
donc comme quoi, on est des bavards,
surtout tous les trois.
Donc je vais laisser la parole à mes chers co-podcasters,
qui vont clôturer ça avec leur mot de la fin.
Nicolas, je te laisse la parole.
Ben ça y est, je ne sais plus quoi dire,
n'optibilisez pas de manière trop anticipée.
Eh ben, j'espère que vous faites rester dans le classique,
que vous avez apprécié cet épisode.
Je vous en rendez-vous pour le prochain épisode,
et si je creuse un trou dans le jardin,
à Grenoche, je ne pense pas que je vais trouver de cap sous ma rame,
mais je ne sais peut-être pas,
si je n'ai rien à faire, je vais essayer.
Allez, à bientôt.
Si tu as envie de discuter du mouvement,
alors rejoins-nous dans la communauté des compagnons du DevOps.
À bientôt.
La balade aux diffusions des compagnons du DevOps
qui est produite par l'Hydrat.