Ce que nous avons appris en rendant open source une partie majeure de Mailgun

Il y a quelques semaines, nous avons rendu open source Flanker, notre bibliothèque d’analyse MIME et de validation des emails. Nous sommes très heureux de cette sortie et de l’intérêt porté par la communauté Python. Ce tweet est représentatif de ce que nous avons pu lire depuis la sortie :

Ouvrir le code d’un logiciel peut sembler facile, mais c’est plus complexe que de simplement publier son code sur Github et de s’arrêter là. En fait, nous avons été surpris par certains des défis rencontrés et avons voulu partager quelques retours sur le processus afin d’aider les équipes de développement qui prévoiraient d’ouvrir le code de leurs propres projets. Pour ce faire, voici comment nous avons procédé et ce que nous en avons appris.

Initialement, nous nous étions engagés à ouvrir le code de Guardpost, notre validateur d’adresse email. Lorsque nous nous sommes lancés, nous avons vite compris qu’il serait bien plus pertinent de l’intégrer à notre bibliothèque d’analyse MIME et de publier l’ensemble sous le nom de Flanker. Cela a entraîné des complications supplémentaires, car nous rendions open source une part assez importante du code de base de Mailgun.

Flanker n’ayant pas été conçu à l’origine pour être utilisé par d’autres personnes, cela a été un vrai défi de s’assurer que toutes les dépendances au code propriétaire étaient supprimées. Nous ne voulions pas imposer l’utilisation de technologies spécifiques à d’autres utilisateurs, nous avons donc rendu plus modulaires les parties de Flanker qui utilisaient des modules Python spécifiques ou des bases de données comme Redis et dnspython. Désormais, vous pouvez utiliser n’importe quelle base de données (ou aucune) pour mettre vos résultats en cache.

Cela signifiait qu’il nous fallait d’abord extraire le code et nous assurer qu’il était utilisable par d’autres, puis réintégrer efficacement Flanker dans Mailgun sous sa nouvelle forme. Nous avons également profité de cette occasion pour remanier de grandes parties de l’analyseur d’adresses (voir le point 5. ci-dessous), ce qui a rendu les choses plus difficiles.

Nous aurions pu simplement créer un fork de notre base de code interne de Flanker, faire de notre mieux pour supprimer les dépendances, et continuer à utiliser ce qui fonctionnait déjà en interne. Mais nous nous serions alors retrouvés soit à négliger le code open source, soit à maintenir deux bases de code distinctes. Au lieu de cela, nous avons décidé de nous engager à continuer d’utiliser le code open source en production.

Cela signifie que lorsque nous fusionnons une pull request (nous en avons traité huit depuis l’ouverture du code de Flanker il y a quelques semaines, et quatre autres sont en attente), nous devons non seulement nous assurer que le code est propre, maintenable et optimisé pour les performances, mais également que toutes les modifications s’intègrent parfaitement au reste de Mailgun.

Comme vous pouvez vous en douter, l’analyse des adresses et l’analyse MIME sont au cœur de Mailgun. Étant donné que nous avions apporté des modifications majeures au processus d’ouverture du code, nous devions être extrêmement prudents lors de la réintégration du code open source dans Mailgun, afin de ne pas perturber les applications de notre clientèle. Ce n’est peut-être pas aussi impressionnant, mais cela ressemblait un peu à faire le grand écart entre deux semi-remorques en marche arrière.

Nous y sommes parvenus en déployant Flanker par étapes. Tout d’abord, nous avons commencé par déployer Flanker sur une petite partie de notre trafic. Cela nous a permis de commencer à observer des situations où le comportement du nouvel analyseur d’adresses était plus strict qu’auparavant. Pour certains éléments, comme l’autorisation des caractères de contrôle dans les noms d’affichage, nous avons décidé de les interdire en raison des risques de sécurité que cela implique. Pour d’autres éléments, comme le support Unicode, nous avons choisi d’être aussi flexibles que possible quant à ce que nous acceptions. Oui, cela signifie que vous pouvez désormais envoyer l’émoji crotte comme nom d’affichage via Mailgun, et nous l’encoderons correctement avant de le transmettre.

Nous avons également pensé qu’il serait judicieux de vérifier si nous pouvions le rendre open source sans nous faire licencier. Flanker est l’un des éléments fondamentaux de Mailgun, il est donc très précieux pour Rackspace. Même si nous pensons qu’il est parfois préférable de demander pardon plutôt qu’une autorisation pour faire avancer les choses, ce n’était probablement pas le cas cette fois-ci. Nous avons donc consulté les équipes juridiques et produit de Rackspace pour nous assurer de leur accord. Heureusement, le slogan de Rackspace est « l’entreprise du cloud ouvert » et elle s’investit dans les logiciels open source, il n’a donc pas été difficile de convaincre les équipes de Rackspace que l’ouverture du code de Flanker était la bonne décision à prendre.

Nous utilisions notre analyseur MIME en production depuis longtemps, mais la partie de validation des emails (Guardpost) était relativement récente. Nous avons lancé Guardpost en tant qu’API avant d’ouvrir le code de Flanker. Cela nous a permis de tester efficacement en conditions réelles avant de passer en open source.

À mesure que Guardpost gagnait en popularité, même si nous l’exécutions sur une machine dédiée assez puissante, il peinait à gérer le trafic qu’il recevait. Nous avons donc passé du temps à analyser les performances de Guardpost pour trouver la cause de ces ralentissements, et il s’est avéré qu’il s’agissait du correcteur orthographique. Nous avons consacré du temps à chercher comment l’améliorer, et avons fini par le réécrire complètement. Vous pouvez consulter notre article de blog sur comment nous avons réussi à rendre le correcteur orthographique 135 fois plus rapide qu’auparavant.

Nous avons également pu corriger un bon nombre de bugs signalés par les personnes qui l’utilisaient. Cela allait de l’ajout du support d’Internet Explorer pour la démo de notre validateur (personne dans l’équipe n’avait de machine Windows, nous avons dû obtenir une licence Windows pour corriger ce bug !) à l’envoi d’emails directement vers un domaine de premier niveau (TLD).

Le fait d’exécuter le code en production avant de l’ouvrir nous a permis d’être fiers et d’avoir confiance dans le code que nous allions publier.

C’est une étape importante. Lorsque vous travaillez sur une base de code interne, vous pouvez aller voir la personne qui l’a écrite pour lui poser une question rapide. Ce n’est pas le cas pour les logiciels open source. Nous voulions donc nous assurer que Flanker était bien documenté, afin qu’il soit facile pour de nouvelles personnes de commencer à y contribuer. Cela signifie que Flanker est bien documenté à l’intérieur même du code avec des commentaires, ainsi qu’avec une documentation externe comme une Guide de démarrage rapide, Manuel d’utilisation, et référence API.

Voilà donc ce que nous avons appris en ouvrant le code de Flanker. Bien que cela ait représenté beaucoup de travail, ce fut un processus libérateur et nous avons hâte d’en récolter les fruits à l’avenir.

Nous serions ravis de connaître vos retours d’expérience dans les commentaires de cet article ou sur HackerNews.

L’équipe Mailgun

Auteur·trice: The Sinch Mailgun team The Sinch Mailgun team shares news, best practices, and strategies to take your products and apps to the next level using email. Subscribe to our newsletter to get all the articles in your inbox!