C'est d'abord une culture. Quand on est en DevOps, on prend tout le monde.
DevOps et agile font effectivement partie de la même famille.
Sa virtualisation applicative, c'est très bien.
Aujourd'hui, ça nous prend 10 minutes et un café.
Ce n'est ni être dev, ni être DevOps. C'est avant tout de la communication.
Ce mouvement DevOps, c'est tout simplement drivé par la communauté
et endorsé par les entreprises.
J'ai adopté une démarche DevOps.
Le développement agile, on a accéléré des poignements.
Ça amène une clarté sur le travail de...
Être dans une démarche d'amélioration continue.
On se retrouve face à des...
Ça, oui, naturellement ensemble. Ça donne des résultats contrêts.

L'objectif individuel, ça s'atteint.
Alors qu'une ambition, ça se partage.
Bonjour à tous et à toutes. Et bienvenue dans un nouveau numéro de DevOps.
Alors aujourd'hui, je suis accompagné de Pierre et on va parler de Covri.
Le but étant de vraiment comprendre un peu plus Covri, ce qu'ils font,
comment ils en sont arrivés là et de voir un peu ce qu'ils vont faire en futur.
Je me présente du coup, je me parle Pierre Mavro.
Je suis city or eco funder de Covri.
Je suis passé par pas mal de boîtes, fait une vingtaine d'années que je travaille.
Je suis passé par des boîtes qui c'est la finance de marché,
dans UQlink, des boîtes un peu plus grosses,
qui c'est des OS et tout un tas de choses,
de stiplar, redacte, ou encore de l'AZ, chez Criteo.
Et donc j'ai un début de carrière plutôt que 6 admins,
puis DevOps, puis SRE et puis SRE Dev,
enfin plus Dev que du coup système aujourd'hui.
Si vous avez notre bio,
vous saurez qu'on s'est rencontrés justement chez Criteo.
On était pas dans exactement la même équipe, mais on a travaillé ensemble.
Et donc depuis Criteo, toi justement, tu es parti sur Covri.
Est-ce que tu peux un peu présenter ce que vous faites chez Covri justement ?
Du coup, Covri, on est une interna, le développeur plateforme.
Donc en gros, ce qu'on va permettre, enfin notre but,
c'est de vraiment rendre les devs autonomes,
sans qu'ils aient forcément besoin d'avoir des notions d'infra.
Et c'est de permettre également aux DevOps
de pouvoir tout contrôler sans exposer la complexité d'infra au dev.
Donc on peut voir ça comme un mode cell-service en fait, pour les devs.
En termes d'usage et techniquement ensuite,
comment ça se représente ?
Parce que le terme de plateforme interne, il y en a vraiment beaucoup.
Alors en plus, si on rajoute à ça les passes externes,
on peut connaître.
Là, c'est quoi ? Je pousse mon code un peu à la Heroku.
C'est quoi exactement vous, ce que vous proposez ?
De mettre de main, on prend vos services.
Peut-être il y en a plusieurs, d'ailleurs, je sais pas.
Alors nous, on demande un Dockerfile et un repo.
Donc on fait le build, c'est pas obligatoire, mais on peut le faire.
Une fois que l'image a l'écran, on va le pousser sur un repo.
De ce repo là, ensuite on va le déployer.
Alors là, c'est vraiment la version grosse-mime.
Et ce qu'il faut comprendre, c'est que à la base, nous, ce qu'on fait, c'est d'infra.
C'est-à-dire qu'on va déployer une infrastructure state-of-the-art
sur le cloud de nos clients.
Comme ça, c'est l'infrastructure des customers.
Nous, on a un contrôle plane de notre côté
qui permet justement de lancer tous ces déploiements à distance.
Et donc au travers soit d'une interface,
donc pour les dev, une console, c'est très pratique,
soit une CLI, soit du terraform,
vous allez pouvoir contrôler tout ce qui se passe sur CoVay.
Donc l'idée, c'est de pouvoir déployer des bases de données, des applications.
Tout ce dont un développeur va avoir besoin
pour tout simplement développer des défunctionalités
sans se prendre la tête.
Ce soit très simple, il y a beaucoup de complexité qui sont masquées.
Et donc justement, pour un développeur,
donc là, t'as dit que c'était un repo et un docker file.
Si jamais je veux déclarer l'accès à une base de données,
et choses comme ça, fin, comment ça va se passer justement.
Est-ce que c'est que je vais besoin de demander un DevOps,
est-ce que, qui va y cliquer dans l'interface, que je dois le faire moi-même,
est-ce que je peux directement l'annoncer dans un paramètre quelconque ?
Oui. Alors on fournit quelques primitives de base, quelques services.
Donc on a 4 bosses de données aujourd'hui,
donc MySQL, Postgre, DocumentDB, Redis.
Et ça couvre généralement la plupart des besoins.
Et donc l'idée, c'est que tu vas créer un environnement.
Donc un environnement, ça va être production, staging, ce que tu veux.
Et tu vas créer tous tes services dedans.
Donc typiquement, j'ai un backend, j'ai un front-end, on va faire simple.
Et une base de données.
Tu crées ces 3 services-là.
Donc la base de données, comme j'ai dit, on la fournit en primitive.
Donc soit en mode conteneur, soit en mode manager.
Et c'est simple, clique sur l'interface.
Et voilà, en quelques secondes, tu as ton conteneur, donc de base de données.
Et en fait, on vient automatiquement injecter aussi tout ce qui est environnement variable au sein de l'environnement.
Ce qui fait que toutes les applications que tu vas utiliser derrière,
tu vas pouvoir leur dire,
moi typiquement, mon application, elle a besoin de DB Host, DB Login, DB Password, etc.
Nous, on a créé des built-in environnement variables avec du coup ce que tu as déployé.
Donc typiquement, là, la base de données.
Et tu vas pouvoir faire un alias vers,
donc typiquement, si une application typiquement à WordPress,
ou ce genre de choses que tu as déployé,
qui vont demander expressément à ce qu'il y ait exactement tel nom de variable, etc.
Tu vas pouvoir la faire pointer en fait vers la built-in variable qu'on a créée.
Donc ça fait un simple alias.
Et ce qui veut, l'avantage de ça, c'est que les développeurs,
quand ils font une nouvelle feature, ce genre de trucs,
ils n'ont pas envie de travailler à 50 sur le même environnement de staging,
typiquement parce que ça devient vite le foutoir.
Ce qu'ils ont envie, c'est de pouvoir dupliquer les environnements.
Et donc ça, c'est une des grosses forces de Cori,
c'est qu'on vient, en un seul clic,
de permettre de cloner un environnement complet.
Et donc tous les alias, etc., que tu as fait pointer vers les built-in,
en fait, nous, on te garde ça de l'autre côté,
mais ça reste complètement isolé.
En fait, on vient refaire automatiquement tout le mapping, etc.
Donc même si tu as 50 applications dans ton environnement,
ça va se faire tout seul.
Seule chose que tu auras à reparamétrer, c'est tout ce qui est vraiment unique.
Typiquement, si tu as mis un custom domain,
ou si tu as mis des secrets,
tu n'as pas forcément envie de partager les secrets, etc.
Donc voilà, ça, c'est le genre de choses qu'il faudrait que tu en mettes.
Mais sinon, voilà, c'est vraiment très, très simple, c'est copier-coller.
Donc là, en fait, on partirait, tu pars de la prod,
tu la dérives, en fait, dans un environnement de développement,
tu pars de la prod, tu dérives.
Et ensuite, tu peux promouvoir justement,
tu as cette notion de promotion pour repartir sur la prod
quand j'ai fini mon développement.
Alors ça, ça va être plutôt toi qui va te débrouiller avec ta CID.
Une fois que tu vas émerger dans main,
typiquement, ça va te débrouiller sur ta prod.
Après ça, c'est des stratégies qui sont propres à chacun,
enfin, chacune des boîtes, chacune des équipes, etc.
Là où nous, en fait, on va augmenter la productivité aussi,
si tu veux, c'est que le dev n'a pas besoin de se connecter sur Covri
pour faire des trucs.
C'est-à-dire qu'il parle de sa branche main,
il veut faire une nouvelle future, il reste dans son guide,
en fait, dans ce qu'il connaît, et il va dire,
tiens, je veux créer une nouvelle branche.
Il fait son truc, etc.
Il teste, en le cas de salaire d'aller,
il pousse ça, il fait une nouvelle PR.
Dans la PR, typiquement, sur GitHub,
ça va lui dire, tiens, si tu veux créer un environnement fmr,
tu as juste à répondre ça en commentaire,
et on va te le faire pour toi.
Et donc, automatiquement, ça va cloner,
ça va lui donner lieu à règles sur lequel il va pouvoir accéder
au bac, au front, tout ce qu'il a.
Il avait besoin de ce environnement.
Et donc, il a accès automatiquement,
de manière vraiment très simple,
et quand il va détruire sa branche,
parce qu'elle sera mergée,
ou elle sera tout simplement détruite,
ça va lui supprimer automatiquement son environnement fmr.
D'accord, donc vous gérez les environnements fmr directement.
Et justement, vous êtes compatible,
donc avec GitHub, tu le disais,
avec d'autres environnements ou pas ?
On a GitLab et BitBucket aussi.
Ok, ok, super.
Bon, on est sur Azure DevOps,
mais bon, je comprends qu'on va y faire.
On va y pas supporter Azure DevOps.
C'est pas qu'on veut pas,
on a 4 ans d'existence aujourd'hui,
et qu'il faut choisir des combats,
et pour l'instant, c'est cela,
mais on ne ferme la porte, tu n'as rien du tout.
4 ans d'existence, historiquement,
c'était ce que vous aviez vraiment voulu faire,
ou c'est...
Comment ça s'est passé un peu la gênaise, là, de Covri ?
Alors pas du tout.
En fait, moi, j'étais à Crypteo encore,
et avec mes associés,
on avait appellé le Techstar.
Donc, c'est un peu comme le OIC,
le Techstar, pour être pris,
c'est vraiment compliqué.
Et on a été pris, en gros, il y avait 1000 boîtes,
10 boîtes sélectionnées, on était dans les listes.
Donc, du coup,
ça faisait un moment, de toute façon, qu'on avait essayé
de projects, qu'on essayait des trucs et tout,
lancé dans un truc qui n'avait rien à voir,
c'était de l'analyse d'image
à des femmes marketing.
Donc beaucoup d'IA, beaucoup de trucs comme ça.
Et avec le Techstar, ce qui est bien, c'est que tu apprends vite
et tu en mets vite,

Est-ce que ton idée, ton produit,
va réussir ou pas et on a rapidement vu
qu'on ne s'agirait pas.
Donc on s'est concentré, après,
sur ce qu'on connaissait, qu'est-ce qu'on fait
depuis des années ?
On passe de boîtes en boîte.
C'est quoi notre but, en tant que DevOps,
et certes, faire plaisir au devs.
C'est enfin, en tout cas faire plaisir.
L'ordonnée, matière, à pouvoir utiliser l'infra,
travailler rapidement, être efficace, etc.
Et comme dans toutes les boîtes, on galère.
C'est compliqué, ça prend du temps et t'as l'impression de refaire beaucoup de choses à chaque fois.
Donc on s'est dit, le pain point pour nous, il est là.
On va changer du coup d'autres fusils des pôles et on va se senser là-dedans.
Et c'est comme ça que la voiture a commencé.
Et où on s'est dit, il faut qu'on propose aux entreprises quelque chose qui leur permette de démarrer.
Et d'avoir quelque chose vraiment de souple qui plaît aux devs.
Parce qu'en tant que DevOps ou SRE, je pense que tu connais bien le problème.
C'est des gens qui sont très très bons côté BAC, mais côté Font, malheureusement,
ce n'est pas forcément les meilleurs pour faire des super 8 et 8X.
Donc ils font un mix de tout.
Et donc là, c'est vraiment ça aussi qu'on apporte.
C'est une facilité et une souplesse pour les DevOps pour pouvoir proposer à leur devs
quelque chose de joli, utilisable et simple.
Et donc là aujourd'hui, vos clients, ça va être quoi comme type de client qui vous rejoigne.
Vous en avez pas forcément le nombre exact, mais c'est quoi, à peu près la proportion ?
Ouais, aujourd'hui, on a une centaine de clients, un peu plus.
Et on a des boîtes de trois personnes qui démarrent avec Covri et qui évoluent comme ça.
Et on a des boîtes à plus de 200 devs.
Donc c'est assez hétérogène, mais je n'y a pas forcément non plus pour la même chose.
Tu vas avoir des petites boîtes qui vont venir parce que quand tu prends Covri,
tu vas avoir des plus gros boîtes qui viennent parce qu'en fait, ils galèrent sur les environnements ephémières.
Et ça, c'est un pain point pour beaucoup de boîtes parce que les devs en ont besoin.
C'est compliqué à mettre en place.



C'est un coup aussi parce que du coup, on a fait beaucoup d'optimisation de coups derrière et on propose pas mal de choses.
Tout à l'heure, je te disais, tu vois, un dev, il déploie une nouvelle PR, il peut avoir son environnement ephémière.
Ok, c'est cool, mais derrière, si ça tourne 24-24, ça va commencer à coûter cher.
Donc on a des optimisations comme ça pour dire, au bout de deux heures, si tu n'as pas utilisé, ça se coupe tout seul.
Et donc il peut le réunir quand il veut.
Il y a plein de trucs autour de ça et donc ça, c'est ce qui va plutôt intéresser les grosses boîtes.
Après, on a des moyennes grosses boîtes qui rentrent par Covri là-dessus et puis qui disent, ah putain, mais en fait, ça marche bien.
C'est cool, en fait, on va commencer à basculer de la prod aussi dessus.
Et donc comme ça, ça leur permet d'avoir le faux complet et du coup, cloner des environnements, c'est relativement simple, du coup, dès lors que tu as tout.
La question, c'est est-ce que je peux mettre un Covri et continuer d'avoir le reste de ma prod qui fait autre chose ?
Est-ce que c'est un... comment si jamais demain, j'ai déjà une prod, je peux intégrer Covri à certains de mes développements ?
Je ne sais pas, je suis sur Azure par exemple, ou je suis chez GCP, AWS.
Comment je vais intégrer Covri ? Je dois faire un truc complètement à côté ou pas ?
Alors ça dépend du niveau de maturité des boîtes.
Typiquement, si tu es une boîte qui fait déjà du conteneur, tu as ta CIA, tu sais déployer du conteneur aujourd'hui, tu buildes tes images, etc.
On ne va pas rebuilder à chaque fois de nous aussi les images.
Tu peux aller directement chercher le conteneur sur un registri.
D'accord ? Donc si déjà tu fais du conteneur, tu as moins de boulot à faire, on gère aussi Elm.
Donc si tu déployes du Elm, ben avec Covri, tu peux aussi déployer du Elm.
Tu peux déployer en fait quasiment tout ce que tu veux.
On a un truc qui s'appelle Life Hiker Job, et dedans tu mets absolument ce que tu veux.
Tu peux mettre du Elm, tu peux mettre du Terraform, tu peux mettre du ShellStream, du go, peu en peu en peu.
Donc tu peux déployer vraiment tout ce que tu veux.
Et donc en fait, il y a des transitions qui se font comme ça,
où typiquement tu vas avoir une prod qui est sur un compte AWS, dans un VPC en particulier.
Le client va décider de déployer Covri sur un autre VPC, il va faire du VPC Piring entre les deux,
et il va commencer à faire communiquer ses infras, ce genre de choses, et petit à petit, en fait, il passe
du coup ses environnements dev ou ses jeux de test sur Covri.
Alors des fois c'est très très simple, parce que comme je t'ai disais, ils ont déjà une CIA avec des conteneurs, etc.
et donc on vient juste récupérer les conteneurs, et puis des fois ils sont un peu moins matures sur ce côté-là
et donc ils font pas aussi vers plus de cloud native et ce genre de choses.
Ça dépend vraiment des clients, leur infra et leur maturité.
Et quel est l'intérêt justement d'utiliser Covri pour du HL?
Moi si jamais j'ai déjà toute une stack avec du HL, du Kubernetes,
enfin si jamais c'est du HL, il y a du Kubernetes.
Mais quel est l'intérêt que je vais avoir là d'utiliser ça?
Ça va être que pour des gens qui sont on-prem et vous installez directement un Kubernetes,
ou est-ce que c'est quelque chose à mettre sur les Incloprider?
Enfin, quel va être l'intérêt et sur quel environnement je vais pouvoir le mettre?
Aujourd'hui, on ne fait pas de on-prem, c'est que du cloud.
Ça va, c'est en train de changer, enfin en train de rajouter ce type de fonctionnement aussi.
Mais ce qui est important de comprendre, c'est que HL, la destination qui c'est qui va vraiment utiliser ça?
Généralement c'est les DevOps, c'est les SRN.
La plupart du temps, pour pas dire 90% du temps, à chaque fois que je parle des devs qui doivent eux-mêmes déployer du HL,
en fait c'est un enfer parce que c'est un bout de la stack que eux n'ont pas envie de gérer.
En fait c'est une dépendance qui leur a été plus ou moins imposée,
parce qu'en fait on leur a dit que s'ils voulaient telle ou telle truc qu'il fallait qu'il passe par,
et puis ils devaient gérer ça, et en fait juste ça les ennuit.
Alors quand tu passes par Covri, t'as une interface qui te permet de dire bah voilà.
Moi mes DevOps, ils m'ont préparé un environnement.
Je sais que si ça je le clone, je le déploie, en fait je vais avoir tout qui va marcher
et je vais pouvoir builder par-dessus.
Et en fait les devs ils ont la main parce qu'ils contrôlent exactement et ils peuvent faire tout ce qu'ils veulent en fait dans un environnement.
Ils peuvent même, je dis faire du terraform donc déployer des services tiers sur des cloud provider qu'on ne gère même pas du tout.
Et faire en sorte que ça soit vraiment très très simple pour le end user.
En fait la force elle est là, on cherche pas à changer les méthodes classiques que DevOps dit là.
C'est vraiment on cherche à amener une expérience que le développeur ne peut pas avoir aujourd'hui.
Ok, donc là en fait si jamais je veux une base de données, donc comme ça le développeur peut directement demander une base de données.
T'as parlé tout à l'heure de soit des conteneurs de base de données, soit des bases de données manager.
Aujourd'hui vous suportez quoi comme type d'environnement, donc si jamais c'est pas le on-prem,
ça va être quel type, c'est GCP, AWS, et Azure.
Ouais, alors deux bases nous on supporte, quand je te disais manager aujourd'hui on ne fait que AWS en manager.
Et il y a que les quatre bases que j'ai citées de tout à l'heure.
Donc MySQL, Postgreer et Diss et Mongo, ça sert à quoi.
On ne compte pas forcément en mettre plus parce qu'on a les life cycle jobs déjà,
qui permettent du coup de déployer autre chose si tu veux faire du dynamo,
si tu veux faire des bases de données spécifiques à Google,
ou tu veux faire du MongoEc class ou n'importe quoi en fait, tu peux le faire déjà.
Et début d'année prochaine on va arriver, donc on remarque qu'on a déjà un petit petit,
donc remarque que c'est le sigo de Covain, mais on arrive avec une espèce de plateforme open source
qui permettra en fait d'avoir une espèce de catalogue si tu veux,
sur lequel les DevOps vont pouvoir builder par-dessus et proposer sous forme de catalogue,
aux développeurs de pouvoir déployer en fait certains services.
Donc ça peut être du complètement in-house, ou ça peut être des trucs externes,
comme je viens de citer mon boîte là, ce genre de truc.
C'est bien que tu en parles de genre de choses parce que j'étais à l'OVH Summit il y a peu
et je parlais avec Levercloud, oui, ils parlent avec Levercloud.
Et justement eux ils ont un peu cette problématique là, en fait, où tout le monde aujourd'hui
on voit qu'il y a un mouvement vers une espèce de pass-à-tage qui tend à apparaître.
Donc moi j'avais un projet comme ça depuis très longtemps qui s'appelait K-Appliance,
mais il y a cette notion en fait de création de plateforme et de définir ce que c'est qu'une plateforme.
Et je pense justement qu'il y a un travail qui pourrait être fait justement au sein de la communauté,
donc c'est cool si jamais vous le faites en open source,
ce qu'on n'a pas dit c'est que là votre logiciel covrit pas open source en tout cas je ne crois pas.
Il y a une grosse partie qui est open source, t'as 70% qui est open source.
D'accord, il y a juste le Control Plane qui n'est pas open source, mais sinon tout le reste est open.
Au plus que l'installation chez les clients est open source, tout ce qui est chez toi et que c'est actuellement le paradis.
Ok.
Et donc en fait cette notion de définition de plateforme, c'est vrai que c'est intéressant,
là t'as parlé typiquement de quatre bases, et c'est vrai que c'est ça en fait,
ce qui est intéressant en définition de plateforme, c'est quelles sont les services que je vais pouvoir aller
requêter facilement qui sont disponibles l'un de l'autre.
Et l'idée par exemple qu'on avait eu, ok, encore, je te dis ça, on n'a pas discuté avant,
mais l'idée qu'on avait eu c'est peut-être de définir des levels de plateforme
et de se dire par exemple, une plateforme de level 1, c'est une où il y a,
genre juste je fais tourner des conteneurs et à la limite j'ai un XATCP,
une plateforme de niveau 2 c'est celle où tu vas directement avoir une notion de l'autre d'Allenser,
niveau 7, HTTP, et peut-être un MySQL,
et un niveau 3 tu vas avoir MySQL, Redis, toute la stack, etc.
Le but étant en fait de pouvoir se comparer et pouvoir dire dans tel environnement,
je suis une plateforme de niveau temps, c'est-à-dire que j'ai tel service qui a été ajouté
et dans un autre, dans un autre cas je suis à niveau temps.
Un peu le but étant de reproduire ce qui s'est passé dans le X86
avec les variantes de X86 qu'on a fait parce qu'il y a une pléthore d'extension
qui ont été rajoutées à X86 et aujourd'hui c'est dur de savoir
quand je fais un logiciel il doit tourner sur telle variante de X86,
bah voilà il y a le V1, V2, V3, ce qu'on appelle les micro-architectures,
et le but étant peut-être d'avoir ce type de définition de ce que c'est qu'une plateforme
pour pouvoir se comparer et pouvoir faire en sorte qu'un client qui vient chez toi
déjà un, ça tilt beaucoup plus, ça permet de ne pas créer des plateformes
comme ça isolées les unes des autres et d'avoir vraiment de créer un écosystème
qui pourrait, le but étant pas qu'on ait tous la même, c'est juste de définir
quel est de l'extérieur pour un client qui sache lui définir son application
disons bah moi mon application je sais que c'est une application de level 2
et donc elle doit pouvoir tourner chez Covri, chez OVH je sais pas quoi,
ou chez un, non c'est ça le but, vraiment non,
pourront en discuter à un moment donné mais c'est vrai qu'aujourd'hui
toute cette notion de création de plateforme est assez compliquée
et c'est assez flou quand on parle à des clients, c'est une plateforme de type héros-coups,
c'est quoi, enfin c'est compliqué aujourd'hui quand on parle,
quand on parle au client et pour naître, je sais pas quel est ton ressenti par rapport à ça
oui oui, de toute façon c'est pas mal de nouvelles terminologies qui arrivent
clairement on passe avec du coup différents marchés américains, asiatiques, européens
on voit que le niveau de maturité est pas le même
tu vois le plus, le niveau de maturité que tu vois c'est un...
bah le marché américain est un peu plus mature, en tout cas
il y a un peu plus connaissance de ce genre de choses, même si dans certains cas
ça reste en cours flou, notamment parce que si tu cherches IDP pour Tarnal Developer Platform
tu as plein d'autres termes qui correspondent à IDP
et puis tu as des personnes qui se projettent avec un portail
parce que c'est la finalité, mais en fait ce qu'ils cherchent à la base
c'est plutôt une IDP, ils veulent qu'il y ait un portail aussi
mais en fait ce qu'ils veulent c'est l'IDP
et donc on peut les faire rentrer par le portail parce que c'est ça
enfin c'est ça qu'ils ont en tête, mais la finalité c'est vraiment une
Tarnal Developer Platform
et c'est vrai que c'est pas évident parce que c'est un peu comme
tu vois la CI CD il y a 10-15 ans, il y a pas mal de gens qui se disaient
ouf, ouais j'ai pas raison, j'en ai vaguement entendu parler
ouais ça a l'air pas mal, ou ça sert pas à grand chose
ou ouais ça peut être intéressant vers un plus tard
et en fait aujourd'hui tu vois personne sans une CI CD
et on pense que l'IDP c'est la même chose
c'est un maillot manquant aujourd'hui
et on pense qu'avec ça du coup
on comble un gros manque de pas mal de boîtes
et du coup quand on a des boîtes qui viennent de nous voir
en fait c'est assez rigolo parce qu'on a des boîtes qui viennent
avec qui on discute, ils me font, ah ça a l'air super intéressant
bon on verra, ou des fois ils essayent en interne
et puis tu vois un an, un an et demi après ils reviennent
on essaye en interne, c'est bordel, c'est super compliqué
en fait ça paraît simple mais en fait c'est trop compliqué
donc du coup ils essayent covrir et ils sont super contents
mais c'est vrai que c'est quelque chose qui encore nous vaut
je pense qu'il y a encore besoin d'un petit peu de temps
qui se passe pour que tout le monde l'intègre bien
ouais et ce que je me dis aussi en même temps
on a besoin d'avoir cette notion de standardiation
en fait tu parlais des noms et les noms c'est ultra important
les mots, les concepts, de bien les définir
pour pas justement que ça devienne un peu trop n'importe quoi
et c'est vrai qu'aujourd'hui les plateformes interne de développement
c'est vraiment pas, c'est pas forcément compris
je le vois souvent quand je vais te quitter dessus
où il y a vraiment un manque de culture par rapport à ça
j'essaye même moi en interne donc chez Cégin
d'apporter ce type de réflexion là d'une plateforme interne
et aujourd'hui on va regarder avec des yeux un peu
mais qu'est-ce que tu essayes de nous raconter quoi
c'est vraiment le problème
et aussi parce que alors là
aujourd'hui ce que je vois et c'était
pas mal de gens le disent même sur Twitter
c'est les plateformes de développement interne
en fait elles viennent dans une sorte de volonté
de standardisation de ce que Kubernetes a amené
en fait c'est vraiment la suite logique de Kubernetes
on a eu Kubernetes qui a ouvert les vannes
de plein de choses, de plein de possibilités
de standard, enfin pas justement de standardisation
mais de façon de faire très différente
et aujourd'hui on a peut-être besoin justement
pas de rationaliser mais de capitaliser
surtout ça en fait et que les gens qui étaient en amont
qui étaient en avance sur ces sujets là
aujourd'hui elles amènent un peu à tout le monde
en fait voilà Kubernetes c'est très bien
ça peut faire tout ça et aujourd'hui
en standardisant un peu les labels
en standardisant un peu deux trois sujets
on arrive justement à se remettre dessus
c'est vrai que je vois Covri
c'est marrant je vous vois un peu
donc là dans la description comme un crossplane
qu'on aurait très très customisé pour un besoin précis
en fait un crossplane étant un gel qu'on peut mettre
un CRD de CRD de CRD
dans Kubernetes mais qui permet justement
de définir voilà qu'est-ce qu'une base de données
alors je sais plus comment ils les appellent ça
mais on peut avoir des espèces de méta
de méta-déploiements en fait en disant
bah moi je propose une base de données
mes clients peuvent aller les requetter
il y a ça et c'est vrai que
on sent qu'il y a vraiment tout ce besoin
en fait de gestion
de gestion du drift aussi qu'on va avoir
quand on fait beaucoup de terraformes
de se dire bah qu'est-ce que font les gens quand ils
touchent à plein de sujets
donc je sais pas aussi si vous ça justement
vous allez réussir à gérer le drift
comme je me dis que tout est fait
via l'interface en tout cas via des épiais que vous allez
faire bah il peut y avoir en tout cas moins de drift
que d'avoir 4 milliards de façons
différentes d'aller toucher aux mêmes ressources
dans Azure
exactement le fait de standardiser
et de tout contrôler à ce niveau-là
ça nous permet aussi de rajouter des fonctionnalités
qui sont pas forcément évidentes
sur tous les cloud providers
parce que effectivement
on a buildé au-dessus de Kubernetes
et
aujourd'hui on propose 3 cloud providers
AWS, GCP, Scaleway
et pourtant sur ces 3 cloud providers
en fait on essaye
de standardiser le truc
pour que
toi en tant que développeur
si tu fais du Scaleway
du GCP ou de la AWS en pensant
parcouvrir en fait c'est exactement
la même chose pour toi et demain on me dit
tiens on va changer de cloud provider
en fait bah ok tout à l'heure je t'ai parlé
de la fonction de clonage
mais en fait tu vas pouvoir cloner
tous tes environnements et les passer
sur un autre cloud provider sans problème
parce qu'il y a des clients par exemple
qui veulent la stabilité
quelque chose d'assez poussé
qui prennent de la charge etc
et donc ils vont utiliser typiquement AWS
et puis pour des questions
de coût et puis parce qu'ils ont un usage
aussi qu'est moins enfin plus restreint etc
ils vont avoir par exemple du Scaleway
pour tous leurs environnements
dev ce genre de trucs
donc je te dis que vous vous dites qu'il est capable de gérer
ce type de débordement de dev
sur de ce type
c'est quelque chose qui est souvent
enfin en ce cas que j'ai souvent essayé de demander
et qui rare d'avoir dans les boîtes
enfin c'est... souvent on l'a dit
que c'est de la proche
ah oui parce que t'as l'impression que c'est 2 ou 3 fois le taf
en fait à chaque fois
parce que les cloud providers ils sont gentils
mais c'est vrai qu'ils sont complètement
hétérogènes et ils n'ont quasiment aucune homogénité
et c'est là
où Kubernetes arrive
à donner une certaine homogénité
et donc c'est bien de build up par dessus
il y a toujours quand même des petites spécificités
quand tu pousseras par l'autre balancer
ça va pas être les mêmes annotations
enfin security group etc
il y a toujours des spécificités
donc nous ce qu'on essaye de faire c'est vraiment masquer cette complexité là
et du coup
pour le end user ça ne change
absolument et enfin pour lui c'est pareil
et est ce que demain je pourrais avoir quelque chose qui
plutôt une interface type kubanthys
ou est ce que même vous le proposez
c'est à dire moi qui fais du kubanthys je vais pouvoir en fait
déployer des ressources type CRD
et en fait me dire bah en fait je déploie
dans le control plane de
de covris et
automagiquement ça va aller sur les
enfin voilà d'utiliser comme interface
justement dont on parlait l'interface
des PI kubanthys qui à peu près standardisait par exemple
et de se dire en fait je sais pas trop sur quoi stop
mais en fait
c'est covris et covris va gérer ça
un endroit
ouais alors j'ai un peu de réponse à te faire
la première
c'est oui on peut voir
les choses comme ça on a déjà des clients qui voient les choses comme ça
rapidement ils ont du terraform aujourd'hui
avec leur infrastructure
nous fournir un terraform provider
ils viennent juste pluggé covris
sur leur existant terraform
et ils build par dessus
ça c'est la première réponse
la deuxième c'est
on est en train de sortir une version qui sortira
plus d'année prochaine
qui va te permettre de déployer covris
sur un cluster déjà existant donc nous
on ne gérera pas le cluster c'est toi qui mettra
tout ce que tu veux dedans on viendra
avec quelques prérequis on me dirait il faut ça
si tu veux pouvoir faire si
ce genre de choses mais derrière c'est toi qui va
gérer pour terminer
aujourd'hui avec ce qu'on propose tu sais je t'ai dit
on déploie sur l'infrastructure
de nos clients ce qui fait que
eux-mêmes en fait on accès à la PI kub
ils peuvent déjà déployer tout ce qu'ils veulent
s'ils ont envie de déployer des CRD et faire ce qu'ils veulent
avec les life cycle jobs
typiquement c'est possible on a des clients
qui utilisent crossplane comme tu disais tout à l'heure
en fait ils ont juste préparé
des life cycle jobs avec une conf
déjà préfaite de crossplane
quelque part dans le environnement etc
ils fournissent ça leur dév
et ça marche donc voilà
il y a quelques prémitifs qui te permettent de déployer
des trucs déjà tout fait comme les bases données
et puis derrière dès que tu veux déborder
en fait tu utilises les life cycle jobs
et puis ce qui arrivera après du coup
c'est un catalogue de services pour avoir un truc
vraiment plus joli plus fournible
voilà
là aujourd'hui en termes de
marché qui vous adressait
on a parlé un peu de la taille tout à l'heure des entreprises
mais quand on parle de la taille des équipes
ça va être donc des équipes de 3 personnes
si jamais c'est une entreprise de 3 personnes dont tu parlais
mais ça peut monter
à beaucoup de développeurs enfin c'est quoi à peu près
aujourd'hui la taille
qui vous avait préparé pour votre outil
parce qu'il y a toujours ça il y a le marché
attendu
c'est une bonne question
aujourd'hui les clients qu'on a
les plus gros qu'on a eu
ils avaient des environnements avec
à peu près 150 apps dedans
donc tout qu'on fout du base des données
broker, backend, fontaine
c'est assez rare quand même
d'en avoir autant généralement
tu vas être... enfin tes services
ne sont pas de cette taille
et puis c'est surtout que derrière ça va être aussi
découpé en fonction des équipes
tu n'as pas forcément envie d'avoir un environnement
avec toutes les équipes qui sont dedans
enfin voilà sachant que
des environnements
suivant comment tu fais les choses
tu peux faire en sorte qu'ils se parlent entre eux
donc en fait tu as des projets
dans tes projets tu as tes environnements
et donc tu as tes environnements de prod qui peuvent se parler
donc je dirais que c'est assez aussi
couper en fonction de l'organisation
de l'entreprise
tu vois ils vont gérer ça comme ça
et après ça
les environnements...
c'est d'avoir ces petites équipes là découpées par organisation
et après avoir un top au-dessus
ouais exactement
nous le découpage
c'est... alors cluster
c'est virtuel
c'est à dire que tu peux avoir plusieurs clusters
mais toi au niveau de ton interface tu as tout dans le même truc
on a des airbags qui te permettent du coup
d'autoriser ou pas la vue de certains clusters
et pareil pour les projets et pour les environnements
et ensuite tu as un projet
donc enfin tu as X projet
et dans chaque projet tu as les environnements
voilà comment ça se passe
après...
ça permet quand même de gérer
quand même une complexité
en ayant cette yorki là
ça permet de savoir un peu à qui on s'adresse
que c'est vraiment que pour au fait pour une équipe de 3 personnes
ou est-ce qu'on peut aller...
ouais non non on a des équipes
enfin les plus grosses qu'on a elles sont
dans les 50 personnes
donc ça commence à faire quoi
donc il est pas rare de voir genre
de son environnement fmr quoi
tu vois
ça c'est quelque chose d'assez courant
maintenant
c'est pas quelque chose non plus comme je disais
que tu laisses tourner tout le temps parce que c'est un coup derrière
donc
ça... c'est un cycle de vie
tout ça si tu veux, il y en a beaucoup qui éteignent
aussi le soir et qui rallument tout le matin
voilà il y a différents scénarios possible
et sachant qu'il y a une API aussi
il y en a qui a bien scripté
et build up par dessus
voilà, il y en a même qui utilisent pour des commerciaux
ils font des plateformes spécifiques
à chaque fois pour les commerciaux
et les commerciaux même arrivent à utiliser le produit
exactement
donc on a pas mal de use case différents
ok cool
et donc là je suis en train de parler des PI etc
donc ça on a parlé de control plane
bon alors quand on voit un peu ce que vous avez fait
sans doute vous faites ça en rust
le under the hood justement la tue
c'est parce que vous avez un seul control plane pour tout le monde
que vous avez voulu avoir de la performance
pour ça, quel était un peu les motivations
techniques derrière
ouais
alors quand on a commencé de covris
on va aller vite
parce que quand t'es une petite boîte
que t'as pas trop de thune, que t'as la seule solution de t'en sortir au début
parce que on n'est pas un produit qui se build
en 2 semaines
t'as besoin d'argent
pour survivre
du coup on a appris le langage que vous connaissez le mieux
donc c'était le piton
et c'est bien
mais quand tu fais de l'infra
enfin tu sais bien que l'infra il y a des fois
même souvent t'as pas le droit à l'erreur
si tu te trompes d'un truc c'est ta preuve que tu as foutu par terre
la récupérer ça se fait pas forcément 2 secondes
enfin c'est pas un rollback applicatif
state less et you piece repartie
quoi
et piton
le problème
ce soit pas fortement tippé
qui n'est pas de compile
enfin voilà ce genre de choses
et en reste
ayant un peu le vent poube à côté
mais qui est pas simple après en dé
donc clairement on avait pas de problème de perf
et on a pas de problème de perf à proprement parler aujourd'hui
parce que la plupart du temps
c'est du network IO
qu'on fait et où on attend en fait
les cloud provider
on a certaines parties qui nécessitent un peu de perf évidemment
mais la plupart du
du temps où on utilise
en tout cas cette partie là en reste
c'est de la tente
en fait ça nous permet d'avoir
une très bonne stabilité
si tu veux sur notre produit
on a très peu de bugs
quand il y a des bugs c'est des problèmes humains
c'est pas parce qu'on a
confondre d'une string et un hint
et puis que le machin enfin bon
des trucs débiles quoi
c'est un langage qui est récent du coup
et qui permet de faire pas mal de choses
ça des génériques
enfin voilà il est déjà complet
en fait et il est très bien pour ça
maintenant tu vois on parlait
du control plane
le control plane typiquement n'est pas fait en reste
il est fait en cocline
avec du spring boot
pourquoi simplement parce que
sur la partie front plugin etc
web
on trouvait
à l'époque c'est encore un peu le cas maintenant
que la partie reste est encore très jeune
sur cette partie là et on avait besoin
de quelque chose de mature
parce que on voulait vraiment que ce soit reliable
et puis pas non plus passer 50 ans
parce qu'on en revient toujours à cette histoire
dessous mais quand t'as une start up
malheureusement c'est pas même d'un autre
quelle boîte tu fais attention à ça
ça rentre dans l'équation
et donc on s'est dit on part sur reste
parce qu'on voulait quelque chose de voilà
qui puisse être validé à la compile
on pouvait mettre beaucoup de trucs
beaucoup de trucs comme ça à éviter
les erreurs classiques
et la partie web du coup
c'est plutôt content
après je vois venir ta question
pourquoi pas go
par exemple oui en effet
quand on parle d'infra
même à ce moment là pourquoi pas du go
sachant qu'une grosse partie de l'écosystème
aujourd'hui auquel vous touchez est quand même fait en go
tout à fait
donc ça c'était pareil
grosse question pour Internet on a
fait un poc des deux quand on
devait switcher
et on a regardé en fait sur des compiles
à faire des tests tu vois d'erreurs classiques
voir si le compile
il prenait bien compte de ce qu'on voulait etc
et le compile laisse passer quand même pas mal
de trucs en go
ce qui est un peu normal quand tu vois les temps de compile
tu comprends les deux
mais du coup on a c'est ce qui nous a un peu plus
décidé à partir sur reste
c'est vraiment la rigidité
inhérente au langage et compiata
ouais on peut voir ça comme ça si tu veux
ouais mais ça se comprend
parce que go quand il est arrivé était
lui-même quelque chose d'assez rigide pour
pour ce moment là mais c'est vrai qu'aujourd'hui
il y a toujours des
mal façons entre les mecs qui peuvent passer
en go très régulièrement
donc oui ça peut se comprendre là-dessus
et j'ai vu que vous aviez notamment des nouveaux
projets là pour le coup on va aller sur du web
et sur du reste donc j'ai vu passer
des projets pour des
développeurs portals c'est ça
c'est quoi ?
ouais c'est ça c'est ce dont je te parlais
de tout à l'heure le catalogue de service en fait
c'est un peu l'idée c'est de se dire
ok moi je suis DevOps
je vais proposer quelque chose
à MEDEV je vais pouvoir
bider que ça soit joli à avoir
une interface j'ai l'habitude d'écrire
du Yamel ou en tout cas un long
enfin ce type de langage quoi
de pouvoir faire du déclaratif
je veux rester sur ce genre de modèles
et je vais pouvoir proposer
à MEDEV une interface
qui soit jolie qui
qui puisse la comprendre
comprendre ce que je leur demande
typiquement s'ils veulent déployer une base de données
je vais leur demander un login, un mod pass
je vais leur demander ce genre de choses
et en fait ça te permet de construire
ton input, ton output
et d'être complètement agnostique
sur qu'est ce qui va être déployé derrière
donc tu peux utiliser du docker, tu peux faire de la command line
tu peux faire voilà l'idée c'est un peu ça
et donc du coup tu vas pouvoir proposer
quelque chose
facilement en tant que DevOps
et qui va être utilisé
et utilisable simplement par TDF
et pourquoi pas par service au
du backstage qui est aujourd'hui
la technologie en vogue
sur ce genre de choses là quand on parle
de portail interne
parce que le niveau de complexité
de backstage est bien au-delà
de ce qu'on peut imaginer en fait
pour ce que ça fait et dès lors
que tu veux te lancer là-dedans
encore une fois on essaye d'être problématique
on essaye des réseaux de problèmes
qu'on rencontre régulièrement
et qu'on nous remonte
et ça ça fait partie
backstage on a pas mal de clients qui sont
cassés les dents dessus parce qu'ils pensaient que ça allait
être rapide à mettre en place
et en fait ils se rendent compte qu'il y a besoin
quasiment d'une équipe derrière pour maintenir le truc
faire le mettre en place et tout le face
c'est l'air d'être de la folie donc du coup
on a essayé, on a vu les points faibles
on se rend compte qu'il y a une population
chez qui ça doit plaire clairement
maintenant nous on pense qu'on peut faire plus simple
et que ça puisse couvrir
une population bien plus large
donc c'est ce qu'on essaye de faire
à l'heure de Tori et n'hésitez pas
à contribuer même si vous voulez
apprendre le reste parce que c'est faire le reste
pour Tori
oui parce que backstage
c'est fait en type script et c'est vrai que pour
pour avoir des interfaces dans backstage
et avoir rapidement quelque chose qui est affichable
en backstage en fait il faut comprendre
les mécaniques internes, il faut comprendre le type script
et très souvent tu viens te pluguer
à des choses internes
c'est un logiciel en tant que tel
c'est un framework
de développement web
qui permet d'avoir des primitifs plus simples
pour faire des affichages type et ops
type et platform
vous c'est vraiment
de se comprendre
une configuration d'un côté, enfin un coeur
en rust et après de la configuration
qui vient être ployée donc en fait si jamais
il y a les features qui sont déjà présentes dans Tori
on peut les utiliser
un peu à la volée
c'est ça
oui exactement, c'est vraiment de faire
c'est que ce soit open source et utilisable en dehors
de Covri, bien sûr on va le ployer dans Covri
mais à la base on cherche à répondre
besoin en général
et vous avez d'autres projets comme ça
en voie, enfin d'autres projets dont on ne va peut-être pas parler
ou qui vont arriver des choses
si on en a un qui existe déjà aussi
qui s'appelle ReplayBytes
qui permet de faire
je t'ai parlé de cloné de
environnement et bien souvent ce qu'on nous a dit
c'est oui vous êtes mignon mais vous répliquez
tout ce qu'il state less
mais il state full dans l'histoire
oui effectivement il state full
alors bêtement
on peut se dire bah ouais ok
on va faire un maïs cake done pour faire un truc
comme ça et on va réjecter de l'autre côté
oui c'est ce que ça marche mais
tous ceux qui font du médical, tous ceux qui ont des données
sensibles etc en fait tu peux pas faire ça
et puis des fois tu n'as pas forcément envie
de répliquer l'intégralité de mon plus de ta base
si elle est un peu conséquente, enfin c'est
un peu plus d'intervention
donc du coup c'est un autre projet open source
qu'on a fait qui te permet
de tu vas cider ta base de données
principales
tu vas pouvoir via de la configuration
en fait dire tel champ je veux l'anonymiser
et je vais l'anonymiser
avec tel type de data
et tu viens cider
la data donc tu peux même la cider
partiellement si tu souhaites
et tu vas me stocker tout ça
en fait le jeu de données que tu as racontrugues
tu vas me stocker sur s3
ce qui fait que quand après tu viens cloner
en environnement
dans l'environnement
enfin quand tu cloues dans l'environnement et que tu veux le déployer
après c'est un différent stage
donc typiquement tu déploies d'abord tes bases de données
et puis après tu vas avant de déployer tes apps
tu vas dire tiens je passe sur un stage
un stage de seed
et donc là tu vas récupérer ta donnée que tu as
bumpé sur s3
et donc qui est anonymisé et tu vas automatiquement la réinjecter
et une fois que ça s'est fait, tu passes au déploiement
des apps
ça c'est un projet open source que vous avez encore en rust
exactement
il y a une bonne communauté
commune tactile
on a même un peu de mal à suivre pour être honnête
tellement il y a d'engouement
c'est super chouette
parce qu'on a des clients qui utilisent en prod
on a des comiteurs qui viennent rajouter
des bases de données qu'on supportait pas
franchement c'est top
covry, covry, futur boîte de anonymisation
des données c'est ça
à la docker style
à la docker style
dottloud
disons que c'est un side project pour nous
même si c'est un produit
quand on veut pareil
il est pas intégré dans le produit
bien intégré aujourd'hui dans le produit
c'est quelque chose qu'on va faire aussi
on est content
en tout cas on essayait de répondre
à des problématiques
on voit qu'il y a de la trait et de l'engouement derrière
aujourd'hui tu es une équipe de combien de personnes
qui travaillent sur tout ça
aujourd'hui on a une petite dizaine
côté tech donc front, back, product
et voilà
est-ce que tu as envie de le passer un message
rejoigné nous ou pas
ou on n'a pas le...
on n'est pas
complètement fermé mais on n'a pas de poste
réellement définie aujourd'hui
l'année prochaine c'est sûr on ouvrirait les vannes
mais pour l'instant
il faut qu'on reste focus
et on a encore quelques trucs à délivrer
notamment je te parlais tout à l'heure
tu as d'une version
que tu peux déployer sur un cluster cube
déjà existant
ce genre de choses qui n'est plus géré par Covri
on a GCP aussi là qui arrive
début Q1
on gère en mode manager
des nouveaux cloud providers on fait une version
moins manager
et c'est justement c'est compliqué aujourd'hui
de trouver des ressources
des ressources compétentes
en rosse mais pas que même juste sur l'infra
et Q1 c'est...
effectivement
je vais pas dire que c'est des moutons à 5 pattes
mais c'est très compliqué aujourd'hui
parce que tout DevOps
ou tout SRE que tu connais
enfin c'est très très rare de tomber
quelqu'un de très très bon
qui est aussi bon enfin 55 ans
t'as toujours généralement
une préférence
ou une appétence un peu plus forte
côté dev ou côté système on va dire
et donc ça c'est pas facile
en plus on fait du reste donc tu libides
encore plus donc on sait très bien
que les personnes qu'on embauche
le pourcentage de chance qui soit 100% compétente
jour 1
c'est projeux 0
donc après on sait qu'il y a pas mal
de formations
le rent-peuble chez nous c'est entre 6 mois
et 1 an en général
donc c'est assez long
mais après d'ailleurs du coup c'est cool parce que
ça fait des personnes qui
pas qu'on a de la compétence sur pas mal de sujets
et c'est très vaste parce que tu imagines
plusieurs clottes provider tu rajoutes
Kubernetes, tu rajoutes Rust
et puis on a un peu de go aussi
tu vas par exemple provider Terraform c'est un go
la CLA il est en go
voilà on a quelques petits trucs en go
parti par là mais c'est pas le
langage principal non plus
mais ouais
bon bah super merci beaucoup
en tout cas j'espère que tout le monde aura
une meilleure idée de ce que c'est pour venir après vous voir
en tout cas quand ils verront
qu'ils comprennent peut-être ce que c'est
ce que ça peut apporter et peut-être même qu'on disons
des problèmes ils se diront merde
à ce moment là j'aurais dû
installer un covri
c'est souvent ce qu'on peut se dire
donc bah super merci à toi
merci pour ton intervention
je pense que les gens pourront aussi pinger sur
ou est-ce qu'ils peuvent te trouver si jamais ils ont des questions
sur covris ?
si ils ont des questions sur covris
ils peuvent essayer LinkedIn
ils peuvent essayer le produit aussi
ils peuvent faire une demande pour avoir accès
on a une version de test
c'est quelque chose qui est facilement faisable
et sinon on a un forum aussi
donc c'est discus.cobri.com
et puis voilà
je pense qu'ils auront quoi
et sinon il y a les projets open source
si jamais ils veulent contribuer
super
merci beaucoup