Bienvenue sur le podcast Artisan Developer,
l'émission dédiée au programmeur,
qui parle de techniques bien sûr,
de codes durables,
mais aussi du métier en lui-même,
de recrutement, de développement personnel,
ou encore d'entrepreneuriat,
pour t'accompagner dans une vie de développeur épanouissante.
Alors,
est-tu prêt à passer au niveau supérieur ?
C'est parti !
Aujourd'hui je suis avec Victor Mignot,
de chez Octo Technologie.
Victor bonjour.
Bonjour.
Octo qui est notre sponsor de la semaine,
merci les gars pour votre soutien,
c'est super important pour aider à développer ce podcast.
Merci encore.
Et puis il y a cette question dans la reine aussi,
préfère-tu développer ta polyvalence ou ton expertise ?
Et justement Victor,
tu arrives avec un angle que je trouve assez original.
Est-ce que tu peux déjà te présenter,
c'est la première fois que tu passes sur le podcast,
en une minute, qu'est-ce que tu fais aujourd'hui ?
Alors, en une minute,
ce que je fais aujourd'hui au sein de Octo Technologie,
c'est du dévost principalement,
donc avec comme d'habitude chez Octo,
de valence, le conseil,
où on va se retrouver à faire des audits,
on va aller voir un peu ce qui se passe dans les entreprises,
et essayer de repérer les points bloquants,
donc spécialement dans le délivrer d'un produit,
les points de friction,
et essayer de les aider et les éliminer,
souvent à travers de réorganisation ou d'outils, etc.
Et à côté de ça,
je suis à même de développer souvent ces solutions qu'on propose,
puisqu'on essaye de faire beaucoup d'automatisation,
avec tous les outils d'automatisation des Vops qu'on retrouve,
on part sur le cloud, etc.
On monte des architectures un peu novatrices,
avec tous les produits dont on entend parler un peu souvent,
donc les clouds et les conteneurs.
OK, et justement par rapport à la question de la battle,
tu as amené un regard que je trouvais intéressant
sur le rôle du DevOps dans la feature team,
est-ce que tu peux élaborer un peu là-dessus ?
Ouais, sans problème.
Dans une feature team,
souvent on va démarrer un projet avec un DevOps
qui va être assez central, surtout au début,
c'est-à-dire qu'on a une équipe qui a besoin d'une infrastructure,
la plupart du temps, dans le cadre d'un DevOps dans une feature team,
qui a besoin d'une infrastructure et d'un process de livraison.
Et ça, c'est quelque chose qu'on doit faire très rapidement.
Donc le DevOps souvent va mettre en place
son infrastructure limite en boîte noire,
et l'équipe de développeurs va plus se retrouver
à faire des features bien normées,
avec les user stories, avec de la valeur métier, etc.
Ensuite, il y a une phase qui devrait être importante
et qu'on oublie souvent, qui va être un peu cette phase,
où OK, le DevOps, il a mis en place des trucs,
des pipelines, des beaux tests automatisés,
une belle infrastructure, du beau monitoring,
mais en fait les développeurs,
ils sont encore et toujours dans leur production de valeur,
et donc se transfère de savoir parfois peut être un peu oublié.
OK, mais du coup, effectivement, il arrive avec cette expertise,
il met tout en place.
C'est vrai que moi, souvent, en tant que développeur, la plateforme,
il y a une affinité, il y a un plaisir dans ma première vie professionnelle.
Je faisais à la fois le dev et la partie 6-7000,
mais déjà, ce n'est pas forcément le cas de tout le monde,
de garder une certaine curiosité vers ça.
Et puis c'est vrai que souvent,
moi, en tant que dev, on a tendance à considérer tout ça
un petit peu comme des plateformes à ce service,
le DevOps, il nous livre un truc un peu magique.
Déjà, quand il est impliqué dans l'équipe dès le départ,
je trouve ça super et pas si répandu que ça, en fait,
déjà l'impression.
Mais du coup, imaginez-vous ce cas-là,
le gars, il vient d'arriver,
il a mis en place sous de l'infra, un peu en boîte noire, comme tu disais.
C'est quoi la suite logique ?
Comment est-ce qu'il fait pour...
Ça serait quoi ?
Ça serait de transmettre ça au dev pour qu'il soit autonome,
au moins sur des actions de base, c'est ça ?
Et comment il le fait ça ?
Alors, oui, c'est clair que c'est compliqué.
Je vais revenir sur la partie où tu dis qu'il faut trouver quelqu'un
qui est intéressé déjà,
parce qu'effectivement, en fait, de toute façon,
on ne peut pas forcer quelqu'un à s'intéresser au système
qui est quand même un port assez particulier de l'informatique.
Aujourd'hui, quand même, avec several DevOps,
on se retrouve à avoir une abstraction,
quand même, autour de tout ça, qui est plus ou moins...
Enfin, on a moins besoin d'avoir des connaissances en réseau, etc.
Quand on a une plateforme qui marche.
Donc ça, c'est quand même assez positif.
Mais c'est vrai que moi, ce que je dis souvent,
c'est quand même ce qui différencie pas mal.
On va dire un 6nm d'un...
Enfin, un ops, c'est pas non plus qu'un 6nm, d'ailleurs.
Car qu'un développeur, c'est quand même un moment donné,
il y a la prod, puisqu'on se retrouve beaucoup à avoir des développeurs
qui n'ont pas accès à la prod pour des raisons
qu'on nous présente parfois comme légales
ou pour des raisons qu'on ne sait pas expliquer.
Mais donc, il y a cet ops qui a cette vision de la prod.
Et c'est ça qui le différencie.
Donc il faut quelqu'un qui envie d'aller au-delà du fait
que ça marche bien sur sa machine.
Et de se poser des questions de haut de dispo,
de comment on construit une architecture.
Qu'est-ce que ça veut dire les conteneurs ?
Est-ce que c'est juste...
Enfin, quelqu'un qui ne verra par exemple pas l'intérêt du cloud,
pas l'intérêt des conteneurs, en fait, je pense qu'on ne peut pas le forcer.
Ça, c'est sûr.
Mais ça ne fera pas un bon candidat à un transfert de connaissance.
OK. Et maintenant, imaginons que dans l'équipe,
on ait identifié des gens qui soient intéressés ou curieux de ce truc-là.
Comment est-ce que tu as sûr la montée de compétences
pour atteindre un niveau suffisant pour que le jour où le DevOps
soit pas là pour une raison X ou Y,
l'équipe soit capable d'avoir un certain niveau de service quand même ?
Pour moi, il y a pas mal de moyens au-delà du moyen technique
sur lequel je reviendrai après de comment on fait, effectivement,
pour une passion de connaissance.
Je dirais que le premier moyen, ça va être de les intéresser
à ce qui touche à leur application.
Donc, par exemple, à tout ce qui va être observabilité
autour de leur application.
Donc, si on leur donne une stack de monitoring un peu efficace,
ça, ça va les intéresser.
C'est débile, par exemple, de faire des tests de perf
et leur montrer les courbes qui saturent sur le monitoring un peu systéne.
Et ça, ça plaît à tout le monde, normalement.
À part si c'est une application vraiment compliquée,
ils vont se dire, oh merde, je vais devoir aller dedans
alors que j'ai pas envie.
Pourquoi cette mémoire ?
Oui, mais là, t'as d'autres problèmes à régler avant, je pense.
Que ton problème de perte ?
Exactement.
Non, ça peut être un truc marrant.
Donc, voilà, des tests de bêphes qui font des erreurs 500,
passer un certain nombre.
BAM, enfin BIM, on leur montre,
oh, regarde, les logs, tu peux les voir sur cette plateforme.
Voici comment tu fais tes recherches.
Tiens, là, il y a un moment donné où en fait,
il y a une connexion qui se refuse.
Qu'est-ce que ça veut dire ?
Pourquoi est-ce que des pertes font que tu as du mal à communiquer ?
Enfin, pourquoi est-ce que de la charge fait que tu as du mal à communiquer
avec ton Rédis ou avec ta base de données ou avec ton API ?
Et on va se poser des questions comme ça.
Donc là, en fait, ce qu'est-ce que c'est ?
C'est tout simplement du, enfin, faire à plusieurs,
donc Péré ou Moby, le père, en binôme et le mob en groupe,
donc faire des ateliers en fait,
où on se pose, enfin, on se pose à plusieurs les questions qu'on devrait se poser.
Et ça parle d'un milieu qui connaît,
puisque c'est le code qui est fait au même, quand même, la plupart du temps.
Et après, par contre, on les attire discrètement vers le côté un peu sombre.
Donc tiens, c'est une base de données, c'est une limite de connexion.
Et en fait, tu les libères pas ou tu les recycle pas,
tu les laisse ouvert trop longtemps.
Et donc, en fait, au bout de 200 poufs, on craque.
Et oui, pourquoi ?
Qu'est-ce que c'est que des connexions ?
Qu'est-ce que c'est qu'un pool ?
Etc. Etc. Etc.
Et donc là, on l'a attiré vers la tenante système un peu de l'histoire.
Par le côté, regarde, si je pousse un peu le truc dans les retranchements,
regarde ce que ça donne.
En plus, aujourd'hui, quand même, là, j'y pense, avec les tests de perte,
par exemple, les tests de perte,
aujourd'hui, on peut les faire avec des outils.
Je me souviens, on utilisait beaucoup de gattling,
on utilise encore beaucoup gattling.
Mais là, j'ai essayé par exemple, Artillery.io,
qui est en fait du YAML et du JavaScript.
Donc ça, quand même, pour un développeur Node.js, par exemple,
ou un développeur, on va dire un peu,
qui a un peu les langages un peu modernes.
Enfin, je vais pas dire ça,
puisque ça sous-entend le gattling,
du coup, le Scala, il est pas moderne.
Mais bon, c'est plus agréable, je pense, de connaître un test de perte
avec Artillery, par exemple, qu'avec des outils qu'on avait avant.
Et du coup, la barrière à l'entrée,
elle est quand même plus faible.
Le coup à l'entrée est quand même plus faible.
OK. Et justement, pour aller au-delà de ça
et augmenter encore la transmission,
qu'est-ce que tu vois comme autre outil ?
Alors, je vais essayer un peu de sortir des sentiers battus.
On va dire, c'est-à-dire que, au-delà des formations, des trucs comme ça,
il y a quelque chose que j'aime bien.
Moi, j'ai vu, nous, qu'on fait pas mal.
C'est ce qu'on appelle des espèces d'exercices d'investigation ou des WarGames,
comme ça se voit.
C'est-à-dire qu'on va préparer une vème où il y a quelque chose qui est caché.
Et on va demander et on va montrer à la personne,
en fait, comment c'est censé marcher.
Donc, typiquement, j'ai deux applications,
enfin, j'ai deux vm, une qui fait proxy,
réverse proxy et l'autre qui est mon amour à ma vraie application
et pourquoi pas une base de données.
Donc, je montre que cette application est dit hello one,
elle compte le nombre de fois où je vais sur la page.
Et après, je lance un petit script qui va casser mon explication, en fait.
Par exemple, qui va remplir le disque.
Le disque qui remplit, c'est, à mon avis, le problème numéro un,
rencontrer à gauche, à droite, par des gens qui gèrent des serveurs quand même.
Numéro un, dans le sens où c'est celui qui leur arrive le plus souvent
dans des affrains un peu classiques.
Et nous, on va leur faire un exercice comme ça.
On va leur dire, voilà, maintenant, tu as un accès à la vm.
Viens, on va ensemble, enfin, tu as le clavier et tu peux me poser des questions.
Mais moi, je vais fermer ma bouche et on va voir comment tu t'en sors.
Oui, donc c'est vraiment des mises en situation.
Tu casses un truc et tu vois comment l'autre s'en sort.
Oui, en fait, c'est l'inspiration.
On s'est demandé à mon donné comment pour donner de la connaissance
à des développeurs juniors, on fait souvent des gâthes, des dojos,
enfin, donc des exercices un peu comme on appelle ça,
canonique d'entraînement.
Ouais, exactement, de code et comment ça se fait que c'est rare de trouver ça
pour de l'ops, qu'est-ce qui rend ça si difficile?
Souvent, c'est quand même qu'il faut une affra.
Mais aujourd'hui, l'infra, ça coûte pas cher, puisqu'on a des machines virtuelles
ultra faciles avec soit du cloud, soit même du vagante,
on ne demande pas, on ne demande pas la lune ou du docker.
Enfin, tout ça, en fait, ça coûte pas cher, puisque c'est gratuit.
Donc maintenant, en fait, on est capable de faire
ces petits exercices d'investigation pour transmettre du savoir.
Et au fur et à mesure de l'exercice, on fait pause, on fait,
ah, là, c'est intéressant.
Par exemple, je pars, on s'amuse à faire une application qui essaye de démarrer
sur un port qu'est-ce que j'ai occupé.
On me pose, on explique qu'est-ce que c'est que les ports, comment ça marche,
etc., etc. Donc on peut rentrer vraiment profond dans le système
à partir d'un problème que normalement, beaucoup de développeurs rencontreront.
À vain, encore une fois, là, je parle d'infra classique.
Mais en fait, des ports qui sont déjà occupés, bon, on retrouve ça.
On retrouve ça quand même.
Les histoires de ports, on retrouve ça encore dans les infras de conteneurs.
Donc c'est quand même quelque chose que beaucoup de développeurs,
le réseau, par exemple, pour citer un élément qui fait peur
à beaucoup de monde parce que ça peut être compliqué.
Mais le réseau, ça peut être passé sous silence de nombreuses fois
par pas mal de gens.
Et pourtant, c'est dommage parce que le réseau n'est pas fiable.
Le réseau, c'est une donnée dans ce qu'on va dans notre application.
C'est quand même rare, maintenant, les applications qui utilisent pas le réseau,
qui communiquent pas avec l'extérieur d'une manière ou d'une autre,
ou avec un système de fichier, par exemple.
Et donc, il faut quand même avoir un minimum de connaissance là-dessus,
voir que quand il y a tel message d'erreur, ça veut dire
« Ah, OK, le port est déjà pris. »
Ou « Ah, OK, en fait, je me suis mis sur la mauvaise interface réseau. »
Au moins savoir qu'est-ce que ça veut dire les interfaces réseaux
et que, historiquement, ça vient du fait qu'on mette des cartes réseaux, etc.
Eh ben écoute, je trouve ça super intéressant et je te propose que ce soit le mot de la fin.
Merci, Victor, d'être venu aujourd'hui.
Je t'en prie.
Quant à toi, chère auditeur, je t'invite à nous rejoindre dans l'AREN,
aren.artisan-développeur, pour répondre à cette question.
Préfère-tu développer TAPOLI Valence ou ton expertise ?
Je te dis à tout de suite.