DevObs

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 Covry.

Le but étant de vraiment comprendre un peu plus Covry, ce qu'ils font,

comment ils en sont arrivés là, et de voir un peu ce qu'ils vont faire dans le futur.

Je me présente, du coup je m'appelle Pierre Mavro, je suis CTO et Co-Founder de Covry.

Je suis passé par pas mal de boîtes, ça fait une vingtaine d'années que je travaille,

donc je suis passé par des boîtes qui c'est de la finance de marché donc Qlink

des boîtes un peu plus grosses qui c'est des OS et tout un tas de choses de

ce type là Red Hat ou encore de l'ADS chez Criteo,

et et donc j'ai on va dire un

début de carrière plutôt 6 admins puis DevOps puis SRE et puis SRE Dev enfin

plus Dev que du coup système aujourd'hui donc si vous avez notre bio vous saurez

qu'on s'est rencontré justement donc chez Criteo t'es pas dans exactement la

même équipe mais on a travaillé ensemble et donc depuis Criteo,

toi justement t'es parti sur Kovri, est-ce que tu peux un peu présenter ce que

vous faites chez Kovri justement ?

Du coup Kovri on est une internal développeur plateforme,

donc en gros ce qu'on va permettre, 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 sans

exposer la complexité d'infra au dev.

Donc, on peut voir ça comme un mode self-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 qu'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 qu'il y en a plusieurs,

d'ailleurs, je ne sais pas.

Alors nous, ce qu'on demande, c'est un Dockerfile et un repo.

Donc on fait le build. Ce n'est pas obligatoire, mais on peut le faire.

Une fois que l'image est créée, 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 maille, mais ce qu'il faut comprendre,

c'est qu'à la base, nous, ce qu'on fait, c'est de l'infra.

C'est-à-dire qu'on va déployer une infrastructure state-of-the-art sur le compte cloud de nos clients.

Comme ça, c'est l'infrastructure des customers.

Nous, on a un contrôle plain de notre côté qui permet justement de lancer tous

ces déploiements à distance.

Donc, au travers soit d'une interface, donc pour les devs une console c'est

très pratique, soit une CLI, soit du Terraform, vous allez pouvoir en fait contrôler

tout ce qui se passe sur Kovei.

Donc l'idée c'est de pouvoir déployer des bases de données, des applications,

en fait tout ce dont un développeur va avoir besoin pour tout simplement développer

des fonctionnalités sans vraiment se prendre la tête.

Que ce soit très, très simple. Il y a beaucoup de complexités qui sont masquées.

Et donc, justement, pour un développeur, donc là, tu as dit que c'était un repo et un Dockerfile.

Si jamais je veux déclarer l'accès à une base de données, des choses comme ça,

comment ça va se passer, justement ? Est-ce que j'ai besoin de demander à un

DevOps qui va 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 quatre bases 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 frontend, on va faire simple et une base de données,

tu crées ces trois 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

un simple clic sur l'interface et en quelques secondes,

tu as ton conteneur de base de données.

Et en fait, on vient automatiquement injecter tout ce qui est environment 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 a besoin de DB host, DB login, DB password, etc.

» nous on a créé des built-in environment 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 un WordPress ou ce genre de choses que tu vas déployer 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 c'est un simple alias.

Et si tu veux l'avantage de ça, c'est que les développeurs quand ils font une

nouvelle feature, ce genre de truc, 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 te permettre de cloner un environnement complet.

Et donc, tous les aliases, 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.

Même si tu as 50 applications dans ton environnement, ça va se faire tout seul.

La seule chose que tu auras à reparamétrer, c'est tout ce qui est vraiment unique,

typiquement si t'as mis un custom domaine ou si t'as mis des secrets t'as pas

forcément envie de partager les secrets ça c'est le genre de choses qu'il faudra

que tu remettes mais sinon 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 t'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 CI.

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, il n'a pas besoin de se connecter sur Covery pour faire des trucs.

C'est-à-dire qu'il part de sa branche main, il veut faire une nouvelle feature,

il reste dans son git, en fait, donc dans ce qu'il connaît.

Il teste en local le 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

éphémère, t'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 l'URL sur laquelle il va pouvoir accéder au back, au front,

jusqu'à ce dont il avait besoin dans cet 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 éphémère D'accord,

donc vous gérez les environnements éphémères directement et justement vous êtes

compatible avec GitHub tu le disais avec d'autres environnements ou pas ?

On a GitLab et Bitbucket aussi.

Ok, super. Bon, nous, on est sur Azure DevOps, mais bon, je comprends qu'on

ne va pas supporter Azure DevOps.

Ce n'est pas qu'on ne veut pas, c'est qu'on a quatre ans d'existence aujourd'hui

et qu'il faut choisir des combats.

Et pour l'instant, c'est cela, mais on se ferme la porte à rien du tout.

Quatre ans d'existence, historiquement, c'était ce que vous aviez vraiment voulu

faire ? Comment ça s'est passé, un peu, la genèse de Covery ?

Alors pas du tout en fait donc moi j'étais à Criteo encore et avec donc mes associés,

on avait un play au Techstar donc pour c'est un peu comme le YC 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 l'hélice,

donc du coup ça faisait un moment de façon qu'on avait

des side projects qu'on essayait des trucs et tout lancé dans

un truc qui avait rien à voir c'était de l'analyse d'images

à des fins de marketing donc beaucoup d'IA beaucoup de

trucs comme ça et avec le Techstar ce qui est bien c'est que t'apprends vite

est-ce que ton idée ton produit va

réussir ou pas et on a rapidement vu que ça

n'irait pas donc on s'est reconcentré après sur ce qu'on connaissait qu'est-ce

qu'on fait depuis des années on passe de boîte en boîte c'est quoi notre but

en tant que DevOps etc c'est faire plaisir aux devs enfin en tout cas faire

plaisir leur donner matière à pouvoir utiliser l'infra travailler rapidement être efficace etc etc.

Et comme dans toutes les boîtes, on galère, c'est compliqué,

ça prend du temps et tu as l'impression de refaire beaucoup de choses à chaque fois.

Donc on s'est dit, en fait, le pain point pour nous, il est là,

on va changer du coup notre fusil d'épaule et on va se lancer là-dedans.

Et c'est comme ça que l'aventure, elle a commencé et on s'est dit,

en fait, 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.

Ce sont des gens qui sont très bons côté back, mais côté front,

malheureusement, ce n'est pas forcément les meilleurs pour faire des super UI et UX.

Donc, il faut 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 à

leurs 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 rejoignent, vous en avez pas forcément le nombre exact mais c'est quoi

à peu près la proportion ouais bah aujourd'hui on a une centaine de clients un peu plus.

Et on a des boîtes de 3 personnes qui démarrent avec Kovri et qui évoluent comme

ça et on a des boîtes plus de 200 dev donc c'est assez hétérogène mais ils viennent

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 Covery,

du fait qu'on va te déployer une infra, qu'on va te la gérer,

etc., c'est super pratique au début. Tu n'as pas à te prendre la tête.

Quand on déploie une infra, tu es sort de direct.

Donc c'est pratique aussi si tu veux avoir une besoin de certification rapidement.

Et tu vas avoir des plus grosses boîtes qui viennent parce qu'en fait,

ils galèrent sur les environnements éphémè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. Ça a un coût aussi parce que du coup,

on a fait beaucoup d'optimisation de coût 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 éphémè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 rallumer quand il veut enfin.

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 cover

là dessus et puis qui se disent ah putain mais en fait ça marche bien,

c'est cool bah en fait on va commencer à basculer de la prod aussi dessus et

donc comme ça ça leur permet d'avoir le faux complet et puis bah du coup cloner

des environnements c'est relativement simple du coup dès lors que t'as tout

la question c'est est-ce que je peux mettre un cover 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 Covery à certains

de mes développements c'est quoi je sais pas je suis sur Azure par exemple ou

je suis chez GCP comment je vais intégrer Covery je dois faire un truc complètement à côté ou pas ?

Alors ça dépend du niveau de maturité des boîtes typiquement

si t'es une boîte qui fait déjà du conteneur t'as ta

CI tu sais déployer du conteneur aujourd'hui tu

build tes images etc on va pas rebuilder à chaque fois de nous

aussi les images tu peux aller directement chercher le conteneur sur

un registre et donc si déjà tu fais

du conteneur c'est tu as moins de

boulot à faire on gère aussi elle donc si tu as si tu déploies du mb avec covry

tu peux aussi déployer duel tu peux déployer en fait quasiment tout ce que tu

veux on a un truc qui s'appelle life cycle job et dedans tu n'as absolument

ce que tu veux tu peux mettre du m tu peux du terraform tu peux être du chasse

tri du beau peu importe donc tu peux déployer vraiment tout 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 Covery 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 de dev ou ses jeux de test sur Covery.

Alors, des fois, c'est très, très simple parce que, comme je te disais,

ils ont déjà une CI avec des containers etc et donc on vient juste récupérer

les containers et puis des fois ils sont un peu moins matures sur ce côté là

et donc ils fondent pas aussi vers plus de cloud native et ce genre de choses,

ça dépend vraiment des clients de leur infra, de leur maturité Et quel est l'intérêt

justement d'utiliser Covery pour du Helm si jamais j'ai déjà toute une stack

avec du Helm, du Kubernetes donc si jamais c'est du Helm, 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 ont,

qui sont on-prem et vous installez directement un Kubernetes ou est-ce que c'est

quelque chose à mettre chez un cloud provider enfin quel va être l'intérêt et

sur quel environnement je vais pouvoir le mettre ouais,

aujourd'hui on ne fait pas de on-prem c'est que du cloud.

C'est en train de changer, enfin on est en train de rejouter ce type de fonctionnement aussi.

Mais ce qui est important de comprendre, c'est que Helm, la destination,

qui c'est qui va vraiment utiliser ça ? Généralement c'est les DevOps et les SRE.

La plupart du temps, pour ne pas dire 90% du temps, à chaque fois que je parle

à des devs qui doivent eux-mêmes déployer du Helm, 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és parce qu'en

fait on leur a dit que s'ils voulaient tel ou tel truc il fallait qu'ils passent

pas et puis ils devaient gérer ça et en fait

juste ça les ennuie alors quand

tu passes par Kovri 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

ils peuvent faire tout ce qu'ils veulent dans son environnement.

Ils peuvent même, je t'ai dit, faire du Terraform, donc déployer des services

tiers sur des cloud providers qu'on ne gère même pas du tout.

Et faire en sorte que ça soit vraiment très simple pour le end-user.

En fait, la force, elle est là. On ne cherche pas à changer les méthodes classiques que le DevOps a.

C'est vraiment, on cherche à amener une expérience que le développeur ne peut pas avoir aujourd'hui.

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 bases de données soit des bases de données managées aujourd'hui

vous supportez 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 de base nous on supporte quand je te disais managé aujourd'hui on ne fait

que AWS en managé et il y a que les 4 bases que j'ai citées tout à l'heure donc

MySQL Postgre, Redis et Mongo ça s'arrête là

on ne compte pas forcément en mettre plus parce qu'on a les lifecycle 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 Mongo A-Class ou n'importe quoi en

fait tu peux le faire déjà.

Et début d'année prochaine, on va arriver, donc remarquez qu'on a déjà un petit

peu utilisé, donc remarquez que c'est le signaux de Cowboy,

mais on arrive avec une espèce de plateforme open source qui permettra d'avoir

un 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 certains services.

Donc ça peut être du complètement in-house ou ça peut être des trucs externes,

comme je viens de citer Mongo Atlas ce genre de trucs c'est bien que tu en parles

de ce genre de choses parce que j'étais à l'OVH Summit il y a peu,

et je parlais avec Levercloud oui je parle 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 at edge,

qui tend à apparaître donc moi j'avais un projet comme ça depuis très longtemps

qui s'appelait CapLiance,

00:17:15.340 --> 00:17:18.880