Mon expérience de DevOps Engineer, Product Owner chez Scaleway de janvier 2018 à avril 2019

J’ai été pendant 10 mois leader d’une petite équipe de trois personnes (Alexandre, Albert et moi) dont le but était de développer un nouveau produit IaaS de type baremetal-server as service".

Ce projet était assez technique, plutôt “bas niveau”. Mon expérience en administration système du début des années 2000 chez LinBox, mes lectures des Linux Magazine et linuxfr m’ont été très utiles.

Concrètement, une application CLI permettait de gérer tout le cycle de vie — create, login, restart, debug, destroy… — de serveurs préalablement provisionnés et configurés en datacenter.
Cette application CLI communiquait avec un serveur central via le protocole gRPC/Protobuf.
Ces deux composants étaient développés en langage Go, avec des librairies du type gRPC, GenProto, SQLx, Cobra/Viper, Logrus, Migrate… (ce projet date de 2018, ces librairies ne sont peut-être plus pertinentes), la persistance était assurée par une base de données PostgreSQL et Minio pour le stockage des images disques.

Les technologies suivantes étaient utilisées pour piloter à distance les serveurs : DHCP server, iPXE, TFTP, IPMI.

Les différentes images des systèmes d’exploitation étaient préparées avec Packer pour fournir une expérience la plus proche de celle de l’utilisation des serveurs virtuels.

Le projet était testé presque entièrement avec Vagrant, Mock IPMI with Virtualbox et quelques conteneurs Docker. Le projet était entièrement déployé en infrastructure as code, avec Ansible et quelques scripts Bash.

L’enseignement majeur que j’ai pu tirer de cette expérience est la méthode de travail en équipe que nous avons réussi à mettre en place.
Au départ, l’inspiration m’est venue de mes observations du fonctionnement interne de chez GitLab, visible à travers leur Handbook.
Cette méthode s’est matérialisée par un environnement de développement de qualité, un concept que je nomme “Development Kit”, et par des pratiques telles que le “Readme Driven Development”, toute action de plus de 10 minutes commencent toujours par une issue ou une merge request, une étape de code review pour chaque Merge Request, effectuée par une personne ou plus quand le changement était impactant.

Cette méthode a eu entre autres les effets suivants : les contributions sur le projet étaient équilibrées — nous n’étions pas dans la situation où un développeur faisait 80% du travail —, très faible bus factor sur le projet, fort sentiment de possession du projet par tous les membres de l’équipe.

Je pense qu’encore maintenant, Albert et Alexandre gardent un agréable souvenir de travail sur ce projet.

Par la suite, j’ai essayé en tant que CTO chez Spacefill de construire une équipe en me basant sur cette expérience positive.

Les 6 mois suivants, j’ai rejoint l’équipe qui travaillait sur le produit “Kubernetes as a Service”.
Kubernetes n’était pas nouveau pour moi, parce que j’avais travaillé sur cette technologie presque à plein temps pendant 2 ans, de 2016 à 2018 chez Tech-Angels.

Ce projet avait dépassé la phase de “prototypage”, il fonctionnait et à mon arrivée, l’objectif était de finir toutes les tâches nécessaires pour le mettre en les mains des clients finaux.

Le déploiement de ce projet complexe — par nécessité — était entièrement automatisé via les outils Terraform et Ansible.

Ce projet était développé en Go et utilisait PostgreSQL.