Loïc Doubinine | Zed

Développeur, Architecte, DevOps et Site Reliability Engineer

Avatar
  • Qui suis-je ?
  • Socials
  • Blog
  • Carrière et formation
  • Parcours académique
  • Deezer

    Since 2016 Développeur - Architecte Logiciel - DevOps - Site Reliability Engineer (SRE) - Lead d'équipe - Formateur

    Je suis arrivé chez Deezer pour commencer une refonte technique transverse. D’abord sur les environnements PHP, puis plus généralement sur une migration d’un monolithe vers une architecture orientée service (SOA).

    J’ai amené et promu des pratiques de développement moderne avec les concepts d’Intégration Continue, Déploiement/Delivery Continu, de tests automatisés et des architectures de code modulaires et adaptées au virage SOA.

    J’ai aussi participé à la mise en place de Kubernetes, à l’observabilité des services et à la construction des outils nécessaires à l’autonomisation des équipes.

    J’ai accompagné les équipes dans la construction de nouveaux projets et dans la migration des anciens vers les nouvelles pratiques.

    Enfin, j’ai construit une API GraphQL en TypeScript avec NodeJS pour remplacer les anciennes API de Deezer. J’ai aussi étudié de très près la performance et la scalabilité de cette API.

    Refonte SOA & Industrialisation

    Amélioration des pratiques de développement pour inclure plus de tests et d’industrialisation, et construction de nouveaux projets plus modernes.

    Migration d’un monolithe vers une architecture orientée service (SOA)

    Je suis arrivé à Deezer pour participer et mener une refonte technique de fond. J’étais acteur et architecte sur quelques solutions techniques et j’ai aussi apporté des pratiques de développement et de qualité modernes.

    La partie code, en PHP, était déjà bien en place, mais avait quelques années de retard sur les standards de l’industrie. Ces retards avaient des implications néfastes sur la qualité des livraisons et leur vitesse.

    J’ai donc construit des projets de migration pour apporter à la fois des pratiques de code modernes, mais aussi des outils modernes. L’objectif était de passer d’un code monolithique déployé et validé presque à la main, par une seule personne, vers un code plus modulaire et orienté service déployé automatiquement ou en autonomie par les développeurs.

    Avec le soutien de collègues nouvellement arrivés et d’autres déjà présents, nous avons permis à la fois de moderniser le code, mais aussi de construire de nouveaux projets sur des bases résolument modernes, et d’intégrer les deux ensemble. J’ai construit et conçu toute l’architecture des nouveaux projets, ainsi que leurs connexions aux anciens.

    API GraphQL

    Création d’une API GraphQL en TypeScript pour remplacer les anciennes API de Deezer. Cette API remplace un ensemble hétérogène d’API REST et permet de simplifier le développement de nouvelles fonctionnalités sur l’ensemble des applications Deezer.

    Un grand travail de réflexion et de dialogue produit a été fait pour construire cette API.

    J’ai construit la base d’une API GraphQL pour remplacer l’ensemble hétérogène des API de Deezer. J’ai aussi participé aux premières migrations d’endpoints REST vers le Graph de la nouvelle API. Ce projet m’a permis d’apprendre et maîtriser TypeScript, et de comprendre le fonctionnement de NodeJS en profondeur.

    Pendant la première phase d’implémentation, j’ai fait beaucoup d’archéologie et beaucoup de discussions ont eu lieu avec l’ensemble de l’équipe, en incluant des personnes responsables du produit. Cela a permis de construire une API, et notamment un Graph pertinent. Au-delà du rôle d’architecte et développeur backend, j’ai aussi fait la gestion de projet et la coordination.

    Beaucoup de travail a été fait sur la performance et la scalabilité de l’API, et j’ai mis en place des outils tels que Gatling pour les tests de performance. Ce projet m’a aussi permis de comprendre les limites de NodeJS et de GraphQL tout en tirant parti de leurs avantages.

    Ce projet a été un succès. Il a été conçu pour que l’ensemble des développeurs des équipes puisse y contribuer, bien qu’ils soient majoritairement des développeurs PHP. Les équipes sont maintenant autonomes pour contribuer et faire évoluer cette API.

    Docker

    Dès que c’était possible et utile, utilisation de Docker pour changer le paradigme de livraison d’une livraison de code vers une livraison d’image réutilisable.

    Utilisation de Docker très tôt pour certains environnements de développement.

    Dans la foulée des migrations et des nouveaux projets, création d’une nouvelle stack de développement basée sur Docker. Principalement orientée développement backend, elle permettait de porter sur les postes des développeurs la majorité des outils nécessaires au développement et à l’exécution des tests automatiques. Cela a permis de démocratiser davantage la pratique du testing automatisé et du TDD.

    Docker est devenu peu à peu la norme de livraison pour les nouveaux projets. Kubernetes est arrivé peu après pour permettre de déployer ces images en production.

    Kubernetes

    Mise en place de Kubernetes pour permettre aux équipes de déployer et de maintenir leur service en autonomie.

    Une fois que les équipes infrastructures ont pu nous fournir un cluster Kubernetes, j’ai participé à la migration des services vers ce cluster. J’ai également créé et mis en place plusieurs outils et processus pour faciliter la vie des développeurs et des opérationnels.

    J’ai accompagné les équipes dans la mise en place de leurs services sur Kubernetes, et les ai aidées à s’approprier les nouveaux outils et technologies liés à Kubernetes, tels que Helm et ArgoCD.

    Divers projets

    Pendant mon temps chez Deezer, j’ai aussi participé à de nombreux autres projets, en PHP, en GO, parfois même en Python. J’ai utilisé tous ces cas d’usage pour promouvoir les pratiques SRE et renforcer les propositions techniques que nous avions à offrir aux équipes, comme les templates de projet et l’amélioration des outils CI/CD.