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 contient votre trou face à des...
Ça, oui, naturellement ensemble, ça donne des résultats contrêts.
DevOps.
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 premier numéro de l'année et aujourd'hui, je suis ultra content d'être chez Skelowe
pour parler d'IAM autour de la table.
Donc, on a des personnes de Skelowe qui vont pouvoir se présenter
et également de Mac qui sera avec nous.
Vous connaissez déjà dans les anciens podcasts.
Je vous laisse vous présenter.
Bonjour à tous, je m'appelle Cyril Pétel.
Je suis Product Manager chez Skelowe.
Et depuis un an, depuis mon arrivée chez Skelowe,
j'ai travaillé sur le produit d'Identity and Access Management, IAM.
Avant ça, j'ai fait pas mal de conseils
et participer à différents projets cloud chez d'autres acteurs.
J'avais un profil assez business
et c'était l'année dernière en tant que Product Manager
pour creuser ce beau produit.
Bonjour à tous, moi, je suis Julien Brochet.
Je suis à Skelowe depuis 3 ans.
Actuellement, je suis décliné de mon parti sur le projet IAM
mais également sur d'autres projets.
Voilà, très stuccentement.
Bonjour à tous, moi, c'est Thomas,
qui est d'Amir sur Twitter et sur mon blog.
Pour le coup, je travaille chez OASED,
qui est une entreprise d'experts et de web administrateurs à ce service.
On vous propose des solutions d'accompagnement
de nos clients, notamment sur des solutions comme Skelowe.
Et tu as un blog comme tu l'as dit ?
C'est ça. J'ai un blog qui est d'Amir.fr
dans lequel vous retrouvez un article
sur lequel je décris ma découverte de l'IAM chez Skelowe
avec des exemples et le code source, si vous voulez vous-même tester.
Et on en dit que ça, c'est plutôt cool.
Pour ma part, Guy Mlethron,
j'ai changé, j'avais un petit dessin dans l'épisode d'avant.
Maintenant, je suis DevSecOps Excellence Leader chez Cégid.
Et oui, on se marre à côté.
Mais le titre est « Ultra-classe », je trouve.
Et peut-être que j'aurai l'occasion d'en reparler
dans un futur podcast de ce que ça veut dire
DevSecOps Excellence Leader chez Cégid.
Alors, pour commencer, on a déjà un peu parlé
dans l'épisode en podcast, notamment dédié au cloud souverain,
de ce que vous voulez dire à IAM.
Mais est-ce qu'on peut vous demander à vous, de Skelowe,
de le redéfinir ?
Peut-être aussi de présenter le produit et Skelowe ?
On va peut-être commencer par Skelowe.
Je ne sais pas si tous les auditeurs nous connaissent bien.
Skelowe, on est un cloud provider européen.
Historiquement français, on est basé à Paris.
Et on offre à nos clients un écosystème cloud assez large.
On va du bernmétal jusqu'au Savare-les.
On a un catalogue d'une vingtaine de produits aujourd'hui,
et bientôt plus.
On essaye de servir toute une variété de clients,
mais notre cible principal, c'est les startups européennes.
Et aujourd'hui, la majorité des produits et du targeting qu'on fait,
sont adressés à ces startups européennes.
On avait beaucoup de produits,
mais un moment qui était souvent remonté par nos clients,
c'était le manque d'IAM.
Alors qu'est-ce que c'est un IAM ?
Je vais donner ma définition, mais Julien,
tu en aurais peut-être une un petit peu différente.
Chez nous, l'IAM, c'est surtout la partie access management
qu'on a travaillé à travers ce produit.
C'est pouvoir de façon assez simple,
et on a décidé qui a droit de faire quoi sur mon infrastructure.
C'est-à-dire, une infrastructure, c'est un ensemble de produits.
Donc pour chacun des produits que vous avez dans votre écosystème,
quel oeil, quel utilisateur et quels accès programmatique
peuvent faire quoi ?
Voilà, tout simplement.
Je ne sais pas si tu veux compléter, Julien.
Non, non, ça, c'est fidèle.
Je pense que effectivement, on peut mettre d'autres choses dans la IAM,
mais globalement, la grosse bric qui intéresse quand même pas le monde,
c'est cette partie-là, c'est la partie
gestion granulaires des droits et des permissions sur les ressources.
Non, ça, c'est fidèle.
Et je préfère, je le précise tout de suite,
ce n'est pas une opération sponsorisée.
Il y a ce qu'elle oeille nous invite dans ses locaux,
ce qui est déjà très bien.
Le but étant ici, justement, suite au podcast qu'on a déjà fait avant,
de vraiment présenter les évolutions qui sont faites.
Et je trouve que IAM est un point extrêmement important
et qui en effet a été souvent remonté,
même nous, dans l'usage dessus.
C'est pour ça qu'on voulait vous demander d'en parler,
justement, pour que tout le monde découvre cet outil-là,
et qu'on comprenne un peu plus comment il a été fait
et à quel point, peut-être, c'était compliqué.
Dans ce cas-là, peut-être, pour qu'on comprenne
encore mieux comment ça se fait la IAM,
je laisse Thomas, tu as...
Alors toi, dans ton blog, t'as été plutôt,
dans un point de vue utilisateur de ce produit,
qui est sorti, d'ailleurs, il est sorti...
Même il est sorti de Béta, ou pas ?
Il était en Béta depuis juillet 2022.
On a eu une phase de Béta de 6 mois,
et depuis le mois dernier, depuis début décembre,
il est disponible pour tous nos clients.
Il n'a pas été activé par défaut,
donc on va voir des clients qui l'ont activé,
d'autres pas encore.
Mais il est disponible.
Mais il est disponible pour tous.
D'accord.
Et donc voilà, c'est pour ça que, Thomas,
tu vas peut-être le présenter toi,
d'un point de vue plus utilisateur,
ce que ça veut dire, toi, dans ton contexte,
de ce que tu as vu ?

Du coup, effectivement, moi,
j'ai un peu fait mon test en bois de noir,
en tant que simple utilisateur,
comme si je n'ai rien de créé mon compte,
en tant qu'entreprise chez Scalway.
Et du coup, c'est assez intéressant,
parce que c'est quand même une fonctionnalité
comme Guilhem l'a rappelé.
Ça fait quand même longtemps
qu'on l'attend chez des CloudForms sur Français.
C'est un peu le principal reproche
qu'on faisait en général,
qu'on a déjà pas mal parlé
dans le podcast présent sur la souveraineté.
Et ce qui est intéressant,
c'est que c'est comme dit une brique essentielle,
assez simple dans la logique.
Mais il faut voir que, pour rappel,
les hares peuvent varier un peu de scope
en fonction des CloudProvider.
Et quand on parle du coup,
Diane, c'est access identif...
Identity and access management.
Voilà, j'avais plus le tiers c'est pour l'endembre.
Et du coup, cette brique-là,
du coup, effectivement, le but,
c'est de gérer les accès et les permissions.
Mais souvent, en fait,
il y a d'autres briques qui vont être collés
ou intégrés dessus.
Donc, on pourra un peu en reparler après,
mais c'est juste pour vous dire
que ça peut un peu varier le scope.
Et du coup, pour tester, c'est très simple.
J'ai été sur la documentation,
j'ai regardé un peu comment se composer l'offre,
comment ça fonctionnait, comment l'utiliser.
Et j'ai commencé à mettre ça en place.
Donc, j'ai testé sur l'interface du coup Web,
la console Web,
comme on pourrait le faire classiquement.
Mais j'ai surtout testé la partie,
du coup, Cli et la partie Terraform,
parce qu'aujourd'hui, en entreprise,
c'est ce que je demande.
Moi, je ne veux pas faire d'actions sur le Web.
C'est marrant deux minutes pour une démo,
mais pas plus.
Donc, du coup,
peut-être des avis contradictoires,
mais c'est ma vision des choses.
Et en tout cas,
assez rapidement,
j'ai pu prendre en main,
du coup, le système.
J'ai commencé à créer,
du coup, des utilisateurs, des applications,
l'or assigné des droits.
Ce qui est assez intéressant,
c'est que déjà,
Day 1, de ce que j'ai vu,
tout était intégré, du coup, aux différents outils.
Donc, on n'a pas dû attendre
une disponibilité dans un endième outil.
Donc, ça, c'était plutôt...
Quand tu parles là de disponibilité dans les outils,
ça veut dire quoi, concrètement ?
C'est-à-dire que c'était accessible de la Cli,
c'était accessible sur le provider Terraform.
C'était vraiment utilisable
sur l'ensemble, entre guillemets,
l'écosystème de tooling.
Donc, ça, c'est quand même quelque chose aujourd'hui
qui, pour moi, est important.
Pour moi, à partir du moment,
je diverge un peu.
Ma partie, on parle de global invidibilité,
d'une fonction
sur un cloud provider ou d'un service.
Ça doit intégrer, en fait,
la disponibilité dans la Cli, dans la Pays
et, du coup, dans le provider Terraform.
Sans ça, je considère pas que c'est en GER.
De toute façon, sur cette partie-là,
on était totalement conscients que...
Ce que nous demandait,
vraiment, les utilisateurs, c'était de pouvoir
utiliser part Terraform,
parce qu'on était tout à fait conscients
que c'est comme ça qu'est consommé
une grande partie de nos APIs.
Du coup, dans le développement, assez tôt,
en fait, on a vraiment pensé les APIs
déjà pour une intégration Terraform.
On voulait que l'intégration Terraform
soit disponible plutôt possible.
C'est-à-dire que...
Enfin, l'ouverture de la console
devait vraiment être liée aussi
avec une ouverture Terraform.
C'est pas envisageable d'ouvrir
uniquement la console, justement,
pour ces raisons-là.
Pour le coup, c'est une très bonne chose
que j'apprécie.
Et je pense que beaucoup l'ont appréciée.
Et pour le coup,
d'autre part, c'est assez simple
dans le fonctionnement.
Donc, vous avez votre organisation
SkylWest, ça, ça ne change pas,
qu'il était déjà en place.
Vous avez votre découpage par projet,
qui existe depuis quelques années aussi.
Et vous allez pouvoir, du coup,
créer soit des applications,
ça va être des utilisateurs non humains,
ou des utilisateurs que vous allez inviter
qui là sont identifiés par une adresse mail,
qui sont en réalité, du coup,
des utilisateurs humains, comme je disais.
Et du coup, vous allez, à eux,
pouvoir les assigner dans des groupes.
Et vous allez pouvoir assigner, du coup,
des règles, des sets de règles,
ce qu'on appelle des policiers en général,
assez ressources, donc que ce soit les groupes,
les utilisateurs ou les applications,
pour pouvoir, du coup, leur donner des droits.
Pour la construction des droits,
ce qui est un peu le plus,
on va dire, qui peut très vite être complexe.
On est sur un système qui, pour l'instant,
est assez basique,
mais qui offre pas mal de flexibilité.
C'est-à-dire que vous allez avoir, globalement,
dans la configuration,
deux étapes, une première,
vous allez choisir, du coup, le pro de l'E,
ou les projets dans lesquels vous voulez mettre
des droits.
Et ensuite, vous allez donner une liste d'ensemble d'actions
que vous allez vouloir autoriser.
Il n'y a que de l'autorisation,
il n'y a pas du refus,
c'est important de le noter.
Et du coup, si je prends un exemple,
demain, vous avez un utilisateur, vous voulez l'autoriser,
j'ai des développeurs, je vais les autoriser,
au moins avoir l'état des instances,
les buckets, possiblement,
mais pas supprimer les buckets,
je vais avoir des policiers qui vont être
Allo, Read, Bucket, Allo, Read, Instance,
et du coup, on va pouvoir varier
comme ça un peu les droits.
Ça va être assez basique
dans le sens où, pour l'instant,
la plupart du temps, ça se limite
à du read orie ou du full access.
Il y a pour certains services, notamment S3,
quelques petites subtilités en plus,
on peut, par exemple, autoriser l'écriture,
mais pas la suppression de buckets,
ça peut être intéressant dans certains cas.
Mais pour l'instant, on reste sur une notion assez basique,
mais assez granulière, dans le sens où on va pouvoir au moins choisir
par service et par projet.
Donc on peut déjà commencer à faire
une limitation qui est infiniment meilleure
que précédemment, donc c'est quand même
quelque chose qui est assez agréable
et qui fonctionne plutôt bien
d'un point de vue utilisateur.
J'ai fait des tests, notamment en essayant
de voir jusqu'où je pouvais aller
quand j'avais mis des droits,
est-ce que je pouvais aller un peu plus loin
que ce que je pensais.
Et je n'ai pas rencontré trop de mauvaises surprises.
Par exemple, si vous mettez un read-only
d'un utilisateur sur du capsule,
vous n'allez pas pouvoir récupérer du coup
le cube CTL dans lequel il y a les droits d'admine.
Voilà, des petites choses comme ça,
ça a l'air d'être plutôt rassurant,
que ce soit pensé.
Donc là-dessus, c'est plutôt cool.
J'ai eu quelques petites erreurs,
des erreurs sur la...
En étrangement, je n'ai pas eu d'erreurs en terraformes
ni en clis. Par contre, sur l'interface graphique,
en venant de créer des policiers, j'ai eu pas mal
de fois des petites erreurs
avec la petite pop-up rouge,
mais qui ne me donne pas beaucoup de détails.
Le seul truc niveau 8, si un peu frustrant,
c'est que sur la console, des fois, on voit erreurs.
Oui, mais...
Il faut se rendre compte que la console
n'a jamais été pensée...
Pour avoir un grand paradigme
qui change justement avec Ayam,
c'est qu'avant, un utilisateur sur la console avait accès à tout.
En fait, on avait trois rôles préd définies,
soit l'honneur de nos organisations,
soit été administrateur,
soit était billing avec des droits très spécifiques.
Du coup, la console n'a jamais été vraiment pensée.
Pour un affichage,
on se dit que j'ai juste
telle permission,
et du coup, ça demande énormément
de refactoring, de revoir
toute la structure pour se dire.
Suivant les permissions que j'ai,
je peux potentiellement
faire une certaine action sur la console,
mais il faut que je puisse
naviguer sur la console avec uniquement
un certain nombre de permissions très spécifiques.
Et donc, ça demande énormément de boulot,
et c'est quelque chose sur lequel on a conscience qu'on me bosse.
Mais effectivement,
le problème à l'heure actuelle,
c'est que tu en entends
des petits messages d'erreurs qui t'affichent.
L'intégration graphique,
c'est un énorme challenge quand on fait l'access management.
Et là, je lui ai dit à moi,
on représente plutôt la partie
back-end, on a surtout travaillé
sur la conception du produit
sans penser uniquement à la partie fronte.
Mais côté front, il y a eu un travail énorme
pendant l'année, au moins
tant que nous, pour construire
une console qui fonctionne, même s'il y a quelques erreurs,
comme je l'ai dit,
avec plein de scénarios de
permissions différentes.
Et là, tu parles avec quel point de
vue, c'est-à-dire que tu connais quel autre IAM
quand tu compares par rapport à ça,
et quelles seraient les points que tu vois...
Si jamais, moi, par exemple, je suis habitué
à IAM, que tu es AWS,
ou Azure, n'importe...
C'est vrai que moi, je suis habitué plus à IAM que tu es AWS,
qui est un peu l'inverse, qui est ultra complet,
mais qui pour le coup est beaucoup plus difficile d'accès
pour beaucoup d'entreprises
et de tech. Donc, oui, c'est un peu
le cas inverse, mais si je compare
un peu à l'écosystème FR
de ce que j'ai vu chez les autres clubs de
fournisseurs, c'est quand même aujourd'hui, je pense, celui
qui est le plus avancé, et qui
fonctionne le mieux de moi. Si demain,
je dois... J'ai des problématiques, on va dire,
d'aller sur un club de fournisseurs français,
et je veux gérer les drones à minimum,
bien clairement, c'est la meilleure offre
pour moi qui est actuellement.
Et...
C'est pas plaisirant, t'en as.
Oui, c'est le travail
qui mérite.
Mais là,
si jamais il y a d'autres fonctionnalités, peut-être que
Thomas n'a pas essayé, est-ce que vous en avez
d'autres en tête qui...
Moi, par exemple, il y a une grosse logique,
j'en avais parlé déjà dans le présent podcast
sur l'audit, ça veut dire avoir
accès à toutes les traces de qui a fait quoi.
Est-ce que vous avez ce genre de choses ? On n'a pas encore
euh...
cette minimum d'information, mais c'est
encore assez léger, et c'est une des priorités
de l'année 2023, justement, c'est dans notre roadmap
et on commence à travailler là-dessus.
On sait que nos clients, notamment dans
certaines industries, vont avoir des exigences
importantes sur qui a accédé à quoi,
parce qu'il va y avoir des audits,
même à titre personnel, ils veulent savoir
ce qui se passe, et on travaille dessus, donc
dès les prochains mois, il va y avoir
des nouveautés là-dessus.
En fait, on a les informations brutes, la question,
la problématique, c'est comment la
rend visible à l'utilisateur de manière la plus
pertinente possible, pour que
l'utilisateur puisse vraiment avoir l'information qu'il a besoin
sans vraiment lui donner
une liste de log brutes
et en disant, bah débrouille-toi,
l'idée c'est de savoir comment lui fournir
et qu'il va le rajouter, pour qu'il puisse vraiment
extraire l'information qu'il a besoin dedans.
Et euh... Donc là, vous en avez un peu parlé,
c'est combien de temps le projet,
enfin, c'est-à-dire, comment ça se passe ?
Est-ce que le OAS a combien de temps, c'est une
entreprise qui s'est lancée ?
Ça dépend sur l'online ou ça...
Ça va dépendre de où tu pars,
je ne pourrais pas te donner exactement
tous les détails, il y avait des épôts, des articles qu'on était
faits sur l'histoire d'Esquelway,
sur la partie Cloud,
enfin, je vais juste parler, je ne vais pas
m'engager sur d'autres trucs, juste sur la partie
IAM en tout cas, le projet
a commencé, je veux en dire, il y a 18 mois
à peu près, un an, un an et demi,
sur les premières réflexions.
Il y a eu beaucoup
de techniques, en fait, quand on voit
un peu les résultats, on se dit, bon, bah voilà,
il y a quatre pages, c'est pas forcément super
compliqué. En fait, il y a eu beaucoup
de techniques, on peut en parler des heures,
je pense, de tout ce qu'on a dû
cliner.
C'est quoi comme genre de choses ?
En gros, bon, on peut rentrer dans les déserts.
C'est bien.
Globalement, comme on marche sur Esquelway,
on va dire une autre partie, on a la partie
Authentication et la partie Authorization.
La partie
autorisation est faite par la PQTW,
c'est-à-dire que les requêtes arrivent, elles sont authentifiées.
Et après, le micro-service
derrière, on sort, genre, Kubernetes, instance,
capsule, on le reçoit.
On précise, vous êtes aussi l'équipe qui gère
les PQTW. Tout à fait. Exactement.
C'est pour ça que les deux sont liés. La muptique Asquete.
En gros, globalement, on gère un peu toutes les problématiques
d'authentification et d'autorisation,
en fait, l'authentication
par la PQTW et après, la partie Authorization
qui maintenant est faite par ailleurs, qui avant
n'était justement pas faite par ailleurs.
Et en gros,
chaque micro-service,
lui reçoit leur requête qui a été authentifiée,
et c'est le micro-service qui va s'occuper
de demander un service d'authentification
de dire, j'ai tel requête qui est rentrée,
est-ce que ma requête a le droit de faire telle permission.
Donc, il fait cette requête
de la permission,
un SS micro-service, qui va lui répondre
oui ou non, est-ce que
l'utilisateur a la permission.
En gros, l'idée, c'est
que toutes les micro-services, ça n'avait pas été
totalement migrés sur ce système
des permissions centralisées. Historiquement,
on était sur un paradigme un peu inversé,
c'est-à-dire que le micro-service
récupérait l'ensemble des permissions
que l'utilisateur avait, et c'est lui qui est regardé
dans la liste des permissions pour dire, est-ce
que dans la liste, j'ai la permission
qui m'intéresse. On a changé
un peu le paradigme pour que ce soit plus simple
et justement pour que ce soit plus évolutif.
C'est-à-dire, le micro-service a juste besoin
de se dire, moi je vais vérifier
serveur read, j'ai été le requête
en 30, répond moi oui ou non,
et la logique est totalement abstrait
et est centralisée. Du coup, la première étape
c'était de s'assurer que
tous les micro-services parlent la même langue,
donc parlent avec le même service d'authentification.
Ça n'avait pas été fait entièrement,
donc les nouveaux produits n'y avaient pas eu souci, mais
il y avait certains micro-services un peu légacies
qui n'avaient jamais été migrés totalement. Du coup,
il y avait une grande partie, en fait, fin de chantier,
fin de projet, un peu la queue de projet qui n'avait
jamais été totalement terminée. Donc la première partie
ça a vraiment été de faire ça.
Et donc mine de rien, ça prend déjà 3-4 mois
à migrer, parce que
c'est des équipes différentes, donc
il faut contribuer. Et surtout, c'est des scopes
assez importants. On parle
des services légacies, donc on avait un peu
nous, on interne tous les services
de gestion de compte, gestion
d'organisation, gestion instant,
tous ces micro-services-là.
Donc ça a pris déjà pas mal de choses.
Et après, la grosse partie
ça a été de migrer le modèle
de données. En gros,
on parle
actuellement, donc il y a un bouton
pour activer IAM, en fait, de manière technique
on n'active pas IAM, c'est-à-dire qu'on a
juste migré en interne notre
micro-service d'authentification
pour lui donner le modèle de données à IAM.
Et une fois qu'on a migré
ce système de données en interne,
en fait, l'intégralité des gens a utilisé IAM.
En gros, on a transposé le modèle
de données qui existait actuellement, qui était très simple
avec, on avait 3 rôles,
un utilisateur a été dans ces rôles-là, et
en fonction des rôles, on avait des permis sont associés sur une organisation.
On a transcrit ce modèle-là
dans le modèle IAM, donc il a été expliqué
plus tôt avec tout un système de groupe,
un système de policie, avec des permissions
un peu plus gradulaires.
On s'assurait que le précédent
on a transposé dans ce modèle-là.
Et une fois qu'on a fait le switch,
on a migré tout le monde
sur IAM en interne.
En gros, quand on a entreguimé
mis en production notre micro-service
qui utilisait le modèle de données IAM,
en gros, tout ce qu'elle oeait
à migrer sur le modèle de données IAM.
Et ça s'est fait bien,
ou ça a été dans la douleur ?
Étonnement, ça s'est fait plutôt pas mal.
En gros, on l'a fait petit à petit.
On s'est assuré qu'on n'avait pas
de changements de comportement.
En gros,
l'avantage c'est qu'on avait le modèle de données
avant et après. On a fait
des échantillons statistiques
pour s'assurer qu'en fait, pendant plusieurs semaines
on a pris les deux modèles de données,
on a pris des cas d'usage aléatoire en disant
telle personne, telle action, sur tel serveur,
est-ce que
l'utature elle a permis son pas.
On s'assurait que...
En contrôlant Y, en envoyant les doubles...
Et en fait, on s'assurait que les comportements
étaient identiques des deux côtés, plus des checks manuels
parce que nous, on savait des cas un peu spécifiques,
on avait déjà eu des problèmes de s'assurer ces cas-là,
mais en fait, on a laissé tourner pendant plusieurs semaines
pour s'assurer qu'il y avait
exactement les mêmes réponses sur les deux modèles
de données à gauche à droite.
Et après, en fait, on a déployé ça petit à petit
sur plusieurs AZ.
Et l'avantage c'est qu'on s'assure
de déployer, je dis pas, genre 50%
des requêtes sur tel AZ.
Et après, on s'assure de vérifier que le taux
d'erreur, le taux de deny
response sur l'AZ est identique
vu que c'est distribué de manière aléatoire
entre l'ensemble des microservices.
On est capable de s'assurer que si le taux
de réponse est identique entre les deux,
il n'y a pas de changement de comportement.
En tout cas, pas de significatif qui pourrait
mettre en bout qu'il y a un problème dans le score.
Ce que ça veut dire, c'est qu'en fait, nos clients
ont emigré Véryem, déjà depuis plusieurs mois
et on parle aujourd'hui encore
à des clients qui sont chez nous depuis longtemps
et qui ont peur de migrer vers Véryem
parce que ça peut casser leur prod, parce qu'ils sont
peur qu'il y ait des changements de droit.
Et en fait, activer Véryem sur sa console
c'est juste mettre à disposition en graphique
des fonctions et avoir
les API qui sont prêts à être utilisés.
Mais dans l'effet, Véryem est en production depuis
plusieurs mois sans un signe notable, tout fonctionne
très bien et on n'a pour l'instant
aucune erreur remontée par un client
autour des sujets du permis.
D'ailleurs, l'utilisation c'est marrant
parce que c'est pas marrant.
Il faut pas prendre peur, il y a un peu la fenêtre
qui arrive sur nous en disant activer Véryem
et tout, on a l'impression que ça va un peu
toucher en boulet. Mais en réalité,
c'est précisé, mais c'est juste que sur le message
on ne s'y attend pas. Mais en fait, non,
ça ne cassera pas vos comportements que vous êtes
déjà, vos clés ne vont pas changer. Si vous avez des clés
qui étaient déjà créés, donc ça, pour le coup
j'ai testé de migrer, j'avais un 2 compte
juste qui était existé pour Terraform et pour moi.
Et il n'y a pas eu de...
En tout cas, de mon côté de problème là-dessus, donc on pouvait le faire
globalement, les yeux fermés. Je me rappelle qu'il y a
un petit bout, ça va faire plus d'un an maintenant.
Il y a eu une rotation totale des clés
justement, pour permettre ça.
C'était déjà du coup en prévision de...
Oui, en fait, ça fait partie de la détechnique
que je parlais précédemment. En gros,
les apéliquies à Skyway, ça exéde
depuis très longtemps.
Historiquement, maintenant,
quand on a introduit la notion de projet,
les apéliquies maintenant étaient scopes à un projet.
Ce qui n'était pas le cas précédemment.
Précédemment, les apéliquies étaient scopes
à être attachées à des utilisateurs.
Ce qui était utilisé par la console
pour faire l'école d'API.
On n'avait pas de notion de GWT, un truc
de session un peu utilisateur, et d'apéliquies
un truc plus applicatif.
C'était un pat, une personne avec ses stockens.
Oui, on peut voir ça un peu comme ça.
Du coup, il n'y avait que des apéliquies, donc l'apéliquie était
attachée à l'utilisateur. Et surtout,
un concept un peu technique
qu'on a introduit avec IAM,
c'est que maintenant,
précédemment, avec une apéliquie,
tu pouvais récupérer des droits
dans l'ensemble des organisations dans lesquelles
t'es invité. Maintenant, c'est plus le cas.
Maintenant, on s'augmente vraiment
au niveau de l'organisation.
C'est-à-dire que même si toi, en tant que contrusateur,
t'invite dans plusieurs organisations,
ton apéliquie, elle va être uniquement
scope à une organisation.
Tu ne peux plus dépasser ce scope d'organisation,
même pour un GWT utilisateur,
n'aura plus les permissions sur plusieurs organisations.

Donc, les anciennes apéliquies
qui étaient rattachées
à des utilisateurs qui étaient dans plusieurs organisations,
on a essayé de les migrer.
C'est le point qu'on pouvait migrer automatiquement, on les a migrés.
C'était que dans une seule organisation.
En fait, on a pu faire
l'immigration en s'assurant qu'on savait
qu'il n'y avait pas de défait négatif.
Par contre, il n'y a plein d'apéliquies.
En fait, on était incapable
de savoir exactement
comment elle a été utilisée,
en tout cas, si vraiment il y avait des impacts pour l'utilisateur.
On était obligé
de la faire expirer et que l'utilisateur
la recréait. En la recréant,
s'occupe de sélectionner un projet.
Pour se dire qu'on a pécu les sciences pour se faire la quoi.
Le subset
d'un apéliquie qu'on n'a pas pu migrer
parce qu'il y avait
une décision de business
derrière associé, on n'avait pas le choix
de les faire expirer.
Du coup, c'est assez marrant parce que
côté utilisateur,
je vais prendre sur un temps large,
c'est après 3 ans que j'utilise pas mal
ce qu'elle oeuf. Il y a eu pas mal
de changements au niveau des droits. Il y a eu la première étape
de l'heure, c'était la notion de projet.
Après, avec les apélices copées, il y a eu la notion
de comme des de rôle
globaux, lecture seules, il y avait billing
et il y avait un full.
Aujourd'hui, on arrive à la YAM, donc on voit vraiment
une gradation.
C'est assez marrant parce que
les changements de l'extérieur, si je prends un point de vue purement fonctionnel,
comme je vous ai décrit la YAM
tout à l'heure quand je l'ai testé,
au final, c'est entre guillemets
d'un point de vue de 7h, pas énormément de fonctionnalité.
Mais on se rend compte quand même avec le temps,
moi, c'est l'impression que j'ai eu.
Du coup, ce podcast, c'est intéressant parce que ça confie
en ce que je pensais, c'est qu'en fait, ça a entrainé plein
de gros changements structurels derrière.
Et même si aujourd'hui, la YAM y a un côté
c'est cool, ça marche très bien,
c'est clairement top.
Mais moi, je suis resté un peu sur ma fin, sur certaines choses,
notamment, je vais prendre de 3 exemples
pour un peu étayer. Le fait de pas pouvoir
associer en fait des droits
directement à des ressources,
c'est-à-dire, par exemple, une instance,
tu veux dire, tout ce qui est sur l'instance,
c'est à droite de contacter du S3, des choses comme ça,
sur AdWallet, c'est des instances profiles.
On peut lui faire aussi sur des potes de mémoire, nativement.
Ces choses-là, ça a un peu manqué,
Guilhem l'avait dit à les logs d'audit.
Et il y a aussi,
il y a 2-3 autres petites choses,
notamment,
je l'ai pu en tête,
notamment, oui, le fait de pouvoir s'authentifier
sur des services manager avec de la YAM,
par exemple, sur YouTube, je peux m'authentifier
dans mon cube, c'est-à-dire avec YAM.
Des choses comme ça, ça, c'est des choses que j'attends aussi.
Mais là, en fait, de ce que je comprends,
de ce que j'ai compris, de ce que je vois,
c'est pour l'instant, c'est une très, très bonne
v1, c'est une très bonne progression.
Mais c'est vrai qu'on attend plus,
et je me dis, j'ai l'impression qu'on a
passé une étape où il y a un gros chantier
de fond qui a été abattu, et que maintenant,
du coup, on va avoir plus de,
on va dire, d'espoir d'arriver
à des intégrations, on va dire rapidement
sans devoir un peu, entre guillemets,
dire qu'il y a peut-être plein de choses
à refactorer derrière, etc.
Moi, c'est un peu l'impression que j'ai eu.
On a posé une grosse brique, maintenant, on va
construire au-dessus du coup notre maison.
C'est un peu ça. Quand tu dis qu'il y a eu beaucoup
d'intérations sur cette partie structure
d'une organisation et contrôle des accès,
ça correspond à l'histoire de Skellway,
donc on l'a dit hyper rapidement, mais
Skellway avant, c'était online, et
c'était pour un développeur, pour des
besoins très précis.
Ça n'a jamais été pensé au tout début,
comme un produit pour des grandes entreprises,
avec beaucoup de personnes et beaucoup de
droits différents. Et plus on attend,
plus on ne s'occupe pas de ce sujet
d'access management, et plus il est difficile
à implémenter, on doit rattraper toute la dette
qu'on avait. Le travail des 18 derniers mois,
c'est avant tout ça, c'est rattraper tout le retard,
poser la base, des fonctionnalités qui vont
répondre à 80% des besoins de nos utilisateurs,
peut-être un peu plus, peut-être un peu moins.
Et ensuite, on se met à l'écoute du marché,
on voit comment le produit est reçu, et on
priorise. On a appris en fait,
sur les derniers mois, que les logs, c'était
hyper important pour la plupart des utilisateurs, et
du coup, on s'y a tel beaucoup en 2023.
En effet, l'intégration
dans Cube, l'accès, la considération
d'une ressource comme un principal, comme
une identité à laquelle tu peux donner
des droits, c'est des sujets qu'on imaginait,
mais on les a pas pris en compte, parce que
il y a toujours l'arbitrage à faire entre
est-ce que je le sors mon produit tôt,
avec des fonctionnalités qui vont
avoir un arrière-goutte trop peu,
ou est-ce que je le sors tard, mais je
rate le coche, et finalement, je perds mes clients
parce qu'il n'y a pas eu d'accès à ce management.
Non. Oui.
Comment ça s'est passé, en interne, pour
l'intégration de tout ce genre de choses ? Comment ça s'est
fait le projet, si jamais on parle plus vraiment
d'organisation au sein de quel web, votre projet,
comment il a été reçu, est-ce qu'il a été créé Xnilo,
comment ça s'est passé, justement,
cette intégration au fur et à mesure
de ce nouveau projet, parce que tu l'as dit, il y a une dette,
enfin, la IAM, il faut voir que pour des boîtes
comme AWS, c'était quasiment le premier produit,
enfin, ils ont S3 et après, ils ont la IAM.
Donc, comment ça s'est passé, vous,
l'intégration ?
L'intégration, en fait,
l'avantage que la plupart des concepts qu'on a
décidé, qu'on avait vu en de migraines, et déjà
dans notre scope, donc finalement, ça s'implifiait
des choses en termes de gestion de projet et de communication.
Déjà, en fait, un niveau de technique,
on a eu un choix assez tôt, c'est-à-dire
en gros, des briques qui gèrent des
constructeurs, des organisateurs, des organisations,
il y en a existé déjà. On aurait pu
déjà décider de construire par-dessus.
Donc, on aurait pu sortir, je pense, IAM en
deux fois maintenant, à mon avis, mais on a fait
le choix, en fait, de partir sur une brique
totalement séparée, notamment justement, en fait,
un pour se forcer à tuer la dette technique,
disant, ben, je repars d'une feuille blanche.
On aurait pu construire sur le modèle de
données existantes, on a décidé de repartir
d'une feuille blanche et de se dire, ben, qu'est-ce qu'on veut
pour notre IAM ? Donc là, en fait, on a eu beaucoup
de réflexions sur, en fait, on a regardé
ce que fait la concurrence, on ne va pas se le cacher.
On dit, ben, qu'est-ce qu'ils font bien ? Qu'est-ce qu'il est pas terrible ?
On va aller voir un peu tout le monde, se dire, bon, ben, qu'est-ce qu'on peut
pêcher là ? Qu'est-ce qui est intéressant ?
Quels ont été justement les modèles que vous avez regardés
le plus ? Ceux qui vous ont inspiré ?
Ben, tous sont en train de redire la WS,
GCP, enfin, les lignes grands, à dur, on a regardé
un peu, surtout qu'en plus, nous, on a
une notion de projet qu'on va pas retrouver chez la WS.
Du coup, ça aussi, on peut pas tout prendre
et transcrire tel quel, donc on a obligé
un peu de regarder un peu.
Le projet qu'il existe sur le GCP, pour le coup ?
Mais qu'il n'y a pas la même notion de granularité.
Nous, c'est pas encore exactement, on peut pas
transcrire tel quel, enfin, c'est le même nom,
mais on n'a pas les mêmes contraintes associées,
du coup, c'est aussi compliqué.
Mais du coup, on est partis vraiment d'une feuille blanche
sur le modèle de données.
Ce qui nous a impliqué, en fait, énormément, justement,
dans la partie des techniques, de migrations,
c'est-à-dire, en fait, on a dû migrer le modèle de données
qui était précédemment géré par
le micro-service actuel.
On a dû le migrer
sur le nouveau.
Là, c'était énormément, parce que le but,
c'est qu'on ne peut pas se dire, je coupe
pendant deux heures, je migre les données et c'est amené.
Du coup, on a dû migrer
sans couper le service
avec la synchronisation de données à droite à gauche,
avec des codes d'appui
gRPC, pour s'assurer que le modèle de données
reste synchronisé dans le temps.
Parce que finalement, on peut pas, parce que d'un côté,
on a un modèle un peu historique,
et de l'autre, on a le même modèle de données,
mais sous le format IAM, donc c'est beaucoup plus compliqué.
Typiquement, une API key
avant était associée à un projet.
Du coup, on a obligé de traduire ce concept-là
dans IAM, donc on se dit, bon, ok,
on va avoir une autre API key qui va être
attachée à une application.
Cette application-là, on va les donner les droits
qui avaient exactement la même app...
qui avaient exactement la même droite précédemment,
donc on a obligé de tout faire, mais uniquement
scoper sur un projet. Là, on est obligé de transcrire
une ligne, entre guillemets, dans une base de données,
en 10 dans l'autre, parce que le modèle de données
est plus complexe. Et donc, l'idée,
c'est d'assurer qu'à droite, à gauche,
ça reste synchro au fil du temps.
Pour, en fait, quand on est sûrs à certains,
un truc y met, appuie sur le petit bouton
pour dire, maintenant, au lieu de lire
dans le modèle de données à gauche, je vais le lire
dans le modèle de données à droite, et je suis sûr
que c'est le même modèle de données, et donc
j'ai aucun changement de comportement, c'est juste que mon modèle
est beaucoup plus complexe à droite.
Et vous avez fait des changements technologiques entre les deux,
parce que là, tu parles de modèle de données, on est quand même
très très haut niveau, tu as parlé un tout petit peu de GRPC,
si j'ai raison, est-ce que vous avez fait des changements
technologiques de codage,
de base de données ?
Alors, la base de données, c'est pas la même base de données,
mais c'est la même technique, on est sur du poste gré.
Sur le sujet
de base de données, en fait, on s'est posé la question,
mais je reste qu'on utilise une base de données
des graphes, des choses comme ça.
Quand on parle de la gamme, oui, quand on a un modèle de droit,
la période des temps, on va penser graphes...
Après, il faut faire aussi un peu...
parce que nous, on est 8
dans l'équipe. Sur la
partie AIA, on était à peu près 3 développeurs
temps plein qu'on tournait.
Donc, c'est 3 développeurs sur 10 U, c'est ça à peu près ?
Ouais, à peu près, on a 3, 3, 1,5, ça va dépendre.
En gros, il y a des personnes qui sont rentrées, d'autres qui sortent.
Sur la partie BAC, après,
comme ce qu'elle oeille, un écosystème,
à chaque fois, on est organisé en équipe,
on va avoir une équipe qui va être sur le front,
une équipe qui va être sur la documentation, une équipe qui va faire le provider terraforme,
comme on le disait juste avant.
Donc, 3 développeurs concentrés sur ça,
mais autour de ça, plein de gens qui travaillent
à 10-20 % sur le sujet.
Donc, les développeurs qui travaillent sur le provider terraforme,
ils sont dédiés sur le provider terraforme,
mais pas sur votre projet ou les produits de l'écosystème.
On fait les coups de main sur certains sujets, effectivement,
mais quand je parle 3, c'est vraiment dans l'équipe BAC,
du coup, on est sur du post-gray,
donc, ouais, les bas de graphes.
On a réfléchi, après, il faut prendre
la big picture, si on dit.
Si on décide de partir sur une techno,
déjà, il faut s'assurer que l'équipe la maîtrise.
Post-gray, c'est connu,
on maîtrise en interne,
on est quand même sur des problématiques assez sensibles,
parce que derrière, il y a toute la résolution de permission,
d'immilisons en plus,
ça veut dire qu'à chaque call, il y a d'immilisons
de plus sur la résolution des permissions.
Donc, c'est quand même un sujet assez sensible.
Et après, qui dit Nouvelle Technos,
dit, bon, il faut s'assurer du cycle de vie
de l'applicatif,
il faut gérer les mises à jour,
il faut gérer le backup,
il faut gérer s'assurer que le backup marche.
Il y a tout un écosystème autour de contraintes
qui sont associées.
Nous, on interne, on a la possibilité
d'avoir du post-gray facilement.
On a une équipe plateforme
qui nous permet d'avoir des services manager.
Post-gray, on fait partie.
Ça nous permet de ne pas nous préoccuper.
Ça rend forcément en compte
dans le choix de la techno.
En se disant,
est-ce qu'on est prêt à rajouter du run
sur une nouvelle techno
qu'on ne maîtrise peut-être pas forcément,
en tout cas pas forcément dans les détails,
dans la précision par rapport à ce qu'on a besoin.
Et en fait, post-gray,
globalement, ça répondait quand même aux besoins.
En faisant les choses bien,
un schéma dans une base de données relationnelle,
même par rapport...
en passant juste un petit peu de temps,
en faisant les choses correctement,
on a quand même réussi, même par rapport au modèle de données précédent,
on résout les conditions plus rapidement maintenant,
alors que le modèle de données est plus...
plus compliqué.
On a quand même dit, enfin, j'ai pu les chiffres en tête,
mais je crois qu'on a descendu le 49% de 20 ou 30%.
Donc c'est quand même pas négligeable.
Juste en fait, en passant de temps, on a besoin des choses bien.
Donc en fait, je pense que ça peut être
à un moment donné, la question se posera
si on a des problèmes de volumétrie, si vraiment, en fait, on a des problèmes de performance.
Alors actuellement, c'est pas le cas.
Du coup, on est sur une reposerie classique
qui répond extrêmement bien à nos problématiques.
La grosse différence qu'on a eu,
ces côtés, l'engage de programmation,
la partie historique, c'est du piton, on est sur du go maintenant.
Pour diverses raisons, notamment, je pense que c'est plus...
enfin, c'est vraiment par rapport à la...
par rapport à l'équipe, par rapport
aux envies de l'équipe
plus que par...
pour des questions de performance.
Même si, globalement, on remarque que c'est quand même
plus rapide et qu'on a moins de problèmes...
on a moins de problèmes
sur comment s'est intégré l'écosystème.
Mais à part ça, on est...
il faut savoir que tout le micro-service
en interne, c'est du GRPC.
Ce qui fait que tout passe par la PQTW,
et en gros, on a une translation
de requêtes restes en requêtes GRPC
qui est fait automatiquement par la PQTW.
Ce qui fait qu'on consomme nos API
avec des requêtes restes
et nous, derrière, c'est du
GRPC qu'on reçoit en interne.
À part ça, on est sur quelque chose de vraiment super simple.
Enfin voilà, c'est vraiment... on n'a pas d'autre...
Et les PQTW, voilà, je...
Disgress, c'est vous qui l'avez codé,
ou c'est un produit... Non, non, il y a une très belle...
une très belle vidéo YouTube
fait par Jérôme, qui est un...
de l'équipe actuelle qui explique un peu comment ça marche.
Globalement, en fait,
on ne peut pas se permettre de recoder
une API Guettway, enfin...
C'est illusoire et tout ça pour faire un travail
moins bien qu'est-ce qui existe déjà.
Il y a eu plusieurs choix qu'on a été envisagés
et en fait, nous, on utilise Envoy,
qui est vraiment, vraiment cool.
Donc Envoy, qui est un projet
même qui utilise Mary Stayo, etc.
Enfin, c'est à la base qui avait été fait par
l'IFT, ça, justement.
L'IFT, c'est ça, exactement. Donc, VTC,
de base, et qui l'a rendu donc,
projet de... de...
de Load Balancer en C++.
Ouais, qui marche très bien et en fait...
Qui est d'ailleurs, avec une API, enfin, en gros, globalement,
dites-vous que c'est un espèce de blob qui fait du Load Balancing
mais avec... comme configuration
qu'une API. Ouais, c'est ça. Et puis,
il y a plein de briques qu'on peut venir greffer.
Typiquement, on vient greffer
notre propre brique de rate limiting.
Pareil, l'authentification est fait directement
au niveau d'Envoy. Donc...
Rate limiting qui fait... C'est Envoy va faire
des call GRPC à un blob de rate limiting
qui va répondre oui ou non. Exactement. Voilà, tout est...
Tout est API. Enfin, je...
Je vais vraiment configurer Envoy directement.
Tout est GRPC, c'est magnifique, c'est génial.
Du coup, nous, ça s'intègre super bien notre récosystème.
Enfin, tout en interne, c'est du proto-buff,
nous, au micro-service, on a du proto-buff,
c'est du GRPC partout, du coup, ça s'intègre super bien.
Et pareil pour la brique d'authentification,
on a notre micro-service
qui, lui, implément le proto
d'Envoy.
On répond la réponse qui va bien
et en fait, c'est juste que notre micro-service va taper
dans le modèle de Donarium pour répondre la requête, quoi.
Du coup, du coup, là.
Ah, cool.
Et à peu près, là, le temps de développement
de ce backend-là, c'était...
Ben, finalement, en fait, une fois que
toute la dette technique a été migrée
et que finalement,
l'applémentation du backend, en fait, c'est hyper rapide.
C'est finalement ce qui est visible à l'utilisateur
sur la console, c'est quoi,
c'est un code
de user, d'applications,
de rules avec des policies.
Enfin, c'est super simple.
Je pense sur les 18 mois, j'ai pu les chiffres en tête,
mais on a bien 12.
C'est de la dette technique.
C'est assuré que le modèle de données qu'on avait précédemment
ait transcrit dans le nouveau modèle de données.
Une fois qu'on avait le modèle de données
avec le check de permission
utilisé, ce nouveau modèle de données,
en fait, le plus gros effet, quoi.
Le reste, c'est juste fournir les appellés
pour consommer les données dans ce nouveau modèle de données.
Et vous n'avez pas regardé des projets,
parce que... Enfin, ça, c'est marrant.
C'est un sujet que j'ai poncé ces derniers mois là-dessus.
Des modèles comme Caspine ou des choses comme ça,
des modèles open source qui existaient,
qui font justement du...
C'est exactement ce que vous vous présentez,
mais de manière open source, pour le coup.
Oui.
Vous auriez pu partir d'une base,
même si après, elle est abstraite par votre...
Mais ça d'ailleurs, dans le sens...
Parce qu'il faut voir que le laia,
mais ultra important, parce que tu l'as dit un peu,
c'est que si jamais on se plante dans les règles,
qu'on donne des droits à quelqu'un qui devrait pas en avoir, etc.
C'est un point central de la sécurité.
Oui, tout à fait.
Tout à fait.
On a envisagé un peu, on a regardé un peu ce qui existait
niveau open source.
Après, c'est pas trop la politique en interne.
Et notamment, surtout pour nous,
parce que, en fait, si tu commences à utiliser
une bricoplin source, surtout si c'est ce truc-là,
tu vas vite te retrouver bloqué dans les contraintes
à poser par ta solution.
Nous, un des gros avantages qu'on a,
c'est que quasiment tout est fait
sur mesure, en tout cas,
toutes les A-Pays, c'est vraiment de l'interne,
toute la partigestion des permissions, c'est de l'interne.
Ça nous permet d'avoir vraiment un couple à chevaux,
c'est-à-dire qu'on utilise notre modèle de données
comme on en vit.
Le modèle de données qu'on a envisagé pour AYAM,
qu'on a réfléchi plusieurs fois, on l'implément de
comment on en vit.
Ça nous permet d'avoir les A-Pays exactement designés
comme on les veut.
On n'a pas de surcouche de middleware envisagé
pour se dire, pour transcrire une requête A-Pay
qui arrive sur le modèle de données
qu'on a utilisé par tel applicatif
open source qu'on décide d'utiliser.
En fait, on a pas de...
de la maitrise de A-AZ
du cœur du problème.
Ça, c'est plus long.
Non moins, en fait, à la maitrise de A-AZ
de ton scope.
Et sur un projet aussi sensible qu'à AYAM
et par rapport aux évolutions qu'on envisage,
la vête TABRIK,
ton TABRIK open source, elle va quand même te brider
sur ce que tu es capable de faire
et ce que tu envisages de faire dans la suite.
On peut en débattre dans un autre moment
le dessus, c'est vrai que...
Je connais sauf que... un peu mon opinion
sur ce genre de choses.
Je pense que ça, c'est aussi une orientation
de ce qu'elle voit en général.
Il y a eu dès le départ, quand il y a eu
un clabriques basique des VM,
il y a eu tout de suite le choix de recoder
une brique et pas de réaliser un truc existant
comme OpenStack ou autre, ce qui aurait pu être le cas.
Oui, mais c'est vrai. C'est un peu une culture
d'entreprise pour le co-est-ce-n'est.
Mais tu vois, typiquement, ça nous permet
maintenant, on a les elastic metal,
donc les dubermetal, mais ça nous permet
d'avoir des primaires networks qui vont communiquer
avec des instances, qui vont permettre de communiquer
avec un land balancer.
Ça nous enlève
tout plein de blockeurs qu'on aurait pu avoir
et ça nous permet de faire
une intégration entre nos produits comme on l'envisage.
En fait, on n'a pas...
Tu peux pas avoir de contraintes techniques,
ça ne supporte pas, tel truc, machin.
C'est plus long, mais au moins on est exactement
libre de faire exactement ce qu'on a envie de faire
exactement comme on a envie de les faire.
Je suis une petite question,
parce que du coup, j'ai un peu replongé
sur la Pays, etc.
Vu que de base, j'ai tout dans un siya
et donc je ne fais pas tellement gaffe au temps d'exécution.
Et là, c'est vrai que j'ai vu,
depuis la sortie d'Ayam, et même un peu avant,
comme tu t'en as parlé de tout à l'heure,
une grosse augmentation des pertes.
Donc je voulais savoir si c'était le lien
à ce rework, en fait,
et à ce travail sur l'Ayam,
en général, et la Pays get-away,
ou s'il y a eu d'autres travaux qui ont été faits.
Parce que c'est vrai qu'à l'utilisation, ça se ressent pas mal.
Tu l'as remarqué où ?
Moi, c'est sur Terraform, notamment,
et la Cli un peu plus rapide aussi.
Plus Terraform, pour le coup.
Il y a des choses qui sont faites,
notamment sur la partie à Pays get-away.
Après, sur Ayam,
faire un désavantage aussi,
c'est de repartir d'une feuille blanche,
c'est de se dire de prendre en compte
les performances dès le début,
et de se dire qu'on s'est fixés
dès le début des SELI, des SELO.
On s'est dit, voilà, on ne veut pas,
le 80% de s'il dépassent
250 ms sur les tonts de réponse.
Et du coup, on s'en bloque,
on les mesure,
et on s'assure dès le début
et aussi que le développement de SIA se train.
Chose qui n'était pas faite précédemment,
et en gros,
c'est...
C'est des problématiques qu'on a en tête,
dès la conception maintenant,
chose qui n'était pas forcément,
et la technique fait,
et puis l'historique des services fait que
je pense que c'était moins prioritaire,
moins suivi entre y mais.
Moi, j'ai un sujet sur justement
vos politiques de règles.
Est-ce que vous êtes repartis un peu
from scratch, ou est-ce que vous avez
fait utiliser des langages type SEL,
CEL pour ça, ou Durego,
ou des choses comme ça ? Et est-ce que
demain, vous envisagez que l'utilisateur
puisse rajouter des modèles de règles
un peu plus compliqués, via justement
du SEL ou du Rego ? C'est ce qu'on envisage, ouais.
On partait
néanmoins
d'un legacy côté produit,
qui était ce qu'il est, avec des produits
qui sont construits sur
4-5 ans avant que YAM arrive,
et qui n'avaient pas forcément tous
les mêmes façons d'implémenter les permissions,
les mêmes façons de les écrire, de les déclarer.
Ce qui fait qu'aujourd'hui, ce qu'elle voyait,
même si la YAM montre
quelque chose de très uniforme, on reste
avec des produits qui ont des fonctionnements un petit peu différents.
On a dû
faire un peu du from scratch, avec
des permissions qu'on expose
qui
masquent un peu cette complexité
à l'utilisateur, et avant
d'être prêt à avoir
un langage pour que le
l'utilisateur puisse construire ses propres règles,
on a encore un travail d'uniformisation
au sein de tous les produits,
et c'est pour ça qu'on a sorti une première
version d'YAM, et on va la faire évoluer.
Parce que derrière,
chaque produit, on va faire le tour avec eux, leur dire
« ok, voici les nouveaux standards qu'on aimerait pousser,
parce que c'est comme ça que nos clients l'habitude d'utiliser,
voici les changements que vous devez faire
dans votre façon de déclarer les permissions,
une fois que ça s'est fait
sur tous les produits, et aujourd'hui
c'est une vingtaine de produits, alors on pourra
mettre en place
celles ou une autre façon
d'écrire des règles personnalisables.
C'est d'accord. En tout cas, c'est de l'approche
qu'on envisage, rien n'est figé dans le marbre
à l'heure actuelle, mais
en fait ça offre
une flexibilité assez cool
pour l'utilisateur, de spécialisation
avec les paramètres qu'on lui fournit
et puis c'est hyper évolutif, on a juste à fournir
d'autres paramètres, et après l'utilisateur
il a juste à changer sa règle pour prendre en compte
ses nouveaux paramètres qu'on supporte.
Par exemple, dans GCP, on parlait de mettre
des règles sur une instance,
clairement GCP a dit « tout ça,
ça va dans celle,
tu mets ta règle, tu dis « l'instance,
je donne le droit sur tous mes buckets,
mais je dis
une règle où si le bucket s'appelle Toto,
là j'ai le droit, j'envoie un trou,
là non ».
C'est plutôt ça la manière dont ça a été
implémenté à ce niveau-là.
Après, le IAM sur GCP,
c'est un bordel monstrueux, ça donne ressources
où tu as le droit d'en mettre d'autres pas,
et donc il y a un espèce d'héritage un peu partout
qui est un peu bordélique. C'est ça la vraie complexité produite
pour nous, c'est garder la simplicité
parce que, quand on cas les fuites de données
récentes sur ces dernières années,
il y a un bon pourcentage où c'est du bucket
mal configuré, des droits d'axe mal configuré.
Aujourd'hui, chez Esquelwae, on va avoir
une granularité d'action
peut-être pas encore assez fine selon certains,
mais elle est compréhensible. Vous passez
moins de 10 minutes sur la console, vous avez compris exactement
qu'est-ce que vous avez comme droit.
La mission qu'on va avoir sur les prochaines années
c'est augmenter notre couverture fonctionnelle
mais garder cette simplicité, et ça,
c'est le vrai gochemard d'un product manager.
C'est vrai que pour moi,
en fait, j'ai pas d'impression qu'il y a de solution miracle.
C'est un curseur qui se déplace,
c'est une chose qui peut être personnalisée,
puissante, plus ça va être
une petite à petite vinaigase,
et on le voit bien que WS, c'est
hyper usinagase, mais on peut aller
très très très loin avec.
Et je pense que là-dessus, il y a vraiment
un curseur à placer. Soit on voit le truc,
on essaie de faire entre guillemets
deux niveaux pour les gens qui vaillent plus loin,
soit on essaie de placer le curseur
sur lui-exe, et on se dit que ça va suffire
je sais pas, 80% des personnes,
et puis les autres personnes trouvront soit
un autre moyen de faire, soit, bah choisiront pas,
de moins ça atteint un point bloquant pour elle.
Ce qui est sûr, c'est que la complexité
à minimap doit être abstrait par d'autres
moyens, soit c'est par l'interface, soit
enfin en tout cas, il faut que tout le monde trouve son compte.
Ça c'est vraiment quelque chose
vraiment une des règles qu'on essaie de se fixer,
même si c'est compliqué derrière, il faut
que Mme Michuque a créé son compte
qui veut juste sécuriser son projet
simplement. Bah c'est pas qu'elle doit
passer trois heures à lire dix pages de docs
pour comprendre exactement où elle doit mettre
ses règles, est-ce que c'est au niveau
déduiteur, est-ce que c'est au niveau de la ressource,
oui, mais du coup qui gagne si une
un qui répond non ? Enfin voilà, tout
ces trucs là, à minima il faut qu'elle
puisse faire simplement ce qu'elle envie
de faire. C'est la grosse difficulté
oui. Comme je disais, on se produit, on
l'a sorti en BÉTA en juillet 2022,
donc là on enregistre en janvier 2023,
ça fait six mois. Sur ces six mois
on a collecté pas mal de feedback,
c'est vraiment un collecté le plus possible
dans ces phases de BÉTA, et on a eu
des feedbacks qui vont du, je ne comprends pas
du tout ces concepts, c'est beaucoup trop
compliqué pour moi,
ça c'est vraiment la base de la base
et je m'attendais beaucoup plus.
Et en termes d'attente de la façon
dont se sont soutirés les concepts, on a
des gens qui vont être nourris par AWS,
qui ne connaissent que AWS, donc dès qu'on s'en
nélevoie un peu, ils ne sont pas contents
et on va avoir d'autres personnes qui sont
chez nous parce qu'on est européen, qui veulent
qu'on soit très souverain, très indépendant
dans nos choix et qui vont nous reprocher
de s'être inspirés d'AWS. L'équilibre
est super dur à trouver, on espère
l'avoir trouvé et du coup on continue
à être à l'écoute de feedback, j'espère que
à la suite de ce podcast on va avoir
aussi des gens qui vont venir vers nous, qui vont nous en donner
des trucs. Si jamais on veut vous faire un feedback,
c'est comment ? C'est en direct, en pinguant
sur Twitter ? Alors Twitter
n'est une dernière, ni moi, ça me traite très présent,
je n'aime peut-être un peu plus, mais on a, on a,
chez Scaleway, un outil
qu'on utilise beaucoup pour recevoir des feedbacks, c'est Slack,
on a un Slack community, avec plus
de 10 000 personnes présentes dessus.
C'est slack.skelly.com
Oui. Et dessus, on a
pas mal de chaines différentes,
on a un chaine IAM, par exemple, on collecte
des feedbacks sur IAM, on les a
dans plusieurs langues, on les a
sur tous les sujets et tous les produits.
Je pense que si vous voulez parler
des product managers, des ingénieurs
de l'équipe Scaleway, c'est le canal
de préférence. Il n'y a pas que des product managers
effectivement, on typiquement
n'en suit ce qu'ils se disent dessus et on répond
directement, on essaie d'avoir une proximité
entre nous et nos clients, qui nous permettent
de, sans avoir
une espèce de
mur entre nous et nos clients.
C'est un des trucs qui est sympa avec le Slack community.
C'est vrai qu'on a maintenant parlé du coup,
ce serait que la diversité
des profils aujourd'hui, c'est un vrai
problème quand on fait une solution comme ça,
parce que moi je vois, j'ai fait,
on a plusieurs clients et des niveaux de maturité
qui sont très différents, et
autant pour certains clients, ils sont habitués à faire des choses
assez poussées, ils connaissent très bien IAM, etc.
Et pour eux, très vite,
un peu comme moi, on a très vite mis des mains dedans
et moi globalement en une heure avec la doc
et le provider, je comprenais comment ça
fonctionnait, je comprenais ce que je pouvais faire.
Et il y a des personnes qui sont
des fois pas du tout aptes au cloud, et pour elles
rien que la notion de, qu'est-ce que c'est qu'un IAM
en fait, elles sont un peu dépassées.
Donc c'est pas un exercice
simple et je pense que
il faut en être conscient qu'au niveau technique
comme on disait, il y a un gros refactoring,
au niveau produit, il y a tout cette problématique
de trouver le bon équilibre et d'accompagner
les gens. Donc c'est vrai que
c'est un gros projet quand même, c'est pas rien,
c'est pas pour rien qu'aujourd'hui
si on prend les cloud hors GAFAM,
il y en a très peu qui ont un IAM
qui soit propre, fonctionnel et puissant.
En réalité, j'en vois pas beaucoup.
Donc on peut dire que ça va dans la bonne direction
à l'heure actuelle et qu'il faut essayer, enfin,
faut l'essayer quoi. Ah, clairement,
si jamais vous voulez faire du cloud
européen
à plus forte raison français
et que vous aviez eu un peu ce
blocage au niveau de l'IAM, ben là vous avez
déjà quelque chose qui vous donne
un premier pas, entre guillemets, et je pense
comme on disait que petit à petit les
briques manquantes, entre guillemets vont venir, la base est là.
Après justement,
vous parlez du Slack, mais si jamais
ben je prends mon exemple,
si jamais j'ai mis un lien à l'intégration
d'IAM sur Kubernetes
ou des choses comme ça,
faut passer plutôt par
fiture.scaleway.com qui sert
à mettre en avance que la communauté
a besoin comme fiture, ou directement
sur le Slack ?
C'est un bon rappel, on n'est pas
chtttouti, en effet on a cet URL
qui permet de proposer
ses propres features, ou d'upvoter
des features proposées par d'autres.
Si vous avez besoin d'une feature, le mieux
c'est de faire un peu les deux, c'est-à-dire
voter sur fiturequest.scaleway.com
c'est peut-être pas l'URL exact,
mais vous trouverez. Et
d'en parler sur Slack, on met
aussi des entretiens utilisateurs
en tant que product manager
un job principal si on suit la théorie
du product, c'est de parler à ces utilisateurs
constamment, constamment. On en fait pas mal
les entretiens,
on discute sur Slack.
Si vous avez des choses à nous raconter
sur votre utilisation de Scaleway, est-ce qu'il va, ce qu'il va pas
vraiment manifestez-vous, on est toujours
à l'écoute. Et ça, pour ça c'est Slack
après vous pouvez
de façon une autre récupérer nos mails
et nous contacter je pense.
Super, merci beaucoup
merci vraiment pour l'invitation
c'était vraiment en plaisir de pouvoir
justement avoir un peu plus d'informations
un peu de l'intérieur
sur les Cloud Provider.
J'espère que vous aurez appris des choses
j'espère même qu'on pourra refaire
des épisodes comme ça sur d'autres
sur d'autres sujets dès que
vous avez les futures features qui sortent
voilà vous pourrez nous présenter un peu la killer
features dessus.
Merci à tous d'avoir écouté
jusque là et
et on pourrait se voir
sur Twitter
sur le Discord également
tous les liens bien sûr dans la description
comme on dit.
Merci à tous et merci à vous
pour l'invitation en tout cas.
Merci à tous et c'est super cool.