Fondée en 2011 à Montpellier, la plateforme de publicité en ligne Teads a connu une croissance rapide. L’infrastructure du groupe est hébergée sur le cloud AWS. En 2016, cette infrastructure comporte deux grandes zones, qui ensemble représentent des milliers de serveurs : une région historique, l’Europe, et l’Amérique du Nord, ouverte ultérieurement, pour laquelle l’infrastructure européenne avait été recopiée. « Cette infrastructure était très centralisée, mais très peu industrialisée », raconte Damien Pacaud, directeur de l’infrastructure, qui venait alors de rejoindre Teads. « Cela se traduisait par une forte hétérogénéité, avec de nombreux problèmes de fautes de frappe, de nommage, d’adressage CIDR… » A l’époque, deux équipes de deux personnes s’occupent de gérer l’infrastructure : l’une travaille sur le pipeline d’intégration et de livraison continue (CI/CD), l’autre sur la plateforme, en majorité AWS mais pas seulement. « Ces deux équipes avaient très peu d’outils en commun, alors qu’elles poursuivaient les mêmes objectifs », précise le directeur de l’infrastructure. 

C’est dans ce contexte que Teads décide d’étendre ses activités à la zone Asie-Pacifique. « Nous nous efforçons d’avoir le moins de latence possible entre nos serveurs et les terminaux des internautes », explique Damien Pacaud. « Pour accompagner le développement sur cette nouvelle zone, il fallait donc ouvrir une nouvelle région sur AWS ». Deux choix se présentent alors pour déployer cette dernière : soit recopier celles existantes, soit repartir de zéro, en investissant dans le socle technique. « Notre priorité était l’industrialisation : plus question d’opérer les changements à la main. Nous avons décidé de profiter du projet pour regrouper les deux équipes et leur faire parler la même langue, en cherchant un outil commun », relate Damien Pacaud. Pour industrialiser la gestion de son infrastructure, cette nouvelle équipe Ops choisit de mettre en œuvre une solution d’infrastructure-as-code sur la nouvelle région, début 2017. Deux grandes options se présentent : CloudFormation, la solution d’Amazon, et Terraform, solution open source de HashiCorp. « Nous avons retenu Terraform car celui-ci pouvait également fonctionner avec d’autres fournisseurs de Cloud », indique Damien Pacaud.

Du peer review pour l’équipe d’infrastructure

La solution Terraform fonctionne en trois grandes étapes. « La première consiste à décrire l’état souhaité pour son infrastructure, sous forme de code : nombre de compartiments de stockage S3, services de load balancing, … », détaille Damien Pacaud. « Des propriétés peuvent être associées à chaque composant ». Le fait d’avoir un fichier de code a permis de mettre en place un processus de peer review (revue du code par les pairs) au sein de l’équipe d’infrastructure. Autre avantage, toute l’infrastructure est documentée, ce qui permet de savoir quels composants interagissent avec quoi. Dans un second temps intervient une étape de planification des mises à jour : « l’outil lit le fichier de code et fait le différentiel avec l’environnement en production, pour proposer ensuite la liste des mutations à appliquer », explique le directeur de l’infrastructure. Enfin, il ne reste plus qu’à demander à l'outil d'appliquer les modifications identifiées. Les Ops voulaient que l’exécution soit centralisée, notamment pour pouvoir auditer les changements. « Pour cela, il fallait éviter que les équipes de développement utilisent directement Terraform depuis leurs postes de travail. Nous avons donc déployé des jobs Terraform dans l’outil d’intégration continue Jenkins », relate Damien Pacaud.

Fin juin 2017, trois mois après le lancement du projet, la nouvelle région est opérationnelle. Cependant, les deux régions historiques représentent encore 98% de l’activité. L’équipe infrastructure réfléchit alors à une manière de migrer ces deux régions en douceur, de façon à ne pas perturber le travail des équipes de développement. « Notre équipe ne pouvait pas effectuer cette migration pour tous les développeurs, qui sont plus d’une centaine dans l’entreprise. Il fallait donc renforcer la collaboration entre les feature teams et les Ops », souligne Damien Pacaud. Pour s’assurer que Terraform est utilisé de façon homogène, l’équipe infrastructure rédige des directives, qui précisent comment écrire du code respectant les exigences propres à Teads. Les Ops forment ensuite quelques développeurs dans chaque feature team. En parallèle, l’équipe migre un composant transversal, afin de disposer d’une marche à suivre précise pour les autres migrations. Ces étapes franchies, les Ops transfèrent alors la responsabilité aux équipes de développement. Pour inciter ces dernières à migrer, l’équipe d’infrastructure intègre des modifications demandées depuis longtemps par les développeurs dans un outil de déploiement réécrit pour l’occasion, et qui ne fonctionne plus qu’avec l’infrastructure Terraform.

Un langage partagé par les Dev et les Ops

Deux ans et demi après ce projet, presque toute l’infrastructure de Teads est « terraformée ». Au total, 80 contributeurs différents sont venus alimenter le référentiel de code de l’infrastructure, alors que les Ops eux-mêmes sont aujourd’hui au nombre de 10. Le pari de la collaboration a donc été tenu, avec 70 collaborateurs en dehors de la production qui ont participé à l’évolution de l’infrastructure. 6000 pull requests ont été soumises, revues puis fusionnées avec le code principal par l’équipe infrastructure, qui conserve le contrôle sur l’ensemble des changements appliqués. Au total, plus de 10 000 mutations ont été effectuées sur les environnements de production depuis la mise en place de la solution. « Ce projet a permis à tous, développeurs et opérations, de parler le même langage, celui de Terraform (HCL) », se réjouit Damien Pacaud en conclusion de sa présentation.