Bienvenue sur Double Slash, le podcast dédié aux outils et aux techniques pour le développement
web.
Bonjour à tous, bienvenue dans cet épisode où on va parler de DevOps avec Patrick comme
toujours.
Salut Patrick ! Salut à tous !
Et on a un invité, Patrick Christophe Chaudier qui a eu aussi une chaîne sur le DevOps,
les compagnons du DevOps qui est un podcast.
Salut Christophe !
Salut !
Nous ici on a plutôt la culture de parler du front du bac, mais je crois pas qu'on
a déjà invité quelqu'un pour nous parler un petit peu de cette culture DevOps.
Alors nous on est un petit peu novice là-dedans, peut-être avant de plonger dans le cœur
du sujet, de savoir c'est quoi le DevOps, c'est quoi cette culture, la définition
exacte.
Est-ce que à la limite tu peux peut-être te présenter, d'où est-ce que tu viens et
pourquoi aujourd'hui tu fais du DevOps ?
Oui, je vais essayer de faire court.
D'où est-ce que je viens ?
Alors j'ai commencé ma carrière avec le bug de l'an 2000, j'aime bien dire ça parce
que pour ceux qui ont connu c'était un événement important.
Au début j'étais un développeur bac et puis après je suis rentré dans les SS2E, puis
j'ai fait beaucoup de prestations et je me suis mis à faire du déploiement d'applications
de plus en plus.
Et j'ai senti dans les grandes boîtes, parce que je suis passé par rapport à toutes
les grandes boîtes, le problème entre les développeurs et les ops, les fameux administrateurs
système, administrateurs cloud, il n'y en avait pas encore etc.
Et les problèmes qu'on avait entre nous, les problèmes entre services etc.
Et aux entoures de 2010-2012, je me suis posé des questions justement sur comment
est-ce qu'on peut fluidifier tout ça.
Et à ce moment-là, j'ai décidé de devenir frélande.
C'est là où j'ai découvert le DevOps dans la thématique et j'ai décidé de devenir
administrateur système cloud pour vraiment aider les entreprises à faire du développement
et du déploiement surtout.
Et aujourd'hui, je ne fais plus ça puisque aujourd'hui je suis CTO et Product Honour
d'un sas qui s'appelle Frogit, qui est un concurrent de GitLab et de GitHub pour
faire simple.
C'est David Cotrogoliet.
Je fais aussi du Montorail, de la formation autour du DevOps et de Git et de GitLab
de manière globale.
Ok, Frogit c'est un service qui est français ?
C'est un service qui est 100% français, qui est bergé en France dans des assassinateurs
français puisque nos fournisseurs sont Skaalway et OVH et d'autres parce qu'on a plusieurs
hébergeurs.
Super.
Ok, tu parles de DevOps, de déploiement, tout ça.
Souvent en fait c'est un mot un petit peu fourtou le DevOps.
Est-ce qu'on pourrait peut-être un peu clarifier les choses ou au moins donner ta version,
toi ta définition du DevOps c'est quoi ?
Oui, ça te rend bien parce que j'ai une définition que je donne dans les formations.
Ma définition c'est celle-là, le DevOps c'est un mouvement et une philosophie qui
vise à faire collaborer les équipes IT pour améliorer en continu les outils d'entreprise.
J'aime bien cette définition parce qu'elle parle des gens et des gens qui font l'entreprise
parce que souvent quand on va chercher des définitions DevOps, on parle pas des gens
et il n'y a pas cet aspect de faire collaborer les équipes.
Et honnêtement le DevOps c'est vraiment un mouvement et une philosophie qui vise à
ce que les équipes de développement et les équipes d'exploitation qui sont les personnes
qui gèrent les infrastructures et qui déploient les applications qui sont développées par
les équipes de développement, et bien que ces deux populations-là, elles se parlent,
elles collaborent et surtout qu'elles arrivent ensemble à travailler et à améliorer en
continu que ce soit l'outil informatique, l'application ou l'infrastructure.
Il y a cette notion-là d'amélioration continue d'automatisation qui transparaît
en fait dans le mouvement DevOps.
Ok parce que moi je pensais que c'était vraiment du déploiement, c'est-à-dire
comment je vais distribuer mon applicatif à travers une infrastructure.
Mais toi elle est beaucoup plus, on va dire un peu métal, c'est beaucoup plus englobant parce
qu'il y a cette culture, cette philosophie d'entraide autour du logiciel, ok c'est beaucoup plus
puissant pour le coup.
Oui parce que souvent en fait la plupart des boîtes en fait elles ne pensent qu'au
déploiement parce qu'en effet c'est ce qu'on appelle un quick win c'est pour accélérer ton
déploiement et pour réduire ton time to market, je pense que ça parle à tout le monde
au time to market sinon je peux le définir, mais pour réduire ce time to market là tu
vas utiliser des méthodes de déploiement automatisé et souvent c'est ce qui est mis en place,
c'est ce qui est mis derrière le mot DevOps.
Mais le DevOps ça ne se limite pas qu'à ça parce qu'après derrière une fois que
tu as mis en place ton application, il faut la mesurer, il faut vérifier qu'elle ne s'écroule
pas, que les pertes soient bonnes, il faut la corriger, il y a plein de trucs dans le
cycle de vie de l'application, il n'y a pas que le déploiement.
Il y a aussi la communication entre les devs qui expliquent que notre avelle fait ça,
on a besoin de ça etc. et puis la personne qui va dire ok le serveur il faut qu'il fasse ça
parce que sinon ça va pas bien fonctionner etc. c'est aussi la communication des fois
qui ça aide aussi beaucoup non c'est ça, c'est un peu le développeur à pinesse en fait.
Exactement mais moi c'est comme ça que je me vois, c'est comme la personne qui va aider son
équipe de développement, souvent moi j'étais le seul ops dans les équipes de développement
parce que quand j'ai commencé à faire justement être freelance, je m'adressais à des gens qui
avaient des applications assez grosses pour faire appel à des ops mais pas assez grosses pour avoir
une pêleté d'ops à disposition donc du coup j'étais intégré dans l'équipe de développement
en tant qu'ops et mon rôle était de leur faciliter la vie, de leur faire comprendre c'est quoi en fait
la vie d'une application en production parce qu'il y a ça en fait quand on développe souvent
on n'a pas cette vision là de la production on sait pas trop ce que c'est et aussi de les aider
avec des outils parce que moi je suis un ops qui est un ancien développeur et du coup j'aime
encore cette partie automatisation c'est un des trucs que je préfère et du coup je trouve que mon
rôle d'ops et de développeur d'infrastructure il y a beaucoup de personnes qui utilisent ce
terme là et ben je le préfère à mon rôle de développeur d'avant. Ok donc en fait c'est vraiment
des à disposition des équipes frontes ou back pour pouvoir en fait mettre à profit tout leur travail
le rendre accessible dans la main des utilisateurs finaux le plus facilement et le plus simplement
possible avec le moins de friction possible quoi. Exactement, il y a ça et puis il y a aussi
des utilisateurs quoi. Améliorer leurs outils au quotidien pour qu'ils aient un environnement
de travail le plus proche possible de la production. Oui ça c'est vraiment ça c'est vrai que putain
tu veux en tant que dev tu peux vraiment vite perdre du temps sur le déploiement tout ce qui est
tout ligne en fait à le configurer et c'est quelqu'un qui le fait à ta place c'est génial en fait.
Oui et puis il y a ça puis il y a la standardisation parce que mine de rien enfin vous êtes des
développeurs front donc ça veut dire que vous avez utilisé npm et les jsonne et tous ces trucs
là en fait ça existe dans toutes les dans tous les langages et si on prend pas l'habitude de tout
standardiser et d'avoir des environnements qui se ressemblent alors je parle des entreprises
parfois qui peuvent avoir plusieurs applications qui se ressemblent si du standard si du standardise
pas chaque équipe va faire à sa manière et du coup ton entreprise elle va se retrouver à voir
ah bah tel application nod elle est déployée comme ça tel autre application nod elle est
déployée différemment etc et après tu as plus d'uniformité alors qu'en fait si tu arrives à
uniformiser les choses et à les automatiser bah tu vas gagner du temps global dans l'entreprise
et donc de l'argent évidemment. Et est-ce que toute cette culture de mono ripo elle est
elle s'inscrit dans cette démarche là justement de tout centraliser pareil avec les workspaces
pour justement toutes les arbres de dépendance le limiter au maximum est ce que tout ça ça
s'inscrit aussi dans dans cette culture de simplification pour le développeur et donc ça
rentre en fait dans ton scope et dans ton giron. Alors le mono ripo en fait c'est chaque chaque
entreprise et chaque équipe qui va trouver son mode de fonctionnement j'ai tendance à dire souvent
il n'y a pas une manière de faire le DevOps c'est chaque entreprise elle doit trouver sa manière
par contre il y a des préceptes à aborder c'est à dire en effet la question c'est est-ce qu'on
va aller vers un mono ripo est-ce qu'on va aller vers plusieurs ripos et une fois qu'on a fait notre
choix en fonction des critères il faut qu'on le partage au sein de l'entreprise il faut que toutes
les équipes elles puissent aller là mais il n'y a pas vraiment de comment dire le grand.
Il n'y a pas de méthode en fait il n'y a pas une méthode DevOps il y a vraiment plusieurs méthodes
il y a des bonnes pratiques et en fonction des résultats qu'on veut obtenir il y a des choix à
faire et le mono ripo ou pas c'est un sujet que nous animons évidemment mais on n'a pas tranché
on n'a pas tranché. Moi justement j'ai une question la petite je t'ai vu un petit peu mais
alors on parle de mono ripo est-ce que tu... moi j'ai l'impression que le serveur less là les gens
sont un petit peu revenus et reviennent vraiment sur du mono ripo un peu plus classique un peu plus
basique en fait est-ce que tu as cette impression est-ce que tu vois ce phénomène en fait le serveur
less c'est trop compliqué en fait de tout séparer en différents trucs on revient sur un mono ripo c'est
plus simple. En fait tu peux faire du serveur less en mono ripo à partir du moment où tu
fonctions tu les as mis quelque part dans ton mono ripo en fait le serveur less c'est juste tu crées
une application qui est événement ciel et donc après faut gérer tes événements et puis surtout
faut que bah faut que ton infrastructure enfin plutôt que ton architecture d'application elle
soit bien pensée le serveur less c'est bien pour faire des trucs à l'événement justement mais
après pour faire toute une application je sais pas honnêtement le serveur less à part pour faire
des pour traiter des événements puisque nous on a pareil typiquement pour frogit on utilise make
qui est un outil no code et du coup ça on pourrait faire des fonctions serveur less ce serait
pareil on a décidé de faire du no code mais pour certains trucs en fait typiquement il y a une
prise de commande hop on va créer un utilisateur dans notre sas et ben on va passer par ça on
pourrait faire une une fonction serveur less mais après est-ce que toute une application elle peut
être en serveur less ça dépend vraiment des applications ça va être le métier qui va plutôt
dicter les bonnes pratiques est ce que c'est est ce que le métier est adapté à ce type d'architecture
en serveur less ou pas quoi mais après c'est comme on va organiser notre code voilà telle instance
va être montée mais ça c'est plus sur le versioning de notre code base est-ce qu'on
centralise tout sur un sur un monoripo ou pas quoi ça ça va être des choix stratégiques de la
boîte quoi oui puis ça ça peut très bien tu peux très bien avoir un monoripo pour plusieurs
équipes c'est pas gênant à partir du moment où toutes les équipes partagent le même flux
de développement et qui n'est pas de soucis en fait et qu'après tu peux avoir un monoripo avec
des répertoires séparés en fonction des domaines métiers je sais pas alors je suis pas très monoripo
mais bon ah ouais tu n'es pas très monoripo parce que la légende magique google a un seul
répertoire pour tout leur service en fait alors je sais pas si jamais vu mais il paraît que google
a un seul répertoire en fait je sais pas comment ils font moi je même moi dans des petits dépôts
j'aime bien créer des répertoires ouais donc j'aime bien ranger les choses et non mais ça
se tient carrément tu disais tout à l'heure que tu tu travailles avec différentes équipes avec
différentes boîtes et tu as travaillé avec différentes tailles d'équipe justement à partir
de quel moment on peut dédier du temps à un poste de DevOps pur où la personne est vraiment
dédiée à la mise en place de justement de tous ces environnements pour fluidifier un petit peu
tout ça est ce qu'il ya des des seuils critiques pour dire ok à partir de x nombre de développeurs
en fait la collaboration va devenir beaucoup plus compliqué donc il est recommandé en fait de peut
être dédié un peu de temps à ça est ce que tu as ce genre d'information quand même pas du tout moi
j'aurais tendance à dire déjà quand les gens viennent me voir souvent ils me demandent quand les
start-up elles viennent me voir elle m'a dit ouais je voudrais passer sur Kubernetes etc donc je
suis un peu c'est souvent ça c'est à vous déployer Kubernetes donc je sens un peu les
besoins et souvent je m'aperçois qu'il pourra aller typiquement sur un pass platform as a service
type cléver clod et recours etc donc je leur conseille plutôt d'aller là dessus et en fait à partir
du moment où les applications ont beaucoup d'utilisateurs et comment ça a des problèmes de
performance c'est là où justement tu devrais aller voir un ops parce que il va falloir commencer
à faire des stats à aller chercher pourquoi est-ce que tu as des problèmes de performance
commencer à architectureer ton application et donc aller soit vers du micro service soit
externaliser certains trucs et penser pour le coup l'architecture de ton application et non plus
comme un truc en effet monorepo que tu vas déployer on passe c'est à mon avis c'est quand tu
commences à avoir des problèmes de performance que tu dois t'adresser à un ops parce que lui il a
l'habitude de ça ok mais est-ce que justement c'est pas alors c'est la poule ou l'œuf mais en
fait est-ce que c'est pas déjà un peu trop tard quand tu te rends compte que t'as des problèmes de
perf et peut-être que toi tu vas arriver en disant à les gars vous avez fait n'importe quoi et donc
il faut tout reprendre est-ce que on pourrait dans un monde idéal anticiper cette cette montée en
charge d'ops et en fait penser là le service le l'application métier directement à sa conception
en disant bah les best practices des vops même si on est que deux aujourd'hui où on a très peu
d'utilisateurs on va respecter et on va mettre en place ces best practices des vops qui vont
nous permettre de main en fait de plus facilement ce qu'elle est est-ce que ça c'est possible ou pas
alors ouais c'est possible seulement en fait si tu penses tout de suite à concevoir une application
qui va se quitter dans l'avenir tu vas faire des dépenses pour se quitter alors que tu sais
pas si tu vas avoir besoin de se quitter je te prends un exemple tu es dans une dans un moment où
tu as monté une start-up tu crées à ton produit sauf qu'en fait ça se trouve dans un nom ton
produit sera mort parce que d'aura pas son client et puis tu vas mettre la clé sous la porte est-ce
que le plus important c'est de faire de l'argent et donc de mettre à disposition ton produit pour
le vendre ou est-ce que ta priorité c'est de penser au futur scale qui va avoir lieu et donc de
retarder encore ta mise à disposition du produit et pour nous dans le mouvement des vops il y a moi
je le rappelle à chaque fois que je fais des formations c'est le retour sur l'investissement il
doit être dans notre tête constamment parce qu'on est là quand même pour que l'entreprise elle
gagne de l'argent puisque l'entreprise nous paye et nous ou alors nous nous contracte parce que
quand on est frilance et donc le but du jeu quand même de l'entreprise c'est qu'elle gagne de
l'argent donc le retour sur le vétissement il doit toujours être là et donc on doit toujours
faire des petits pas pour atteindre notre objectif mais sans forcément se projeter trop loin parce que
sinon le retour sur l'investissement il ne sera pas là tout de suite alors rien ne nous empêche de
mettre en place des bonnes pratiques mais là j'ai envie de dire c'est plutôt un travail personnel de
chaque développeur et développeuse et puis de l'équipe de s'auto-former aux bonnes pratiques et de
les appliquer tout le temps en fait parce que en fait le dévops ça a un mouvement je ne l'ai peut-être
pas dit mais c'est un mouvement transverse et donc on a des ops dévops c'est pour ça que je parle
d'ops on a des ops d'administrateur système des administrateur cloud dévops et on a des devs
dévops qui sont aussi dans cette philosophie et pour moi c'est un truc transverse cette philosophie
ok après donc si on essaye de résumer faut pas aller trop trop vite et faut pas mettre des usines
à gaz sous prétexte que peut-être un jour on va scale quoi donc c'est approche incrédentale et on
fait quand on a besoin quoi dans le développement c'est la même chose quand tu développe quelque
chose tu ne vas pas penser à des choses qui potentiellement vont évoluer non tu fais la fonction
que tu as besoin au jour le jour et puis après tu fais évoluer quoi mais par contre ça comme tu dis
c'est aussi important d'avoir quelqu'un comme toi au début à je vais les surcubernities à
non mon gars attend là tu t'emballes non ça ça va te suffire c'est quand même important quand même
de passer par quelqu'un comme toi pour avoir au moins un conseil là dessus quoi exactement
exactement et ça je me suis aperçu parce qu'il y a beaucoup de gens qui viennent me voir en fait
en discutant une heure deux heures ça suffit à les orienter et en fait moi typiquement j'ai
développé un service de mentorat c'est pas de la prestation c'est juste les gens ils prennent du
mentorat chez moi donc on se voit une heure par mois une heure toutes les deux semaines une heure
par semaine ils me posent des questions et puis moi je leur réponds et donc ça leur permet de
choisir sans forcément prendre de la prestation de ma je tiens un jour par ci un jour par là etc
c'est du je pense en discussion quoi exactement c'est ça et donc ça permet de choisir les bonnes
orientations sans forcément avoir la connaissance en interne et est-ce que de ton côté t'as le même
problème un peu qu'on a à nous côté d'oeuvre est-ce que les gens mettent toujours les outils avant
je suis dit tout le temps attendez on va sonder nos besoins et après on choisira nos outils
mais c'est exactement ça enfin je peux pas citer ce client là mais j'ai bossé pour une boîte
quasiment six mois à temps plein j'ai avancé et le gars était obsédé par microsoft azur
microsoft azur je dis les gars moi je joue pas à ça je n'ai pas les compétences et vu votre
volumétrie ça me parait un petit peu prématuré de partir sur ces services là ça va vous coûter
cher et un cher à l'usage mais aussi à l'implémentation parce que il n'y a aucune compétence la
autour de la table il ya personne qui sait utiliser ça donc le temps de former de se former
ce fin vous allez retarder justement on parlait de time to market et voilà et ça fait un an et
l'appli toujours pas déployé verdict verdict et ouais alors les gars vous êtes fou chez avec un bon
vieux passe des familles plateforme à ce service en trois clics le truc il était il était déployé
et ça passait quoi et ça passait exactement et en plus là ils vont être déjà ils vont pas le
sortir tout de suite et quand ils vont sortir à faire qu'ils aient cherché des clients donc ça
ou des utilisateurs mais ça veut dire que du coup ils avaient largement le temps de sortir
dans un passe et puis après de se lancer dans le dans le cloud directement mais après c'est
c'est dur d'aller contre le le le mouvement quoi c'est vraiment moi je me sentais vraiment seul
et je pouvais prêcher mais c'était pas c'était pas possible après c'était mon client c'était le
boss de la boîte bon bah m'en vendre c'est ta boîte je ne peux que te conseiller après tu fais
tes choix juste pour revenir sur sur les passes ce que je comprends mais en fait toi t'es t'es
plutôt pro on va dire sur ces plateformes à ce service qui viennent quand même automatiser beaucoup
de choses à quel moment tu vas on bascule d'un plateforme à ce service à gérer ton infras
tout seul est ce que on peut y a des seuils comme ça à passer ou pas comme je disais dès que tu as
des problèmes de performance où tu as beaucoup d'utilisateurs à un moment donné les passes
suffisent plus et c'est souvent à ce moment là où en fait mes clients ou mes prospects venaient me voir
quand j'étais encore frillance ok parce que moi je leur je leur concevais des infras sur mesure en
fonction de leurs applications ok budget aussi budget puisque à un moment donné peut-être ça devient
plus intéressant de passer sur ton propre ta propre structure oui alors après c'est kiff kiff parce que
tu vas embaucher quelqu'un qui va faire quelque chose en fait tu vas tu vas gagner un truc c'est
que tu vas gagner en performance et en maîtrise mais tu vas pas forcément gagner en budget parce
qu'en fait les passes s'ils ont plus cher c'est parce que à un moment donné t'as pas un ops à
payer c'est ça aussi il faut voir bien sûr c'est que l'ops il est externalisé dans les services et
puis le croc enfin un gros avantage que je vois aussi on a tout fin on a on connaît tous des
startups qui qui connaissent l'effet passé à la télé où il y a un reportage à la télé tout le
monde se connecte le serveur il est en PLS et des nids de service ça marche pas là sur des passes
on coche autoscale est terminé quoi on n'a pas géré ça et on n'a pas un débops qui transpire à
faire du scale de machine tout est programmé automatiquement donc ça c'est quand même assez
confortable pour pour c'est vrai mais on n'est pas à l'abri je vais vous prendre exemple tout bête
dans une application souvent il ya une base de données c'est souvent elle en fait qui est la limite
alors je suis adopté pour ça du coup c'est pas parce que ton ton frontal donc ton application
front elle va être élastique que ta base de données elle va s'élastifier parce que avoir un
agréga ou un cluster de base de données élastique c'est très très cher et je pense que les passes
ne le font pas et si t'as une centaine de milliers d'utilisateurs qui arrivent alors certes tu vas
avoir ton application qui va se poper qui va se dupliquer comme ça à l'infini par contre ta base de
données derrière voilà la base de données elle va devoir encaisser des milliers de requêtes et si
si tes requêtes ne sont pas bien tunés ou si tu fais des tonnes de requêtes à la seconde voilà
micro seconde bah ton service base de données il va tomber c'est souvent ça qui va se passer
d'ailleurs la paix la paix tombe souvent c'est clair en fait il ya une élasticité jusqu'à un
certain point et ton appétit ta base de données bah suivra plus et c'est à ce moment là où justement
et bah tu dois penser du sur mesure avec des agrégas complète base de données redondée
etc. avec même tu peux avoir des bases de données en lecture et une en écriture fat il ya plein de
lait d'accord c'est chaud et bah ouais c'est chaud c'est pour ça que des gens qui sont qui sont
dédiés à ça donc en fait souvent le talent d'achilles c'est la débae ouais alors souvent
talent d'achilles c'est la débae pour ça que c'est pour ça que la première chose qu'on fait quand
on quand on repense des applications souvent c'est de c'est de séparer parce que souvent quand
les gens viennent nous voir alors soit ils ont ils ont des passes soit ils ont tout mis sur un seul
serveur la première chose que tu fais c'est tu sépare la base de données de la base applicative
etc. puis tu remorces elle tu tu fais des serveurs dans tous les sens fameux mais la base de données
c'est toujours elle qui a des soucis là où les parce que tu pourrais avoir plusieurs bases de données
et je sais pas si t'as suivi il ya un peu une tendance là de retour sur des bases de données
un peu plus traditionnelle type SQLite où en fait on va utiliser ça sur des serveurs fichiers
pour aller optimiser le temps de réponse et pour pouvoir justement utiliser des scales
en élastique assez assez fort je sais pas si tu sais pas si tu connais néontèques ou des choses
comme ça c'est en fait un service en abstraction qui se fait derrière derrière posgres donc toi en
fait ils viennent tout enregistrer sur des fichiers type s3 et ils ont un espèce de machine
intermédiaire qui te permet en fait de de scale et de ouf mais c'est encore assez bêta non t'as
pas trop d'infos là dessus non je connaissais même pas mais j'aurais tendance à être frileux parce
que posgres SQL c'est quand même base de données qui a été pensée pour pour plein de choses et
donc extraire des données pour les envoyer dans du stockage objet à un moment donné comment tu
vas faire tes relations entre objets ça va devenir compliqué et donc ça veut juste dire que ta base
de données va te déporter sur ton serveur d'application et donc je sais pas si ça va être performant j'ai
aucune rapport je sais pas je suis ça parce que pour l'instant voilà je suis assez curieux je veux
voir ce que ça dit mais je voulais juste savoir si toi t'avais des infos là dessus donc toi tu serais
plutôt un peu un peu frileux là dessus justement on parlait de c'est surtout que je m'adresse pas
en fait parce que je pense que ça c'est vraiment pour des besoins particuliers avec des un fort
trafic et moi les forts trafic base de données c'est quelque chose que je fais pas parce que moi
je suis historiquement administrateur cloud system et ça c'est clairement qui est quelque chose
qui fait par les administrateurs base de données et donc moi je connais moins donc force parce que
en plus comme chez les dev chez les ops il ya plusieurs il ya plusieurs branches bien sûr il ya des
branches exactement et justement on parle de de nouveaux services est ce que aujourd'hui il ya
vraiment la pratique où il ya de la grosse hype est ce qu'il ya un petit peu des deux la vérité
un petit peu au milieu des deux et ben t'as l'avènement des services manager qui est quand même pas
mal sans pas tu vois après les après les passes t'as l'infrastructure à ce service donc là tu
tu vas créer tes infrastructures et dans les infrastructures de service t'as des services
manager notamment l'un des premiers qui a apparu c'est le stockage objet puis ensuite il ya eu
les bases de données de façon la donnée c'est le c'est le coeur d'une application les bases de
données manager et puis t'as plein de services manager qui existe et ça c'est vraiment une
évolution alors c'est par essence ça fait quelques quelques années maintenant mais c'est une
évolution qui te permet d'aller encore plus vite aussi ok et est ce qu'on peut parler de la
dépendance des gaffes ames on peut parler de la dépendance des gaffes ames la dépendance d'amazon
surtout tu veux dire c'est parce que en tant que dévoile c'est tu vois on parle tout à l'heure
d'infrastructure tout ça est ce que est ce que aujourd'hui c'est c'est eux qui prennent le la
grosse part du marché est ce que leur hegemonie elle est due au marketing ou elle est due juste
parce qu'ils ont plus de machines est ce que nous on peut rivaliser en termes de souveraineté
ou est ce qu'on en est toutes ces questions là c'est à la fin dès qu'on parle d'internet à la fin
ça finit quand même souvent chez les gaffes ames ou en tout cas on est obligé de parler des gaffes ames
toi ton point de vue là dessus est ce qu'on c'est quoi ta philosophie alors déjà on va dire
ce que c'est que les gaffes ames je sais pas si l'auditoire et donc les gaffes ames c'est google
parce que google clod plateforme qui a un hébergeur clod amazon parce que amazon web services qui
a un hébergeur clod facebook facebook c'est pas un hébergeur clod meta ou c'est vrai meta mais bon
c'est gammam
c'est un petit gamin
parce que pareil google c'est alphabet bon bref facebook facebook est un grand fournisseur de
projet open source apple qui est un fournisseur device qui a pas encore de clod provider
un jour peut-être et microsoft qui a microsoft azure qui a un clod provider donc déjà dans les
gaffes ames il y a trois clod provider qui en effet se taille la part du lion puisque la plupart
d'internet tourne chez ces trois clod provider là et même on peut aller plus loin internet tourne
chez amazon web services ce qui fait que aujourd'hui on a un problème c'est que si amazon web services
prend une décision qui va à l'encontre de la neutralité du net ou c'est cool parce que on est
pas à l'abri qu amazon c'est cool et bah il y a une grande partie d'internet qui disparaît ce qui va
à l'encontre même de ce qu'est à l'internet à l'origine qui est répartition c'est déjà arrivé
c'est déjà arrivé à des moments que ça répondait plus clod flare tout ça et que majorité des
sites ne marchaient plus en fait exactement quand quand il y a eu le plus gros problème c'était
quand le stockage d'objet d'amazon était planté on a vu un ralentissement d'internet mondial
et là aujourd'hui alors moi c'est vrai que je développe sur ma chaîne et dans mes postes de
blog l'aspect de la souveraineté numérique parce que en plus d'être américain et d'être soumis à
des lois américaines on n'a plus l'autonomie sur nos hébergeurs et l'aspect légal moi m'intéresse
fortement parce que je sais pas si on peut parler du clod acte mais le clod acte et le patriot acte
obligerait ces trois fournisseurs là à fournir des données au gouvernement américain si jamais
il décidait de vouloir avoir les informations d'une entreprise par exemple d'une petite start-up
française qui développe un outil qui contrevient aux intérêts économiques américains par exemple
ouais et notamment ils ont ils ont et en plus ils ont pas le droit d'en parler ils ont pas droit de
dire qu'ils ont donné les informations au gouvernement en plus c'est ça qui est le plus
vicieux exactement et même si ces entreprises là se défendent en disant qu'elles ne font pas
forcément et qu'elles ne font pas beaucoup le fait est que la possibilité existe et qu'on doit en être
conscient aujourd'hui l'autre partie de la question c'est est-ce qu'on peut rattraper ça alors plutôt
est-ce qu'on est pourquoi est-ce qu'elles sont à ces niveaux là et ben parce que déjà elles sont
partie plus tôt dans le clod puisque amazon web services a développé le stockage objet avant tout
le monde enfin ils sont en avance justement ils ont en avance sur les services qui proposent
leurs utilisateurs et c'est pour ça qu'ils ont la plus grosse part de marché que ce soit amazon
google ou microsoft tazur ok juste historique ouais historiquement c'est parce qu'ils sont là avant
et puis surtout qu'ils qu'ils agèquent beaucoup en recherche et développement je ne vais pas
aborder l'évasion fiscale qui a un avantage concurrentiel mais regardez ça à l'esprit aujourd'hui est-ce
que contrairement à ce qu'on dit le clod c'est pas si vieux que ça je veux dire le clod ça a
commencé dans les années 2010 et ça fait ça fait pas 20 ans que c'est là donc c'est pas c'est
pas encore trop tard en fait c'est trop tard si on pense que c'est trop tard c'est sûr mais par
contre il y a des solutions libres typiquement il ya open stack qui est une solution libre il ya
Kubernetes qui est une sans-l'une solution libre et des solutions libres qui nous permettent à nous
européens de peut-être décider de faire évoluer ces solutions libres aussi et puis de les
implémenter chez nous est-ce qu'aujourd'hui t'as tes clients ils sont sensibles à ce type
de problèmes en tout cas est-ce que c'est un sujet qui arrive sur la table et qui est abordé
où c'est admis déjà bon bah de toute façon on s'affinera chez amazon ou chez google ou chez
ou chez microsoft et les dés sont c'est comme ça quoi ou justement ils sont de plus en plus en
alerte là dessus sur cette propriété des données et c'est possible le leak de toutes les informations
quoi et bah on a plusieurs types de clients alors ce que j'ai pas dit tout à l'heure c'est que je
suis aussi co-créateur d'un collectif de freelance qui s'appelle l'hydra on prône le DevOps etc et
justement on va parler des clients qui viennent chez l'hydra pour justement avoir des compétences
ups et bah les clients qui viennent chez l'hydra ils sont soit sensibilisés soit ils ont pas le choix
parce que nous on a décidé de ne pas travailler avec les gars femmes pour des contraintes de
souveraineté numérique et économique parce qu'on pense aussi que filer des sous à ces gens là
et de la thune en fait c'est de la thune qui va s'évader du territoire européen qui va pas revenir
et donc on va s'appauvrir en faisant ça donc nous on a décidé de pas le faire donc les gens qui
viennent nous voir on leur dit bah nous on vous aidera pas à aller vers ces gens là donc allez
trouver d'autres personnes ou alors on a des solutions pour vous parce que il y a des français
des européens qui ont des solutions alternatives qui dans votre cas pourront s'adapter dans certains
cas ça s'adapte pas je faut être honnête dans certains cas il faut absolument aller chez eux
mais ces gens là bah du coup c'est pas nous qui allons nous accompagner et aussi et aussi du coup
avec nos services en ligne que ce soit froguite ou les autres qu'on développe on a justement on
met en avant ce truc là où nous on est français on fait hébergé en france et on est basé sur
des logiciels libres on a développé le concept de sas libre et je voudrais créer un manifeste
justement sur le sas libre pour proposer une autre voie pour le sas pour justement que les
gens qui nous rejoignent ils soient au courant de tout ça et qui sont au courant que s'ils viennent
vers nous et bah ils pourront quand même partir et utiliser le cilibre qu'on développe qu'on
ont qu'on intègre en fait d'accord et comment ça va comment ça pourrait se s'en orchestrer c'est à
dire faire un transfert de de de provider hyper facilement où je branche en fait on vient s'extraire
de l'infrastructure assez facilement et rapidement ou comment ça s'en forme alors je vais
prendre l'exemple de froguite parce que c'est celui qui va parler plus aux éditeurs et auditrices
puisque froguite c'est un équivalent de github aujourd'hui ma volonté c'est de donc froguite
c'est basé sur matormost une githlab aujourd'hui mais toi il y aura d'autres il y aura d'autres
briques mais aujourd'hui c'est matormost githlab mon idée c'est de fournir au moins pour le githlab
une extraction de toutes les données qui sont dans githlab que les personnes pourraient réintégrer
dans un autre githlab soit githlab.com soit un autre githlab évergé par quelqu'un soit githlab qui
pourrait qui pourrait s'auto-éverger et donc l'idée c'est de fournir en fait un export journalier en
fait de toutes les données au gens d'abord je m'adresse à githlab puis après ce sera matormost
et mon idée c'est vraiment de fournir aux gens un export qui pourraient importer dans les logiciels
puisque comme on se base sur des logiciels libres il pourra aller voir un autre fournisseur de githlab
ou un autre fournisseur de matormost ou même l'évergé eux-mêmes et à partir de ce moment-là ils
auraient ça après ils perdraient toute la partie coopération et toute la glu qu'on va mettre
autour notre notre plus-value en fait mais bon c'est pas grave l'idée c'est pas qu'ils soient mariés
avec nous les clients. Et tu parles de mariage est-ce que aujourd'hui parce que souvent on l'entend
en fait quand tu rentres chez Amazon ou quand tu rentres chez chez les gros en fait c'est quasi
impossible de sortir est-ce que c'est moi j'entends ça j'ai pas les subtils pour savoir si c'est vrai
ou si c'est pas vrai parce que j'ai pas les compétences pour juger de ça toi qui est un petit peu
plus dans la partie est-ce que tu peux attester que oui une fois que tu as mis ton pied dedans au
final le sortir va devenir très très très compliqué. Ouais je confirme que c'est très compliqué pour
plusieurs raisons quand tu vas chez ces fournisseurs-là ce qui va t'intéresser c'est les services
manager dont je parais tout à l'heure donc la base de données manager le cdl manager le dns manager
le reddys manager enfin il y a plein de trucs même des services qui sont vraiment spécifiques comme
si je prends un exemple l'autre balan de soeurs d'amazon web services il fait plein de trucs il
fait par exemple de l'autoscaling de serveurs etc. Donc tu vas chez eux tu prends leur service
manager parce que tu veux développer ton application mais du coup ces services manager ils existent
que chez Amazon web services si tu veux avoir un équivalent chez google c'est d'autres types de
services voire certains n'existent pas et donc si tu développes puisque du coup moi je fais du code
d'infrastructure si tu développes ton code d'infrastructure pour amazon il va pas que tu le réécrives
pour google par exemple et si tu vas chez ces gens-là pour utiliser des briques libres comme
par exemple Kubernetes et ben en fait la question se pose pourquoi est-ce que tu vas les ces chez
gens-là si tu peux le faire ailleurs en fait donc souvent quand tu vas chez ces gens-là tu prends
une partie de service manager une partie de breaklib parce que tu veux pouvoir t'extraire
facilement mais mais t'as toujours un morceau où il t'auras il t'auras facilité la vie et donc tu
deviens dépendant en fait de cette brique et après ça devient quasiment la pierre ongulaire de ton
architecture et ta migration en devient quasi impossible parce que cette pierre ongulaire tu
peux pas la porter facilement à côté quoi ouais puis ça a un coût aussi la migration à un coût
aussi bien en infra mais surtout en homme quoi en temps en même surtout en homme ouais on a l'exemple
avec bedrock ceux qui font m6 tout ça à lyon en fait qui ont fait la migration sur amazon il y a
un livre le projet Copenhague qui explique en fait la migration et ils expliquent vraiment la dépendance
et le temps de développement pour s'adapter à amazon en fait et ils ont vraiment hésité longtemps
avant d'y aller parce que justement c'était un gros investissement en temps rien que pour s'adapter
oui et bien justement et ça aussi c'est un autre truc c'est que si tu vas chez ces gens là
tu as des compétences internes qui vont se former à amazon web services par exemple et donc quand
tu vas vouloir sortir qu'est ce que tu fais des gens qui sont formés à amazon web services est ce que
tu vas les former à d'autres trucs est ce qu'ils vont partir ailleurs enfin toutes ces questions
là aussi c'est un vrai c'est un vrai coup on fait pour l'entreprise et après moi j'ai tendance à
prener le plus possible utiliser des briques libres si vous pouvez et ne soyez pas mariés à un service
manager même si c'est vachement bien un service manager mais si vous avez les moyens essayez de
faire autrement si je résume ce que pardon si je résume en gros ce que tu ce que moi ce que j'ai
compris en fait c'est que si on veut développer nos services européens français tout ça c'est un
bon moment pour nous en fait d'aller vers eux pour leur donner les moyens et l'argent aussi parce
qu'on va les payer de se développer en fait et arrêter de financer en fait ces services américains
tout ça et de les voilà arrêter leur développement par notre utilisation en fait t'as très bien
résumé il faut savoir un truc c'est que ces gens là et on pourrait même parler à quelqu'un qui n'est
pas un gaffin mais samsung par exemple tout le monde connaît c'est en fait ces grosses boîtes elles
sont pas venues de nulle part et ces boîtes américaines elles existent parce que elles ont eu des
très très gros contrats avec l'état américain et l'état américain fait ce qu'on fait pas en
orub c'est à dire elles aident ces entreprises à typiquement spacex n'existerait pas sans l'état
américain enfin je veux dire c'est on n'aurait pas on n'aurait pas de on n'aurait pas starlink en
fait si l'état américain avait pas filé des tonnes de tune à spacex pour qu'il développe pour qu'il
soit un gaffin si on veut en effet que bas que on veut si on veut avoir des fournisseurs européens il va
falloir les aider nous c'est le choix qu'on a fait donc c'est pour ça qu'on essaie d'utiliser des
clotes provider français après nous on est tout petit on va pas filer beaucoup de tune au clotes
provider c'est pas avec nous qui vont gagner des tu n'est mais si on est assez nombreux à faire
ça et puis surtout si les boîtes français se mettent à le faire on va pouvoir arriver à
faire des choses. On va pouvoir arriver à les titiller. En plus, en France, ce qu'on
ne sait pas, et ce que je me suis aperçu récemment, c'est qu'on est dans les leaders
du cloud en Europe. On a le plus de data centers en France, on a beaucoup d'entreprises
qui sont leaders dans leur marché. Si on pense à OVH, c'est un leader européen.
Voilà, justement, j'avais demandé à quel service tu recommanderais ou tu n'as
utilisé en France. Il n'y a aucun lien d'affiliation que l'il faut.
C'est pour ça qu'il faut en citer plusieurs. Surtout que j'essaie de développer de l'affiliation
avec ces gens-là. Typiquement, si vous voulez aller sur DuPAS, on en a parlé du platform
As a Service, allez voir ce que fait Clever Cloud. C'est très bien. Je ne suis pas
utilisé le termatisation artificielle, mais c'est de l'apprentissage du deep learning,
je crois. En tout cas, ils font de l'apprentissage sur l'infrastructure. Du coup, ça leur
permet de proposer un service qui est vachement bien. Un autre Français aussi qui fait un
PAS, c'est Scalingo. On est pro-Scalingo ici.
Alors moi, je n'ai pas testé n'il à n'il autre parce que moi, le PAS, ce n'est pas
mon cœur de métier. Moi, c'est plutôt l'infrastructure de service. Au niveau du
YAS, honnêtement, moi, je conseille Scalway parce que j'ai un très gros problème avec
le support OVH. Ils le savent que j'ai un gros problème avec. Je ne suis pas tout seul
à avoir après avec le support d'OVH. Mais en même temps, OVH ne fait pas sombreur
avec le Cloud. Ça, c'est quelque chose que j'ai appris avec le passage en bourse d'OVH.
Puisque j'ai regardé où est-ce que tout est public exactement, où est-ce qu'ils faisaient
leur chiffre d'affaires et le Cloud, ça représente 20% de leur chiffre d'affaires.
Donc, ça m'étonne pas. Par contre, Scalway est très bon dans ce qu'ils font. Nous, on a
une grosse partie de notre infrastructure pour nos deux sacs chez Scalway. On a d'autres
chez OVH, mais on ne prend que des serveurs chez OVH. Donc, on est sur leur truc historique.
Ok. Et peut-être un autre ou deux en dehors de la France ?
Alors, en dehors de la France, il y a Idora qui tire son épingle du jeu.
En Suisse ?
En Suisse, oui. Et puis, Exo Scal, aussi, en Suisse, qui a l'air de faire de très bons produits.
D'accord.
Je ne les ai pas testés, parce que, pour l'instant, je m'adresse à des Cloud Providers français.
Un jour, j'aurai des besoins qui ne pourraient pas fournir, j'irai voir en effet, ailleurs, en Europe.
D'accord.
Carrément. Et on parlait, après, on le sait en fait, en tant que développeur, que ça soit OBS ou Front
ou Back ou QC, on est toujours dans cette culture d'apprentissage et d'apprendre de nouvelles choses.
Aujourd'hui, quelqu'un qui est soit freelance, qui va jouer directement avec ses clients ou en agence,
donc, qui va devoir en fait répondre à la problématique client, comment il peut se former au meilleur pratique d'Evobs,
avoir des solutions plus faciles et en tout cas, monter en compétence sur toute cette partie-là.
Et bien, qui viennent sur ma chaîne ?
Mais ben voilà, exactement.
Parce que j'aborde toute la partie culture d'Evobs sur la chaîne des compagnons du DevOps.
Après, si c'est un peu plus technique, parce que moi, je fais de la technique, mais pas que.
Il y a la chaîne de Xavier Key aussi, il fait beaucoup de techniques.
Il aborde un peu moins l'aspect culturel, donc du coup, on se complète bien tous les deux.
Mais en plus de la chaîne, j'alime une communauté en fait avec un forum bientôt, il y aura un wiki.
Donc, il peut venir s'inscrire aussi sur les compagnons du DevOps, parce que pour moi, les compagnons, c'est un tout en fait.
Il y a le podcast, il y a la chaîne YouTube, il y a les live, il y a le forum.
A ce sujet-là, si je peux conseiller à tout le monde,
je sais que la grande mode, c'est les Discord et les Slack, etc.
Et moi, je vous conseille de fuir ces trucs-là, parce qu'en fait, il y a un problème, et je l'ai remarqué,
il y a un problème de productivité, c'est que les chats, c'est vraiment bien pour l'instantanéité,
mais par contre, il y a beaucoup de flowde, il y a beaucoup de bruit, en fait.
Et du coup, si on s'absente pendant deux jours d'un chat, on a l'impression d'avoir raté un truc.
Ce qui n'est pas le cas avec un forum, parce que les forums sont bien classifs.
Je ne dis pas ça parce que j'ai mis un forum, mais j'ai remarqué ça en tout cas,
sont bien classifs, ce qui fait que quand on passe une semaine en dehors du forum,
il suffit juste qu'on aille voir les parties qui nous intéressent.
Et c'est très bien structuré par ce sujet.
Exactement. Les chats, c'est bien, ça nous permet d'avoir l'impression qu'il y a une communauté active,
mais en fait, c'est du bruit, il y a énormément de bruit parasite,
et du coup, je ne sais pas si vous êtes freelance, mais moi, je suis freelance,
donc à un moment donné, je ne pouvais pas passer mon temps sur un chat et faire et vendre du temps à mes clients.
Donc, j'ai décidé de couper tous les chats et les Discord, etc.
et d'aller de temps en temps sur ces trucs-là,
mais du coup, je m'aperçois que je rate plein de trucs, et puis comme c'est patrier, ben...
Ok. Donc, de toute façon, on mettra évidemment tous les liens sur tes réseaux, ta chaîne, tout.
Mais aujourd'hui, qu'on soit à limite front ou back, on a tout intérêt, en fait,
à s'intéresser un petit peu à cette culture, comme tu dis, pour faciliter le travail.
Et enfin, en tant que front, par exemple, un outil comme Versel ou Netlify est venu simplifier et
fluidifier énormément mon travail de mise en production. J'ai quasiment plus rien à faire, quoi.
Et donc, un front, en fait, va gérer un petit peu cette partie DevOps et de déploiement avec
toute l'automatisation qu'on peut faire. Mais même pour un front, pour un back,
on a tous intérêt, en fait, à s'y intéresser à cette culture. Donc, on va dire, ta chaîne et
tout ton travail de contenu que tu anime et que tu produis, en fait, ne sont pas uniquement que pour
des admin-sys, quoi, bien au contraire, pour n'importe quel DevOps, enfin, pour n'importe quel
développeur aussi bien front que back. Avoir une culture DevOps, c'est important, quoi.
Ben oui, plus d'autant plus depuis que j'ai lancé FrogIt, parce que du coup, je m'adresse plus
qu'à des ops, mais j'adresse aussi à des devs. Et sur ma chaîne, on en parlait en préparant
l'émission, je fais des lives réguliers pour parler de la Jamstack et pour montrer comment on
va déployer tel ou tel application. Donc là, dernièrement, j'ai fait AstroJS. Dans l'année,
j'avais fait Docusaurus. L'épisode, il sera sorti, j'aurais fait Staticast. Donc, je montre aussi
comment on déploie ces applications, même si moi, je ne suis pas développeur, mais je sais
déployer des applications, c'est quand même mon métier. Donc du coup, je montre comment faire et je
laisse évidemment le code, les gens, ils peuvent l'utiliser, pour justement déployer ça sur des
qui sont un équivalent de Versailles, d'être l'IFI, etc.
Moi, j'ai une question que l'IFI, je peux être un peu... Est-ce que le niveau général des
développeurs que tu rencontres, au niveau culture ops, tout ça, est-ce qu'il est bon ou vraiment...
Enfin, quel niveau il est, en fait ? Est-ce que les développeurs que tu as en général, ils connaissent
vraiment comment ça fonctionne un serveur, comment on déploie tout ça ou vraiment,
comprenne rien ?
Ça dépend après, c'est vrai que quand on fait du développement,
déjà, souvent, on n'a pas un Linux entre les mains. Mon outil de travail, c'est un Linux,
ça veut dire que ma station de travail, c'est un Linux. Et quand tu déploies dans le web,
tu déploies sur du Linux. Donc si tu ne connais pas bien Linux, à un moment donné,
tu es un peu limité. En plus, j'ai remarqué que souvent, la plupart des personnes qui font du
développement, elles ne sont pas très à l'aise avec la ligne de commande, alors que ça permet de
faire des trucs très rapidement, très vite, typiquement. Moi, je fais du mentorat sur Git.
J'accueille beaucoup de stagiaire et d'alternant et je ne vois que le niveau de Git, il est mauvais.
Et en plus, souvent, quand ils sortent des cols, ils ont utilisé que des outils graphiques et je
pense que c'est un très mauvais, un très mauvais, comment dire, un très mauvais scourbe d'apprentissage
que d'utiliser les outils graphiques. Pour moi, il faut utiliser la ligne de commande Git pour bien
comprendre ce que fait Git. Excuse-moi, Christophe, mais quand tu dis interface graphique, c'est des
outils de versioning Git, mais en interface graphique, type GitHub desktop ou Git Kraken,
Tower ou des choses comme ça, OK. Mais par contre, ils n'ont jamais rien fait en ligne de commande,
le Git, Git, stagiaire, ça, ils ne savent pas. Très rarement, en tout cas, en tout cas,
la part de ce que j'ai vu passer, j'en ai vu passer plus d'une dizaine maintenant,
alors je commence à me dire, enfin, je sais que maintenant, quand j'accueille quelqu'un,
soit qu'il y a une tendance court, soit qu'il y a une reconversion, il y a une tendance en effet à
une quitte, je le vois, même je donne des cours en école d'ingénieur, quand je corrige les TD,
je vois qu'ils sont mauvais, c'est juste qu'en fait, ils ne savent pas faire.
Ils ont pas la culture du comitre. C'est ça, et puis ce n'est pas forcément leur faute,
parce qu'on ne leur apprend pas. Donc moi, chez une des écoles, j'essaie de rajouter un jour dans
mon TD, parce que j'ai un TD de deux jours où je leur apprends GitLab, CI et Ransible,
et du coup, faire du GitLab-Ci, alors que tu as des problèmes de Git, c'est un peu compliqué.
Donc j'essaie de rajouter un jour pour pouvoir faire du Git, mais on me dit, mais j'ai pas les moyens.
Est-ce qu'en fait, on pourrait dire, comme dans n'importe quel langage de programmation,
les fondamentaux en fait sont hyper importants, est-ce qu'on pourrait dire que les fondamentaux
de l'Obs, de la culture OBS, c'est la gestion Git ? Est-ce qu'on pourrait dire ça ?
Oui. Pour moi, les fondamentaux, qu'on soit OBS ou Dev, alors, je parle de web.
Moi, je ne parle pas d'applications lourdes, etc. C'est un autre débat. Mais dans le web, Linux,
Git, Linux, parce que de toute façon, on tout va arriver sous Linux à la fin.
Vous voulez que ça va arriver sur Linux ?
Exactement. Si vous voulez travailler avec un OS MacOS, parce que c'est du BSD, donc c'est assez
proche, même si c'est pas tout à fait pareil, mais Windows, oublié, vous allez vous mettre
des bâtons dans les roues. Et Git, parce que clairement, c'est à la fois un outil de versioning.
C'est un outil de déploiement et c'est un outil de communication. C'est-à-dire que Git va vous
permettre, vous, en tant que Dev, de communiquer avec les autres Dev de votre équipe et surtout
avec les Ops, parce qu'on a tendance à l'oublier. Mais si on a des messages de commit, c'est aussi
pour laisser des informations. Comment est-ce qu'on fait les commits ? C'est vraiment super important.
Qu'est-ce qu'on va mettre dans un commit ? C'est quoi notre sub-développement ? Tout ces trucs-là,
c'est vraiment la communication dans l'équipe et c'est ce qui va faire que l'équipe, elle va
aller très loin, très vite ou pas. C'est vraiment le ciment de l'équipe, encore plus avec du travail
à distance ou en remote, ou pour le coup le seul lien qu'il y a, c'est la codebase et tout l'artifice
qu'il y a tout autour. C'est Git ou Frogit qui vient de l'écrire un petit peu tout ça ?
Git, GitOps est le réseau social des développeurs.
Exactement. J'ai même écrit une newsletter que j'ai appelée « Le sujet, c'est Git et mon meilleur
ami ». J'ai fait une antissège Git parce que je me suis aperçu qu'il y avait plein de problèmes.
D'ailleurs, elle a été téléchargée plus de 1600 fois, ça veut dire qu'il y a un vrai truc avec Git.
Et pour moi, Git, ça devrait pas être une douleur pour les gens. Et je traite sur Twitter,
je vois que les développeurs, c'est une douleur pour eux, Git, et qu'ils y vont à reculons.
Et je pense qu'en fait, si ça n'est pas une douleur, le plombier, quand il vient chez
nous, si ce n'est pas utilisé, ça a clé à molette ou quoi, il va faire du mauvais travail.
Pour nous, c'est pareil. Si on ne s'est pas utilisé Git, à un moment donné, on va juste faire du mauvais
travail. Oui. Et juste, peut-être avant de finir, il y a des événements qui sont vraiment orientés
ops où justement, on sait qu'il y a plein de conférences pour les devs ou parfois,
c'est organisé même par les marques à coup de grands trucs, marketing, tout. Mais est-ce qu'il y a
des meet-ups ou des choses comme ça qui sont vraiment orientés ops et orientés à la fois culture
et peut-être parfois un petit peu plus technique ? Oui. Alors, il y a des meet-ups ops, ça,
c'est sûr. Moi, je n'ai pas la chance d'en avoir chez moi, sauf si je me prends par la main et j'en crée.
Mais j'habite sa têteienne, donc il faut que je drague Jaya Lyon pour avoir des meet-ups
ops. Mais typiquement, les Lyonnais, vous avez des meet-ups DevOps. Partout en France, dans les
très grandes villes, il y a des meet-ups DevOps, typiquement à sa têteienne. À Rennes, on va
héberger un meet-up DevOps bientôt. Il y a aussi des meet-ups orientés Linux, enfin, plein de trucs.
Donc là, il y a ce qu'il faut. Il y a aussi en conférence, il y a les DevOps d'Eday qui viennent
de se dérouiller à Marseille. C'est très technique pour le coup, ça. Il y avait, malheureusement,
n'existe plus la conférence que j'aimais beaucoup, qui est le DevOps Rex. Donc, tous les petits t-rex
bleus qui sont là derrière, c'est ce que j'ai pu récupérer au DevOps Rex. Là, on parlait beaucoup
culture, retour d'expérience. Donc, si ça vous intéresse, allez sur la chaîne YouTube de DevOps
Rex et allez voir les précédents tools. Parce que, de toute façon, la culture, elle n'a pas trop
bougé. Le concept, l'idéologie reste la même. Après, peut-être le tooling a évolué, mais le
coeur et l'essence même de l'idée, ça n'a pas changé. Exactement. C'est pour ça que je vous
conseille d'aller voir justement des DevOps Rex, parce qu'il y a beaucoup de retour d'expérience
en fait en français en plus. C'est vraiment comment est-ce qu'on a mis en place le DevOps dans
notre entreprise, comment ça s'est passé, etc. Et puis, il y a plein de sujets qui sont abordés.
Excellent. Écoute, merci Christophe d'avoir pris le temps d'être venu sur Double Slash. On le
redit, tu as un podcast, tu as une chaîne YouTube où justement, tu parles et tu vulgarises,
tu rends accessible aussi bien la culture que la technique les compagnons du DevOps. Un grand
merci à toi et merci à tout le monde d'être restés jusqu'au bout de l'épisode et puis on vous
dit à bientôt. Ciao ciao ! Retrouvez Double Slash sur la plateforme de podcasts préférés et sur
le site internet du podcast www.slash-podcast.fr. Sur le site, vous allez retrouver tous les liens
de l'épisode, les références évoquées durant l'émission.