WEBVTT

00:00:43.199 --> 00:00:46.279
Bonjour à tous et à toutes, et bienvenue dans un nouveau numéro de DevOps.

00:00:46.859 --> 00:00:50.259
Alors aujourd'hui, je suis accompagné de Pierre et on va parler de Covry.

00:00:50.399 --> 00:00:54.279
Le but étant de vraiment comprendre un peu plus Covry, ce qu'ils font,

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

00:00:59.279 --> 00:01:03.839
Je me présente, du coup je m'appelle Pierre Mavro, je suis CTO et Co-Founder de Covry.

00:01:04.459 --> 00:01:08.999
Je suis passé par pas mal de boîtes, ça fait une vingtaine d'années que je travaille,

00:01:08.999 --> 00:01:13.079
donc je suis passé par des boîtes qui c'est de la finance de marché donc Qlink

00:01:13.079 --> 00:01:16.919
des boîtes un peu plus grosses qui c'est des OS et tout un tas de choses de

00:01:16.919 --> 00:01:20.859
ce type là Red Hat ou encore de l'ADS chez Criteo,

00:01:21.439 --> 00:01:24.499
et et donc j'ai on va dire un

00:01:24.499 --> 00:01:30.359
début de carrière plutôt 6 admins puis DevOps puis SRE et puis SRE Dev enfin

00:01:30.359 --> 00:01:35.839
plus Dev que du coup système aujourd'hui donc si vous avez notre bio vous saurez

00:01:35.839 --> 00:01:39.179
qu'on s'est rencontré justement donc chez Criteo t'es pas dans exactement la

00:01:39.179 --> 00:01:42.859
même équipe mais on a travaillé ensemble et donc depuis Criteo,

00:01:43.019 --> 00:01:46.319
toi justement t'es parti sur Kovri, est-ce que tu peux un peu présenter ce que

00:01:46.319 --> 00:01:47.739
vous faites chez Kovri justement ?

00:01:47.739 --> 00:01:50.659
Du coup Kovri on est une internal développeur plateforme,

00:01:51.259 --> 00:01:56.899
donc en gros ce qu'on va permettre, notre but c'est de vraiment rendre les devs

00:01:56.899 --> 00:02:01.099
autonomes sans qu'ils aient forcément besoin d'avoir des notions d'infra,

00:02:01.699 --> 00:02:07.599
et c'est de permettre également aux DevOps de pouvoir tout contrôler sans sans

00:02:07.599 --> 00:02:11.319
exposer la complexité d'infra au dev.

00:02:11.919 --> 00:02:15.459
Donc, on peut voir ça comme un mode self-service, en fait, pour les devs.

00:02:15.799 --> 00:02:20.099
En termes d'usage et techniquement ensuite, comment ça se représente ?

00:02:20.099 --> 00:02:23.759
Parce que le terme de plateforme interne, il y en a vraiment beaucoup.

00:02:23.919 --> 00:02:27.499
Alors, en plus, si on rajoute à ça les passes externes qu'on peut connaître,

00:02:27.899 --> 00:02:31.059
là, c'est quoi ? Je pousse mon code un peu à la Heroku.

00:02:31.179 --> 00:02:33.879
C'est quoi exactement, vous, ce que vous proposez ?

00:02:34.439 --> 00:02:36.879
De mettre de main, on prend vos services. Peut-être qu'il y en a plusieurs,

00:02:37.059 --> 00:02:37.619
d'ailleurs, je ne sais pas.

00:02:38.119 --> 00:02:40.539
Alors nous, ce qu'on demande, c'est un Dockerfile et un repo.

00:02:41.599 --> 00:02:44.379
Donc on fait le build. Ce n'est pas obligatoire, mais on peut le faire.

00:02:45.814 --> 00:02:48.154
Une fois que l'image est créée, on va le pousser sur un repo.

00:02:48.694 --> 00:02:50.574
De ce repo-là, ensuite, on va le déployer.

00:02:50.734 --> 00:02:54.074
Alors là, c'est vraiment la version grosse maille, mais ce qu'il faut comprendre,

00:02:54.234 --> 00:02:57.174
c'est qu'à la base, nous, ce qu'on fait, c'est de l'infra.

00:02:57.414 --> 00:03:03.254
C'est-à-dire qu'on va déployer une infrastructure state-of-the-art sur le compte cloud de nos clients.

00:03:03.374 --> 00:03:05.674
Comme ça, c'est l'infrastructure des customers.

00:03:06.454 --> 00:03:11.594
Nous, on a un contrôle plain de notre côté qui permet justement de lancer tous

00:03:11.594 --> 00:03:12.974
ces déploiements à distance.

00:03:13.954 --> 00:03:18.954
Donc, au travers soit d'une interface, donc pour les devs une console c'est

00:03:18.954 --> 00:03:25.754
très pratique, soit une CLI, soit du Terraform, vous allez pouvoir en fait contrôler

00:03:25.754 --> 00:03:27.534
tout ce qui se passe sur Kovei.

00:03:27.794 --> 00:03:31.354
Donc l'idée c'est de pouvoir déployer des bases de données, des applications,

00:03:31.654 --> 00:03:37.474
en fait tout ce dont un développeur va avoir besoin pour tout simplement développer

00:03:37.474 --> 00:03:41.074
des fonctionnalités sans vraiment se prendre la tête.

00:03:41.274 --> 00:03:43.994
Que ce soit très, très simple. Il y a beaucoup de complexités qui sont masquées.

00:03:44.554 --> 00:03:47.994
Et donc, justement, pour un développeur, donc là, tu as dit que c'était un repo et un Dockerfile.

00:03:48.294 --> 00:03:51.214
Si jamais je veux déclarer l'accès à une base de données, des choses comme ça,

00:03:51.234 --> 00:03:54.214
comment ça va se passer, justement ? Est-ce que j'ai besoin de demander à un

00:03:54.214 --> 00:03:57.014
DevOps qui va cliquer dans l'interface que je dois le faire moi-même ?

00:03:57.014 --> 00:04:01.154
Est-ce que je peux directement l'annoncer dans un paramètre quelconque ?

00:04:01.154 --> 00:04:04.774
Oui. Alors, on fournit quelques primitives de base, quelques services.

00:04:05.014 --> 00:04:08.134
Donc, on a quatre bases de données aujourd'hui, donc MySQL, Postgre,

00:04:08.314 --> 00:04:13.254
DocumentDB, Redis et ça couvre généralement la plupart des besoins,

00:04:13.954 --> 00:04:17.454
et donc l'idée c'est que tu vas créer un environnement donc un environnement

00:04:17.454 --> 00:04:21.734
ça va être production, staging, ce que tu veux et tu vas créer tous tes services

00:04:21.734 --> 00:04:23.394
dedans donc typiquement j'ai

00:04:23.394 --> 00:04:26.174
un backend, j'ai un frontend, on va faire simple et une base de données,

00:04:26.814 --> 00:04:31.574
tu crées ces trois services là donc la base de données comme j'ai dit on la

00:04:31.574 --> 00:04:36.154
fournit en primitive donc soit en mode conteneur soit en mode manager et c'est

00:04:36.154 --> 00:04:40.454
un simple clic sur l'interface et en quelques secondes,

00:04:40.454 --> 00:04:43.774
tu as ton conteneur de base de données.

00:04:44.294 --> 00:04:48.414
Et en fait, on vient automatiquement injecter tout ce qui est environment variable

00:04:48.414 --> 00:04:52.754
au sein de l'environnement, ce qui fait que toutes les applications que tu vas

00:04:52.754 --> 00:04:56.234
utiliser derrière, tu vas pouvoir leur dire « Moi,

00:04:56.614 --> 00:05:01.534
typiquement, mon application a besoin de DB host, DB login, DB password, etc.

00:05:01.754 --> 00:05:06.334
» nous on a créé des built-in environment variables avec du coup ce que tu as

00:05:06.334 --> 00:05:08.254
déployé donc typiquement là la base de données.

00:05:09.202 --> 00:05:13.602
Et tu vas pouvoir faire un alias vers, donc typiquement si une application,

00:05:13.802 --> 00:05:17.602
typiquement un WordPress ou ce genre de choses que tu vas déployer qui vont

00:05:17.602 --> 00:05:21.882
demander expressément à ce qu'il y ait exactement tel nom de variable, etc.

00:05:22.162 --> 00:05:25.662
Tu vas pouvoir la faire pointer en fait vers la built-in variable qu'on a créée,

00:05:25.722 --> 00:05:27.062
donc c'est un simple alias.

00:05:27.662 --> 00:05:31.442
Et si tu veux l'avantage de ça, c'est que les développeurs quand ils font une

00:05:31.442 --> 00:05:35.262
nouvelle feature, ce genre de truc, ils n'ont pas envie de travailler à 50 sur

00:05:35.262 --> 00:05:38.782
le même environnement de staging typiquement parce que ça devient vite le foutoir.

00:05:39.202 --> 00:05:41.662
Ce qu'ils ont envie, c'est de pouvoir dupliquer les environnements.

00:05:41.902 --> 00:05:46.942
Et donc ça, c'est une des grosses forces de Cori, c'est qu'on vient en un seul

00:05:46.942 --> 00:05:50.382
clic te permettre de cloner un environnement complet.

00:05:50.622 --> 00:05:53.542
Et donc, tous les aliases, etc., que tu as fait pointer vers les built-in,

00:05:53.622 --> 00:05:58.082
en fait, nous, on te garde ça de l'autre côté, mais ça reste complètement isolé.

00:05:58.122 --> 00:06:00.662
En fait, on vient refaire automatiquement tout le mapping, etc.

00:06:01.222 --> 00:06:04.982
Même si tu as 50 applications dans ton environnement, ça va se faire tout seul.

00:06:05.482 --> 00:06:08.502
La seule chose que tu auras à reparamétrer, c'est tout ce qui est vraiment unique,

00:06:09.042 --> 00:06:12.702
typiquement si t'as mis un custom domaine ou si t'as mis des secrets t'as pas

00:06:12.702 --> 00:06:16.002
forcément envie de partager les secrets ça c'est le genre de choses qu'il faudra

00:06:16.002 --> 00:06:19.462
que tu remettes mais sinon c'est vraiment très très simple c'est copier-coller.

00:06:20.242 --> 00:06:25.262
Donc là en fait on partirait tu pars de la prod tu la dérives en fait dans un

00:06:25.262 --> 00:06:29.682
environnement de développement tu pars de la prod, tu dérives et ensuite tu

00:06:29.682 --> 00:06:33.042
peux promouvoir justement t'as cette notion de promotion pour repartir sur la

00:06:33.042 --> 00:06:34.062
prod quand j'ai fini mon développement,

00:06:34.662 --> 00:06:37.802
alors ça, ça va être plutôt toi qui va te débrouiller avec ta CI.

00:06:38.062 --> 00:06:41.542
Une fois que tu vas émerger dans main, typiquement, ça va te débrouiller sur

00:06:41.542 --> 00:06:45.102
ta prod. Après, ça, c'est des stratégies qui sont propres à chacun,

00:06:45.422 --> 00:06:47.402
enfin, chacune des boîtes, chacune des équipes, etc.

00:06:48.822 --> 00:06:52.142
Là où nous, en fait, on va augmenter la productivité aussi, si tu veux,

00:06:52.182 --> 00:06:56.122
c'est que le dev, il n'a pas besoin de se connecter sur Covery pour faire des trucs.

00:06:56.422 --> 00:06:59.442
C'est-à-dire qu'il part de sa branche main, il veut faire une nouvelle feature,

00:06:59.682 --> 00:07:02.102
il reste dans son git, en fait, donc dans ce qu'il connaît.

00:07:06.582 --> 00:07:10.662
Il teste en local le salaire d'aller il pousse ça, il fait une nouvelle PR dans

00:07:10.662 --> 00:07:14.702
la PR typiquement sur GitHub ça va lui dire tiens si tu veux créer un environnement

00:07:14.702 --> 00:07:17.862
éphémère, t'as juste à répondre ça en commentaire et on va te le faire pour

00:07:17.862 --> 00:07:19.842
toi et donc automatiquement ça va cloner,

00:07:19.942 --> 00:07:23.042
ça va lui donner l'URL sur laquelle il va pouvoir accéder au back, au front,

00:07:23.162 --> 00:07:26.122
jusqu'à ce dont il avait besoin dans cet environnement,

00:07:26.782 --> 00:07:32.442
et donc il a accès automatiquement de manière vraiment très simple et quand

00:07:32.442 --> 00:07:35.862
il va détruire sa branche parce qu'elle sera mergée ou elle sera tout simplement

00:07:35.862 --> 00:07:40.422
détruite ça va lui supprimer automatiquement son environnement éphémère D'accord,

00:07:40.502 --> 00:07:43.802
donc vous gérez les environnements éphémères directement et justement vous êtes

00:07:43.802 --> 00:07:47.502
compatible avec GitHub tu le disais avec d'autres environnements ou pas ?

00:07:47.502 --> 00:07:49.342
On a GitLab et Bitbucket aussi.

00:07:50.972 --> 00:07:54.412
Ok, super. Bon, nous, on est sur Azure DevOps, mais bon, je comprends qu'on

00:07:54.412 --> 00:07:56.832
ne va pas supporter Azure DevOps.

00:07:57.172 --> 00:08:01.652
Ce n'est pas qu'on ne veut pas, c'est qu'on a quatre ans d'existence aujourd'hui

00:08:01.652 --> 00:08:03.472
et qu'il faut choisir des combats.

00:08:03.732 --> 00:08:06.692
Et pour l'instant, c'est cela, mais on se ferme la porte à rien du tout.

00:08:07.172 --> 00:08:10.712
Quatre ans d'existence, historiquement, c'était ce que vous aviez vraiment voulu

00:08:10.712 --> 00:08:14.532
faire ? Comment ça s'est passé, un peu, la genèse de Covery ?

00:08:14.532 --> 00:08:21.432
Alors pas du tout en fait donc moi j'étais à Criteo encore et avec donc mes associés,

00:08:22.092 --> 00:08:26.572
on avait un play au Techstar donc pour c'est un peu comme le YC le Techstar

00:08:26.572 --> 00:08:31.152
pour être pris c'est vraiment compliqué et on a été pris en gros il y avait

00:08:31.152 --> 00:08:33.872
1000 boîtes 10 boîtes sélectionnées on était dans l'hélice,

00:08:34.392 --> 00:08:37.252
donc du coup ça faisait un moment de façon qu'on avait

00:08:37.252 --> 00:08:40.392
des side projects qu'on essayait des trucs et tout lancé dans

00:08:40.392 --> 00:08:43.432
un truc qui avait rien à voir c'était de l'analyse d'images

00:08:43.432 --> 00:08:46.212
à des fins de marketing donc beaucoup d'IA beaucoup de

00:08:46.212 --> 00:08:49.072
trucs comme ça et avec le Techstar ce qui est bien c'est que t'apprends vite

00:08:49.072 --> 00:08:51.992
est-ce que ton idée ton produit va

00:08:51.992 --> 00:08:55.532
réussir ou pas et on a rapidement vu que ça

00:08:55.532 --> 00:08:59.992
n'irait pas donc on s'est reconcentré après sur ce qu'on connaissait qu'est-ce

00:08:59.992 --> 00:09:04.052
qu'on fait depuis des années on passe de boîte en boîte c'est quoi notre but

00:09:04.052 --> 00:09:07.792
en tant que DevOps etc c'est faire plaisir aux devs enfin en tout cas faire

00:09:07.792 --> 00:09:13.232
plaisir leur donner matière à pouvoir utiliser l'infra travailler rapidement être efficace etc etc.

00:09:13.512 --> 00:09:17.932
Et comme dans toutes les boîtes, on galère, c'est compliqué,

00:09:18.192 --> 00:09:21.872
ça prend du temps et tu as l'impression de refaire beaucoup de choses à chaque fois.

00:09:22.392 --> 00:09:25.152
Donc on s'est dit, en fait, le pain point pour nous, il est là,

00:09:25.232 --> 00:09:28.252
on va changer du coup notre fusil d'épaule et on va se lancer là-dedans.

00:09:28.412 --> 00:09:31.912
Et c'est comme ça que l'aventure, elle a commencé et on s'est dit,

00:09:31.972 --> 00:09:35.732
en fait, il faut qu'on propose aux entreprises quelque chose qui leur permette de démarrer.

00:09:36.504 --> 00:09:40.844
Et d'avoir quelque chose vraiment de souple qui plaît aux devs.

00:09:40.864 --> 00:09:45.184
Parce qu'en tant que DevOps ou SRE, je pense que tu connais bien le problème.

00:09:45.384 --> 00:09:47.984
Ce sont des gens qui sont très bons côté back, mais côté front,

00:09:48.064 --> 00:09:51.224
malheureusement, ce n'est pas forcément les meilleurs pour faire des super UI et UX.

00:09:51.744 --> 00:09:56.004
Donc, il faut un mix de tout. Et donc là, c'est vraiment ça aussi qu'on apporte.

00:09:56.004 --> 00:10:00.104
C'est une facilité et une souplesse pour les DevOps pour pouvoir proposer à

00:10:00.104 --> 00:10:04.324
leurs devs quelque chose de joli, utilisable et simple.

00:10:04.944 --> 00:10:09.264
Et donc là aujourd'hui vos clients ça va être quoi comme type de client qui

00:10:09.264 --> 00:10:12.504
vous rejoignent, vous en avez pas forcément le nombre exact mais c'est quoi

00:10:12.504 --> 00:10:17.904
à peu près la proportion ouais bah aujourd'hui on a une centaine de clients un peu plus.

00:10:19.364 --> 00:10:24.204
Et on a des boîtes de 3 personnes qui démarrent avec Kovri et qui évoluent comme

00:10:24.204 --> 00:10:32.244
ça et on a des boîtes plus de 200 dev donc c'est assez hétérogène mais ils viennent

00:10:32.244 --> 00:10:33.564
pas forcément non plus pour la même chose.

00:10:33.764 --> 00:10:37.464
Tu vas avoir des petites boîtes qui vont venir parce que quand tu prends Covery,

00:10:37.604 --> 00:10:41.024
du fait qu'on va te déployer une infra, qu'on va te la gérer,

00:10:41.124 --> 00:10:44.464
etc., c'est super pratique au début. Tu n'as pas à te prendre la tête.

00:10:45.004 --> 00:10:48.364
Quand on déploie une infra, tu es sort de direct.

00:10:48.704 --> 00:10:53.584
Donc c'est pratique aussi si tu veux avoir une besoin de certification rapidement.

00:10:54.704 --> 00:10:57.544
Et tu vas avoir des plus grosses boîtes qui viennent parce qu'en fait,

00:10:57.564 --> 00:10:59.324
ils galèrent sur les environnements éphémères.

00:10:59.644 --> 00:11:05.044
Et ça, c'est un pain point pour beaucoup de boîtes parce que les devs en ont besoin.

00:11:05.464 --> 00:11:09.404
C'est compliqué à mettre en place. Ça a un coût aussi parce que du coup,

00:11:09.424 --> 00:11:13.984
on a fait beaucoup d'optimisation de coût derrière et on propose pas mal de choses.

00:11:14.124 --> 00:11:18.004
Tout à l'heure, je te disais tu vois, un dev, il déploie une nouvelle PR,

00:11:18.284 --> 00:11:21.144
il peut avoir son environnement éphémère.

00:11:21.264 --> 00:11:25.584
Ok, c'est cool, mais derrière si ça tourne 24-24, ça va commencer à coûter cher.

00:11:25.744 --> 00:11:28.424
Donc on a des optimisations comme ça pour dire au bout de deux heures,

00:11:28.464 --> 00:11:32.344
si tu n'as pas utilisé, ça se coupe tout seul. et donc il peut le rallumer quand il veut enfin.

00:11:33.476 --> 00:11:36.656
Il y a plein de trucs autour de ça et donc ça c'est ce qui va plutôt intéresser

00:11:36.656 --> 00:11:41.436
les grosses boîtes après on a des moyennes grosses boîtes qui rentrent par cover

00:11:41.436 --> 00:11:43.956
là dessus et puis qui se disent ah putain mais en fait ça marche bien,

00:11:44.036 --> 00:11:48.056
c'est cool bah en fait on va commencer à basculer de la prod aussi dessus et

00:11:48.056 --> 00:11:51.536
donc comme ça ça leur permet d'avoir le faux complet et puis bah du coup cloner

00:11:51.536 --> 00:11:55.676
des environnements c'est relativement simple du coup dès lors que t'as tout

00:11:55.676 --> 00:11:59.596
la question c'est est-ce que je peux mettre un cover et continuer d'avoir le

00:11:59.596 --> 00:12:01.756
reste de ma prod qui fait autre chose est-ce que c'est un.

00:12:02.416 --> 00:12:06.376
Comment si jamais demain j'ai déjà une prod je peux intégrer Covery à certains

00:12:06.376 --> 00:12:09.896
de mes développements c'est quoi je sais pas je suis sur Azure par exemple ou

00:12:09.896 --> 00:12:17.476
je suis chez GCP comment je vais intégrer Covery je dois faire un truc complètement à côté ou pas ?

00:12:17.936 --> 00:12:21.236
Alors ça dépend du niveau de maturité des boîtes typiquement

00:12:21.236 --> 00:12:24.016
si t'es une boîte qui fait déjà du conteneur t'as ta

00:12:24.016 --> 00:12:27.156
CI tu sais déployer du conteneur aujourd'hui tu

00:12:27.156 --> 00:12:29.776
build tes images etc on va pas rebuilder à chaque fois de nous

00:12:29.776 --> 00:12:32.676
aussi les images tu peux aller directement chercher le conteneur sur

00:12:32.676 --> 00:12:35.476
un registre et donc si déjà tu fais

00:12:35.476 --> 00:12:38.176
du conteneur c'est tu as moins de

00:12:38.176 --> 00:12:43.576
boulot à faire on gère aussi elle donc si tu as si tu déploies du mb avec covry

00:12:43.576 --> 00:12:46.596
tu peux aussi déployer duel tu peux déployer en fait quasiment tout ce que tu

00:12:46.596 --> 00:12:50.036
veux on a un truc qui s'appelle life cycle job et dedans tu n'as absolument

00:12:50.036 --> 00:12:53.216
ce que tu veux tu peux mettre du m tu peux du terraform tu peux être du chasse

00:12:53.216 --> 00:12:57.096
tri du beau peu importe donc tu peux déployer vraiment tout tout ce que tu veux.

00:12:57.716 --> 00:13:01.856
Et donc, en fait, il y a des transitions qui se font comme ça où typiquement,

00:13:01.916 --> 00:13:06.276
tu vas avoir une prod qui est sur un compte AWS dans un VPC en particulier.

00:13:07.116 --> 00:13:10.456
Le client va décider de déployer Covery sur un autre VPC.

00:13:10.596 --> 00:13:14.576
Il va faire du VPC piring entre les deux et il va commencer à faire communiquer

00:13:14.576 --> 00:13:18.836
ses infras, ce genre de choses et petit à petit, en fait, il passe du coup ses

00:13:18.836 --> 00:13:22.856
environnements de dev ou ses jeux de test sur Covery.

00:13:23.396 --> 00:13:26.156
Alors, des fois, c'est très, très simple parce que, comme je te disais,

00:13:26.156 --> 00:13:29.576
ils ont déjà une CI avec des containers etc et donc on vient juste récupérer

00:13:29.576 --> 00:13:33.296
les containers et puis des fois ils sont un peu moins matures sur ce côté là

00:13:33.296 --> 00:13:37.936
et donc ils fondent pas aussi vers plus de cloud native et ce genre de choses,

00:13:38.496 --> 00:13:43.096
ça dépend vraiment des clients de leur infra, de leur maturité Et quel est l'intérêt

00:13:43.096 --> 00:13:46.876
justement d'utiliser Covery pour du Helm si jamais j'ai déjà toute une stack

00:13:46.876 --> 00:13:50.136
avec du Helm, du Kubernetes donc si jamais c'est du Helm, il y a du Kubernetes,

00:13:50.776 --> 00:13:55.816
mais quel est l'intérêt que je vais avoir là d'utiliser ça ça va être que pour des gens qui ont,

00:13:56.336 --> 00:14:00.836
qui sont on-prem et vous installez directement un Kubernetes ou est-ce que c'est

00:14:00.836 --> 00:14:04.676
quelque chose à mettre chez un cloud provider enfin quel va être l'intérêt et

00:14:04.676 --> 00:14:06.816
sur quel environnement je vais pouvoir le mettre ouais,

00:14:07.536 --> 00:14:11.596
aujourd'hui on ne fait pas de on-prem c'est que du cloud.

00:14:12.897 --> 00:14:17.617
C'est en train de changer, enfin on est en train de rejouter ce type de fonctionnement aussi.

00:14:18.477 --> 00:14:22.117
Mais ce qui est important de comprendre, c'est que Helm, la destination,

00:14:22.357 --> 00:14:26.317
qui c'est qui va vraiment utiliser ça ? Généralement c'est les DevOps et les SRE.

00:14:27.137 --> 00:14:30.457
La plupart du temps, pour ne pas dire 90% du temps, à chaque fois que je parle

00:14:30.457 --> 00:14:35.097
à des devs qui doivent eux-mêmes déployer du Helm, en fait c'est un enfer parce

00:14:35.097 --> 00:14:37.837
que c'est un bout de la stack que eux n'ont pas envie de gérer.

00:14:37.937 --> 00:14:42.477
En fait c'est une dépendance qui leur a été plus ou moins imposés parce qu'en

00:14:42.477 --> 00:14:45.957
fait on leur a dit que s'ils voulaient tel ou tel truc il fallait qu'ils passent

00:14:45.957 --> 00:14:48.257
pas et puis ils devaient gérer ça et en fait

00:14:48.697 --> 00:14:50.937
juste ça les ennuie alors quand

00:14:50.937 --> 00:14:54.717
tu passes par Kovri t'as une interface qui te permet de dire bah voilà.

00:14:55.577 --> 00:14:59.897
Moi mes DevOps ils m'ont préparé un environnement je sais que si ça je le clone

00:14:59.897 --> 00:15:03.377
je le déploie en fait je vais avoir tout qui va marcher et je vais pouvoir builder

00:15:03.377 --> 00:15:07.757
par dessus et en fait les devs ils ont la main parce qu'ils contrôlent exactement

00:15:07.757 --> 00:15:10.217
ils peuvent faire tout ce qu'ils veulent dans son environnement.

00:15:10.297 --> 00:15:13.197
Ils peuvent même, je t'ai dit, faire du Terraform, donc déployer des services

00:15:13.197 --> 00:15:16.877
tiers sur des cloud providers qu'on ne gère même pas du tout.

00:15:17.677 --> 00:15:21.777
Et faire en sorte que ça soit vraiment très simple pour le end-user.

00:15:21.997 --> 00:15:28.977
En fait, la force, elle est là. On ne cherche pas à changer les méthodes classiques que le DevOps a.

00:15:29.657 --> 00:15:36.057
C'est vraiment, on cherche à amener une expérience que le développeur ne peut pas avoir aujourd'hui.

00:15:36.617 --> 00:15:41.057
Donc là, en fait, si jamais je veux une base de données donc comme ça le développeur

00:15:41.057 --> 00:15:44.397
peut directement demander une base de données t'as parlé tout à l'heure de soit

00:15:44.397 --> 00:15:47.777
des conteneurs de bases de données soit des bases de données managées aujourd'hui

00:15:47.777 --> 00:15:51.257
vous supportez quoi comme type d'environnement donc si jamais c'est pas le on-prem ça va être

00:15:51.657 --> 00:15:55.717
quel type c'est GCP AWS et Azure ouais,

00:15:56.457 --> 00:16:00.397
alors de base nous on supporte quand je te disais managé aujourd'hui on ne fait

00:16:00.397 --> 00:16:04.677
que AWS en managé et il y a que les 4 bases que j'ai citées tout à l'heure donc

00:16:04.677 --> 00:16:07.157
MySQL Postgre, Redis et Mongo ça s'arrête là

00:16:07.557 --> 00:16:11.677
on ne compte pas forcément en mettre plus parce qu'on a les lifecycle jobs déjà,

00:16:12.197 --> 00:16:15.237
qui permettent du coup de déployer autre chose si tu veux faire du Dynamo si

00:16:15.237 --> 00:16:16.637
tu veux faire des bases de données,

00:16:17.257 --> 00:16:22.217
spécifiques à Google ou tu veux faire du Mongo A-Class ou n'importe quoi en

00:16:22.217 --> 00:16:23.337
fait tu peux le faire déjà.

00:16:24.640 --> 00:16:29.080
Et début d'année prochaine, on va arriver, donc remarquez qu'on a déjà un petit

00:16:29.080 --> 00:16:31.220
peu utilisé, donc remarquez que c'est le signaux de Cowboy,

00:16:31.900 --> 00:16:36.380
mais on arrive avec une espèce de plateforme open source qui permettra d'avoir

00:16:36.380 --> 00:16:38.980
un espèce de catalogue, si tu veux,

00:16:39.060 --> 00:16:44.260
sur lequel les DevOps vont pouvoir builder par-dessus et proposer sous forme

00:16:44.260 --> 00:16:48.860
de catalogue aux développeurs de pouvoir déployer certains services.

00:16:49.040 --> 00:16:52.660
Donc ça peut être du complètement in-house ou ça peut être des trucs externes,

00:16:53.180 --> 00:16:57.300
comme je viens de citer Mongo Atlas ce genre de trucs c'est bien que tu en parles

00:16:57.300 --> 00:16:59.980
de ce genre de choses parce que j'étais à l'OVH Summit il y a peu,

00:17:00.520 --> 00:17:04.360
et je parlais avec Levercloud oui je parle avec Levercloud et justement eux

00:17:04.360 --> 00:17:06.960
ils ont un peu cette problématique là en fait où tout le monde aujourd'hui on

00:17:06.960 --> 00:17:09.840
voit qu'il y a un mouvement vers une espèce de pass at edge,

00:17:10.400 --> 00:17:13.920
qui tend à apparaître donc moi j'avais un projet comme ça depuis très longtemps

00:17:13.920 --> 00:17:14.780
qui s'appelait CapLiance,

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