Quentin L.

Je contribue à la refonte du système de facturation au sein d’une BU de 90 personnes dédiée au parcours Order-to-Cash. J’assure la conception, le développement et la maintenance de 4 microservices interconnectés, en Go, déployés avec Helm sur Kubernetes, orchestrés via des workflows événementiels Temporal.

Ces services traitent quotidiennement des dizaines de milliers d’événements de facturation, participant à la modernisation d’un module critique historiquement âgé de 10 à 20 ans.

J’ai intégré une équipe passée de 5 à 12 développeurs (+2 lead dev), avec des rituels agiles hebdomadaires (grooming, affinage, revues de code rigoureuses).

Mon rôle implique aussi une forte collaboration inter-équipes pour assurer la cohérence fonctionnelle et technique dans un projet transverse, clef pour la réduction de la dette technique et la fiabilisation de la chaîne de facturation.

» Développement de l'outil interne "Turbine". Turbine est un outil de déploiement d'applications conteneurisées intégré au service d'information d'ADEO SERVICES intégrant diverses fonctionnalités :

- "scale to zero" programmé

- haute disponibilité

- surveillance et alertes basée sur DataDog

- gestion des secrets basée sur Vault

- basé sur Kubernetes GKE

- facturation

- déploiement automatique via CLI ou GitHub Actions

- gestion en micro-service entièrement développé en Golang

» Support avec astreinte sur l'outil Turbine.

» Mission conjointe avec l'équipe en charge de GKE au sein d'ADEO SERVICES

Au sein d’une équipe de 15 personnes pour le produit « Managed Kubernetes Service », j’ai développé en Go pour créer et/ou améliorer les opérateurs Kubernetes responsables de la bonne livraison des services type LoadBalancer au sein des clusters des clients, tout cela dans un environnement multi-région OpenStack.

Il s’agit de comprendre le fonctionnement de Kubernetes, comprendre comment développer en son sein, comprendre les boucles de réconciliations, créer des objets personnalisés et les rendre « scalable » pour un volume de plusieurs milliers d’objets, le tout avec un seul et unique opérateur.

---

1. Étude sur l’existant et maintien en condition opérationnelle de l’opérateur Kubernetes multi-région permettant la livraison des load-balancers clients au sein de leur cluster Kubernetes managé (environ 3000 load-balancers répartis sur 5000 clusters Kubernetes). Faire face à ces problématiques de volumes pouvant ralentir le processus de livraison et diminuer sa fiabilité. Aujourd’hui, nous sommes capables de livrer un load-balancer dans chaque région sous la minute. Il s’agit d’un opérateur Kubernetes (étroitement lié à une API elle aussi développée en Go) développé à base de Kubebuider, proposant une implémentation complétement « custom » du service type LoadBalancer.

2. Étude pour la refonte du produit « Loadbalancer » pour proposer le load-balancer Octavia fourni avec Openstack plutôt que l’implémentation personnalisée.

Pour cela, on est parti de l’implémentation OpenStack cloud-provider-openstack et développement de ce dernier pour intégration au sein du produit Managed Kubernetes Service. Les 2 produits load-balancer (les 2 contrôleurs) fonctionnant en parallèle (2 cloud-controller-manager déployés dans les clusters clients). Plus tard, le LB Octavia sera livré par défaut puis décommissionnement de l’infrastructure « legacy ».