Bienvenue sur le podcast Artisan Developer, l'émission pour les programmeurs qui veulent
vivre une carrière épanouissante. Prêt à passer au niveau supérieur ? C'est parti !
Aujourd'hui je suis avec Grégory Ouyon. Grégory bonjour. Bonjour. Bonjour Mouna.
Enchanté de t'avoir sur le podcast. Est-ce que tu peux te présenter en quelques mots pour
les auditeurs qui ne te connaîtraient pas ? Oui, donc moi c'est Grégory Ouyon,
je suis le fil de CTO pour l'Europe, Montmagnes, Orient et Afrique à New Relic.
Mon rôle chez New Relic, c'est avec tout mon background de CTO, avec 30 ans de VP Engineering
CTO dans le domaine de l'aviation et de l'IT. C'est vraiment de rencontrer les entreprises,
les dirigeants, les leaders de devs pour parler d'observabilité, de transformation, de modernisation
et de comment les plateformes et la technologie d'observabilité peuvent les aider à aller plus vite,
plus fort et délivrer les objectifs business et techniques qu'ils leur sont donnés.
Et justement sur ce thème de l'observabilité, je te propose que ce soit le thème de l'épisode.
Est-ce que tu peux nous expliquer un petit peu plus ce qu'est pour toi ce concept d'observabilité ?
Oui bien sûr. L'observabilité on va peut-être dire c'est une évolution du monitoring.
Le monitoring on le connaît bien. C'était quand on avait des architectures monolithiques,
qu'on déployait peu fréquemment sur des architectures plutôt statiques,
des gros serveurs quand on faisait du scale-up.
Et à ce moment-là on monitorait quelques composants du stack applicatif et surtout de l'infra
et on utilisait les logs. Et grâce à ça on détectait qu'il se passait quelque chose à un moment donné
dans le stack, on cherchait à réagir. Depuis quelques temps, quelques années, on a maintenant
du code qui est beaucoup plus complexe puisqu'il se décompose en micro-service.
Il est développé par de plus en plus d'équipes diverses, les two-pizza-teams DevOps.
Et il est déployé sur des architectures qui sont beaucoup plus volatiles, container, cloud.
Donc en fait on a un animal biologique qui est le code qui est devenu beaucoup plus fragmenté,
volatile et le monitoring ne suffit plus. Donc l'observabilité c'est essentiellement
d'instrumenter l'ensemble du stack, infrastructure, container, host, virtual machine, le code,
le middleware, tout le cloud pass et le software lui-même avec de l'application performance
management et puis même le digital experience tout ce qui est browser, mobile etc. Et donc
toute cette télémétrie qu'on va collecter au travers d'agents ou de télémétrie au
source va permettre d'avoir une compréhension complète de comment un système se comporte,
aussi complexe soit-il en temps réel. Et grâce à ça on va pouvoir détecter les problèmes
qui se développent beaucoup plus vite avant de créer des incidents et puis améliorer,
optimiser la performance du système de bouton. Et ce que tu me disais, l'intérêt que tu me disais
que tu pouvais même dans cette stack d'observabilité y mettre des métriques business et qu'à partir
du moment où tu avais cette espèce de stack qui était centrale commune à tout le monde,
tu voyais des comportements changés. En quoi est-ce que le fait de rassembler les stacks
individuels de chaque équipe dans une même stack, quel impact tu vois que ça a sur les équipes ?
Alors moi je l'ai vécu quand j'ai implémenté l'observabilité dans mon entreprise précédente.
On vit en fait les outils de monitoring en particulier en tendance à refléter les silos,
c'est-à-dire que les équipes adoptent les outils.
Oui c'est complètement logique.
Et souvent les outils sont à visibilité fermée, les ops sont axés à leurs outils,
les devs ont accès à leurs outils devs. Et en fait quand le CTO se tourne vers leurs équipes
en disant on a eu encore une panne majeure qui a impacté tous nos clients, Tirohann cette nuit,
chacun va dire de mon côté tout va bien. J'ai regardé dans mes outils et tout va bien.
Et donc en fait les outils perpétuent un peu le BlameGame.
Une plate-chample d'observabilité c'est fournir à tout le monde, et c'est ça qui est très important,
la même vue sur l'ensemble du stack.
Donc bien sur le coup un opérateur va voir non seulement ce qui se passe dans son mainfra,
mais il va aussi voir ce qui se passe qu'il y a des erreurs java dans le code du développeur.
Le développeur va voir que des serveurs sont totalement mal configurés et ne sont pas
incapables de supporter son code. Ça crée au départ un certain inconfort puisque on
dit couvre dans ce coup tout ce qui se passe sur le stack, mais ça a deux vertus cardinal.
Très rapidement ça crée une vue unifiée de quelle est la dette technique,
quelles sont les problèmes. Donc la collaboration accélère énormément
et ça permet de résoudre les problèmes beaucoup plus vite par la suite.
Donc après ce moment de vérité où tout le monde voit tout le monde,
après c'est une accélération, c'est un aménage de la collaboration,
et ça aide les équipes aussi à transitionner vers le DevOps s'ils n'y sont pas encore
puisque en fait ça va être un outil de formation des opérateurs à comprendre le code et l'architecture
logicielle. Ça va permettre au développeur de comprendre que leur code tourne déployé sur
une architecture d'infra et de middleware et que donc c'est pas juste du code qui développe,
c'est une architecture qui va délivrer des services en production et ils en sont responsables.
Moi ce que je constate c'est que l'observabilité c'est vecteur de collaboration,
vecteur d'apprentissage et des vecteurs d'accélération pour aller vers le DevOps.
Et justement cette notion d'évolution, d'appropriation du DevOps,
c'est quoi les fringues que tu vois aujourd'hui, parce que quand tu me parles comme ça
d'équipes assez autonomes qui capables d'intervenir, tu vois toi tout ce que tu dis c'est que
les outils que tu d'observabilité ou de monitoring évoluent et sont le reflet un petit peu des silos,
donc on voit qu'il y a une espèce de tendance à aller vers des équipes plus petites et polyvalentes.
C'est quoi les fringues que tu vois toi encore dans les entreprises, parce que moi par mon prise
mais ma lentille de consultant, alors je pense que j'ai un biais, mais je vois encore beaucoup
d'entreprises qui sont hyper silottées et notamment avec une espèce de chasse gardée,
des serveurs d'infra ou quand tu parles à un DevOps, la simple idée d'ouvrir les accès routes,
un DevOps, tu as lui fait dresser les poils et quand tu parles à un DevOps tu te rends compte que sa
culture de l'Ops est quand même assez limitée et ça je parle dans beaucoup d'endroits.
Comment est-ce qu'on peut faire péter ces verrous là ?
Alors moi j'observe deux grandes tendances. La première effectivement c'est qu'il y a une espèce
de contrappe confiance qu'on n'arrive pas à établir. Le développeur finalement est considéré comme étant
peut-être peu réactif et peu capable de troubleshooting en production, pas la culture de troubleshooting
et la culture de l'urgence opérationnelle. Donc l'opérateur a tendance à dire je suis le seul gardien
de la perte du système en production donc je ne t'autorise pas à toucher le système puisque par
définition tu vas le casser et puis le développeur qui lit d'une autre façon comme je ne peux rien faire
autant que je ne fasse rien parce que je ne le laisse. Donc c'est pour ça que quand je parle
d'introduire l'observabilité, moi ce que j'ai constaté c'est que ça permet d'augmenter la
confiance des deux côtés puisque ça fait monter la culture que des développeurs
et des six admins de côté d'EV et j'encourage fortement des entreprises à mettre les six admins
dans les études d'EV par les architectures logicielles et infra et ce contrat de confiance petit à petit fait
qu'on va impliquer les développeurs de plus en plus dans des incidents. Les opératures vont réaliser
à quel point les développeurs peuvent créer de la valeur dans la résolution d'incidents et en
particulier de détectés plus vite et des réseaux plus vite et vient le moment où on passe en mode
dévose mais c'est vrai qu'il y a une première barrière à franchir qui est cette barrière de
de la confiance. Un des grands artefacts dont je pense qu'il l'aide beaucoup à ça c'est le passage
en container puisque le container c'est une unité de découplage. Il n'est pas que du code c'est du code
déployé, défini sur un os et donc ça amène le développeur à mieux comprendre ce qu'il va
déployer en prod et ça amène l'opérateur à déchire des interfaces plus claires sur
là où les développeurs pourront déployer des containers. Moi j'ai vu la vertu de passer vers
du code containerisé. Les responsables afra peuvent se préoccuper de fournir une afra structure
container ready et donner la main au développeur et confier la responsabilité de leur délivrer
des containers qui sont stables opérationnellement en production. Ça change les équilibres et ça
définit des points d'interface sensibilement plus claires à mon sens que l'accès à une VM comme
tu disais le route access à une VM qui est quand même... Ok donc ce que tu dis c'est que si je
comprends bien ce que tu dis c'est que la containerisation permet de mieux définir le contrat de
collaboration et avec finalement des zones de prérogatives ultra claires et limitées à celles
d'un container en fait. Je dirais que oui ça définit un point, ça formalise le contrat entre
les équipes Afra et Ops et les équipes de Désol. Et pour moi ça a été un accélérateur de
transformation au même titre que l'observe d'habit. Moi j'entends, je suis toujours un petit peu sur
la réserve, sur ces infras hyper sophistiqués parce que justement je trouve que comme tu l'as fait
ce... enfin comme tu l'as remarqué, je vais le redire, comme tu l'as fait remarquer ça augmente la
complexité du système. D'ailleurs les outils doivent s'adapter parce que ça augmente la
complexité et pour moi un système complexe surtout quand il y a de l'humain c'est un système qui
peut vite partir en cacahuète et je trouve que ça a un coup en fait tout simplement derrière. Et
c'est un coup qu'il faut être capable de justifier, pourquoi aller vers ce type de chose. Et ensuite
ça demande une certaine maîtrise parce que je vois des équipes qui partent sur des logiques de
microservice, d'éclater les choses sur des VM et compagnie mais justement sans aucune là pour le
coup logique de visibilité, de monitoring, de solutions globales d'overview et on se retrouve
avec des systèmes qui deviennent juste ingérables et indébugables. Du coup je suis devenu un petit
peu prudent par rapport à ces approches là de les mettre en place vraiment que quand c'était
justifié et vu que je travaille essentiellement avec des startups en phase d'accroche et
démarrage, chez moi ça me paraît rarement justifié. Je sais que tu accompagnes aussi des
grands groupes mais aussi des petites boîtes, des startups. Comment ça se passe ? Qu'est-ce que
tu vois ? C'est quoi l'espécificité des petites boîtes que tu vois toi ? Alors ça c'est
intéressant ce que tu me demandes là. Ce que je observe moi c'est que dès qu'une startup à plus
de 5-7 ans elle a de la dette technique et si elle a le succès escompté elle est en forte
croissance, elle est en hyper scaling et donc elle est confrontée à deux choses et elle a de la
dette technique et en même temps il faut innover, il faut scaleer, il faut grossir et donc on a tendance
à garder ces VM et on reste dans des instances C2 et on va plutôt se préoccuper de développer
la fonctionnalité. Et je pense c'est très bien, c'est-à-dire connaitre on peut aller très très loin
en termes de scaleer son architecture de service sans passer à du Kubernetes, du container etc.
Je suis entièrement d'accord. Ce que je constate souvent c'est que ces sociétés là qui sont très
très fortes sur des architectures un peu plus traditionnelles qui développent beaucoup de
fonctionnalité, elles ont quand même fortement normalisé leur pipeline de dev, elles ont automatisé,
elles ont du immutable infrastructure et des terraformes. Donc elles ont fait quand même un travail
en amont d'automatisation, de formalisation et de scripting de ce qu'elles font. Donc en fait
elles ont éliminé une grande partie de ce que t'y appelle l'humain au sens de la répétabilité
de leur processus de déploiement. Et puis elles vont l'associer en général à une culture DevOps
où elles vont faire des déploiements avec des versions beaucoup plus incrementales donc on va
appeler le blast radius de leur changement est plus petit. On sait ce qui a été changé, il y a
moins de changements dans une nouvelle version. Donc si quelque chose se passe mal en production,
on sait que ce n'est pas dans le déploiement, on sait que c'est vraiment dans la nouvelle version
qu'on va être capable d'isoler ces changements beaucoup plus vite. Donc pour moi il y a deux
muscles à développer en même temps que l'optère. Il y a trois muscles on va dire, il y a de faire des
déploiements plus petits, ce qui fait qu'on comprend mieux où les changements ont lieu,
les faire beaucoup plus fréquemment, mesurer ces déploiements grâce à l'observabilité pour
détecter immédiatement en staging ou en prod qu'on est en train de dégrader la perte business ou
expérience ou technique et puis automatiser automatiser automatiser automatiser automatiser et
automatiser. Ce que je vois moi les meilleurs pratiques c'est que les développeurs qui
utilisent l'observabilité déploient l'observabilité dans leur pipeline de CI-CD. C'est plus les
ops qui déploient du monitoring à posteriori en production. Quand je déploie du code,
ce code il est déjà instrumenté et au moment où il rentre en activité il se met à rapporter
sa télémétrie et je sais en temps réel comment il performe. C'est ce que vraiment je vois les
bonnes pratiques. C'est clair moi c'est quelque chose que surtout sur la stack rails où on déploie
le client qui collecte les données dans la stack donc c'est complètement intégré. Je vais juste
remont dire sur une des choses que t'as dites quand tu vois les startups qui commencent à se
déployer, elles ont en général de la dette technique. J'aimerais juste prévenir les
auditeurs ce n'est pas une fatalité. Tu peux faire en sorte que cette dette n'existe pas mais
effectivement je constate que c'est souvent le cas. Alors je peux faire une barbe là-dessus ?
Que l'observabilité permet d'implémenter qui est vraiment très intéressante qui est la notion
de l'erreur budget, le budget d'erreur. Alors c'est un peu un mystique mais une des grandes
caractéristiques qu'on va utiliser pour mesurer la performance d'un appui type c'est ses golden
signals, DB, latence, tendres-réponses et taux d'erreur. Et en fait on va aussi mesurer des
disponibilités, des taux de reliability et d'erreur et au bout d'un moment on va pouvoir
objectiver dans la conversation le fait qu'on atteint un taux d'erreur trop élevé. On est
en train de dépasser son budget d'erreur. Et moi j'ai aujourd'hui des clients, des sociétés qui,
quand elles dépassent leur budget d'erreur, arrêtent de développer de la fonctionnalité et consacrent
leur sprit suivant à la résortion de la dette technique. Et c'est un contrat qui est passé
avec les études produites. Quand j'ai dépassement le budget d'erreur, j'arrête de développer de la
fonctionnalité, je résume à la dette technique. C'est souvent une discussion qui est très difficile
dans les entreprises. Non non mais on n'a pas le temps de résoudre des problèmes, moi j'ai besoin
de délivrer les nouveaux features que j'ai promis à tes clients, la cette pression permanente du
business. Le fait d'avoir des chiffres, le fait de pouvoir présenter au travers de la télémetrie,
non mais voilà où on en est, voilà notre taux d'erreur, voilà mon temps de réponse, ça permet
d'avoir une conversation une fois de plus, beaucoup plus d'objectifs et d'avoir une étude
produite qui dit ok, je suis d'accord, là, prochain sprint, dette technique. Tu vois c'est là que je
me rends compte que je suis vraiment un extrémiste dans mon approche, mais au sens de l'extrême programming.
Parce que quand tu me parles du budget, d'erreur pour moi, le budget normal c'est zéro en fait et dans
la culture de ce qu'on essaye de construire avec les équipes, on a des outils de reporting qui
nous rapportent des craches. Je ne dis pas qu'il n'y en a jamais, je dis juste qu'on les résout tout
de suite en fait. On ne se pose pas la question de savoir si il faut les résoudre, pas les résoudre,
mais ça encore une fois on revient sur cette idée de ne pas créer de dette parce que en général
c'est la dette et les problèmes dont tu parles, c'est souvent les intérêts de la dette qui en
plus se stacke et se cumule. Mais si jamais tu as une logique où la dette tu en contractes très peu
et quand tu en contractes, tu la rembourse le plus vite possible et que d'aie qu'il y ait une erreur,
tu la résoudes tout de suite, ça évite le phénomène des trains en fait. Tu sais un train peut en cacher
un autre et ensuite dès que tu commences à avoir deux problèmes l'un derrière l'autre, tu ne sais
trop exactement mesurer l'impact et les effets de l'un sur l'autre. Et en fait une politique de
zéro bug, en fait ça marche, c'est redoutablement efficace et c'est un petit peu comme notre couverture
de code. Sur certains projets on a une règle qui est assez simple en fait, c'est 100% point. Et sur
les projets où il n'y a pas 100%, on a une règle qui est interdit de faire baisser la règle,
la couverture de code. Ok, c'est pas 100%, mais un comide ne peut que la faire augmenter.
Alors moi je te rejoins assez, néanmoins ce que je constate si tu es aujourd'hui, c'est que sur
des architectures où tu atteins certaines vélocipés, moi j'ai quand même plein de sociétés que je
vois qui déploient maintenant des dizaines et des centaines de fois par jour et avec dix,
vingt, trente, cinquante, cent équipes d'evobs qui déploient en simultané. La réalité c'est
qu'il y a toute une partie de ce que tu vas pouvoir éliminer en staging, tu vas faire du smoke
testing, tu vas faire des lot testing, tu vas essayer de diminuer tous les risques au moment où
tu introduites ta version. Mais la réalité c'est que ce que je vois de plus en plus, c'est de plus
en plus de sociétés qui valident leur code vraiment en prod. Il n'y a que là qu'ils ont un vrai
fluide trafic, des vrais véritables usages, qu'ils ont tous les micro-services dont ils
dépendent en prod aussi. Et donc il faut être capable de réagir vite et souvent de tolérer
en fait un certain taux d'erreur. Ce que je constate aujourd'hui c'est que dans les
architectures complexes basées en micro-services, on tolère un certain taux d'erreur puisqu'il est
je dirais ambiant au fait qu'il y a de très nombreux micro-services qui collaborent. Et que pour
éliminer, pour passer aux héros-boys, il faudrait qu'on ralentir la machine de release à un point
qui ferait qu'on aurait le temps de le faire. Il n'y en a pas vraiment le temps de le faire.
Donc c'est pour ça que... Tu veux dire que ça, il y a un compromis, donc là quand on parle de bug,
on parle bien de quelque part à un moment donné un utilisateur qui a une expérience dégradée.
Oui, qui va faire que je sais que dans certains conditions, dans mon nouveau module, dans ce
container, dans ce micro-service, j'ai un taux d'erreur Java de 2,2%. Mais derrière ce 2,2%,
il y a juste trop sûr de bien qu'on se comprenne bien. C'est qu'à un moment donné,
j'ai un crash server, j'ai un truc qui fait que l'utilisateur n'est pas servi comme il devrait
au moment où il fait la roquette. Il va se récupérer un HTTP 500. Oui, il va se récupérer
une erreur, une anomalie. Et ça ce que tu dis, c'est qu'aujourd'hui, plusieurs entreprises acceptent
ce compromis de dire que j'accepte un certain taux d'erreur pour pouvoir accélérer et livrer
plus vite le coût de ce taux d'erreur et inférieur à celui de ne pas aller vite.
Voilà. Je peux entendre complètement cette logique-là, c'est qu'on rejoint une logique du
goût des neufs qualités, c'est-à-dire pas faire de la surqualité. Le gros biais que je vois à ça,
c'est que moi, à l'inverse, je vois pas mal. Et encore une fois, j'ai un biais et moi de consulte,
on m'appelle rarement quand tout va bien. Mais c'est du coup de ne pas créer une culture où on
résouse ça. Moi, ce qui m'embête, c'est qu'on commence à laisser traîner ces trucs-là et que
ça sort complètement de la maîtrise. Et on voit des équipes qui, au bout de quelques années,
se retrouvent à passer 40% de leur temps à éteindre des incendies. Et tu vois, comment tu
trouves un comment ? Parce que c'est une pente, je trouve hyper glissante, surtout d'autant plus
glissante que ta complexité augmente, que ton nombre d'intervénents augmente. Donc à un moment donné,
ça part vite hors de contrôle tout ça. C'est là que souvent que je vois ce qu'on aime appeler
maintenant le Site Reliability Engineer, le SRE, qui est cette personne qui a un certain nombre de
impéritifs. Elle peut parler à sera, elle peut parler un peu de code, elle peut parler automatisation
scripting, elle comprend l'observabilité et les maîtris et la télémétrie et elle comprend le
service que les équipes produits cherchent à délivrer aux clients finales et qui vont faciliter
ces arbitrages au sein de la société. C'est elle qui va on sélier la sérieuse souvent qui vont
aider à fixer les budgets d'erreur. Qu'est-ce qu'on est prêt à tolérer en termes de tolérure sur un
pro-service particulier. Et puis, quand ce taux est dépassé, c'est celui qui va avoir l'autorité de
dire, désolé les gars, une prochaine spree d'être technique. Donc il faut des gardiens,
je suis d'accord, on peut pas laisser juste des inscribes en free will de dire bon allez on va
accepter 5% d'erreur, puis peut-être la semaine prochaine, 7, puis allez, donc 15 jours, 9, il faut
savoir fixer des limites et il faut des gens qui sont capables des compétences, des rôles,
il faut être capable de les implémenter, de créer la tension positive, comme on dit.
Les équipes de devs, il faut que ça frotte, je crois que avec grand truc, c'est que moi les équipes,
les sociétés qui aujourd'hui, je vois, performer à très grande vitesse en utilisant la télémétrie,
l'observabilité, les dévoques, ce sont des équipes où ça frotte. Il y a des discours.
C'est-à-dire ça frotte ?
Il y a des conversations musclées tout le temps, ça frotte et on n'a pas peur du conflit,
on s'engueule, on discute, on n'est pas d'accord, parce qu'il faut que ça frotte,
il faut créer cette tension-là pour avancer.
Oui, je suis d'accord sur le fond la manière que tu as de le dire, me gêne parce que je pense
que cette tension peut aussi se résoudre sans frottement justement.
Alors elle passe par le blameless, justement ?
Voilà, elle passe par la culture d'entreprise, l'égolèse, le blameless, tout cet aspect
où on peut résoudre, qui est cette tension, oui, elles sont un transsegment de business,
elles sont saines, d'ailleurs quand mes clients sont frustrés, je leur dis c'est plutôt
sain en fait, que tu sois frustré parce qu'en fait sinon tu serais pas en train de choisir
et tu serais pas en train de prioriser ce qui a le plus de valeur.
Par contre dans la manière de le résoudre, j'aime pas trop l'idée de laisser penser
que la seule manière de résoudre soit au travers d'un conflit, non, on peut simplement
avoir une discussion argumentée.
Non, alors justement, pas du conflit, du frottement, on va pas s'éviter.
Mais tu m'emmènes à un point qui est très intéressant, c'est qu'une façon d'enlever
la friction au sens conflictuel, c'est d'objectiver les conversations par des chiffres.
Et là encore, l'observabilité et la mesure, moi ce que j'ai constaté, c'est moi j'ai
travaillé plein des types où les équipes avaient des opinions sur ce qu'ils avaient
pas.
Ouais, même aussi qui est trop lent.
Ok.
Mais trop lent de combien ?
Bah il est trop lent.
Et finalement, les équipes sont soulagées quand on dit bah on a mesuré, notre temps
de réponse moyen, il est de 2 secondes, notre 95e percentile, il est de 7 secondes.
Et bah ouais, on a fait tourner des scripts synthétiques sur nos compétiteurs et ils
sont à 0,5 secondes.
Qu'est-ce qu'on veut faire ? Et là, ce coup, ça devient une conversation beaucoup
plus simple, les scènes.
Bien sûr.
C'est où on est, on sait où on s'en doute, on devrait être.
Et on est capable d'objectiver, de donner des services level objectives et d'essayer
les atteindre et puis de dire bah du coup, qu'est-ce que ça va prendre ?
Il dit parvenir.
Donc l'observabilité une fois de plus est aussi un vecteur de rendre ces conversations
sur qu'est-ce qui s'est passé, où est-ce qu'on en avait créé les baseline de performance
objectives puisque les chiffres ont tendance à moins mentir ou moins y a refléter la
réalité de mon nom.
Et alors justement, on a mangé la boîte de temps.
Si tu devais donner un conseil à un développeur qui veut se mettre dans ce, qui veut démarrer
sur ce concept d'observabilité et qu'ils y tiennent aujourd'hui, je vais m'intéresser
à ça.
Ça serait quoi pour l'aider ? Qu'est-ce que tu lui conseillerais pour l'aider à mettre
en œuvre et à démarrer sur une stack d'observabilité ?
Alors pour moi, il faut instrumenter et il faut commencer ensuite à regarder tout
de cette télémétrie que l'offrir en termes de compréhension du stack.
Donc j'aurais vraiment tendance à encourager, d'installer ça soit dans sa société, soit
dans un petit payload qu'on a déployé dans le cloud pour s'entraîner dans un sandbox
privé ou d'entreprise, télécharger peut-être ou créer un compte fritier perpétuel chez
l'urélite et puis installer, déployer et comprendre.
Développer ce muscle, c'est un muscle qu'il faut construire, ce muscle de plancher, créer
du code, je l'instrumente, je le mesure et je construis cette compréhension de comment
mon code se comporte sur une affra, sur du middleware, comment il impacte à la fois
le business et les clients.
C'est un muscle à développer et on peut le faire très facilement en commençant par
instrumenter et commencer à jouer avec les données.
Et bien écoute Greg, ça marche.
Merci pour ce conseil qui est assez clair et qui permet de démarrer.
Si les auditeurs veulent en savoir plus sur ce que tu fais, ils peuvent venir où ?
Neuralic.com, créer un compte et puis démarrer.
Ou alors me contacter moi, Gregoris.on, sous-ditine et puis Géouillon.com.
Merci Gregoris d'être venu aujourd'hui.
Merci beaucoup Benoît, à bientôt.
Quant à toi chère auditeur, j'espère que tu as apprécié ce podcast.
Si comme je te l'ai suggéré à quelques reprises dans cet épisode, tu n'as pas envie de créer
de la dette technique ou en tout cas que tu as envie d'être conscient de ce que tu fais
quand tu en crées pour pouvoir la résoudre et la garder sous maîtrise, je t'invite
à venir découvrir le cursus artisan developer.
C'est dans la maison des compagnons sur maison.artisandeveloper.fr.
Et puis avant ça, si tu as envie de faire un diagnostic de tes pratiques pour savoir
où tu en es, sur tes pratiques, comparer ton niveau à celui de centaines d'autres
développeurs, toujours sur ces enjeux de décrire du code durable, je t'invite à venir
faire ton diagnostic de pratiques sur compagnons.artisandeveloper.fr.
À bientôt !