Pourquoi Malt a migré de l’open source au monitoring basé sur une solution SaaS

Hugo Lassiège, cofondateur et directeur technique de Malt, une marketplace en pleine expansion, qui compte plus de 500 000 utilisateurs et met en relation 150 000 travailleurs indépendants férus de numérique avec 30 000 entreprises clientes dans toute l’Europe, nous livre son retour d’expérience. Il compte plus de 20 ans d’expérience en informatique, notamment en tant que développeur, ingénieur AQ, chef de projet, architecte et coach en méthode agile.

La création d’une excellente expérience de développement est un impératif stratégique pour les entreprises afin d’attirer et de retenir les talents, de stimuler la productivité et, en fin de compte, de lancer des produits numériques haut de gamme.

Lorsque je pense à l’expérience des développeurs, deux éléments essentiels me viennent à l’esprit : (1) la rapidité avec laquelle les nouveaux membres de l’équipe sont en mesure de commencer à apporter une valeur ajoutée dès leur premier jour dans l’entreprise et (2) la suppression des difficultés pour tous les membres de l’équipe (qu’ils soient nouveaux ou expérimentés). Étant donné le développement rapide de Malt en Europe (nous opérons actuellement dans trois pays), nous investissons massivement dans l’expérience des développeurs en tant que levier essentiel au développement de notre équipe.

Deux domaines de l’expérience des développeurs nous ont particulièrement intéressés : la vitesse de déploiement et le monitoring des performances. Nous avons fait de grands progrès dans ces deux domaines et je crois que nous avons presque résolu tous les problèmes liés au dernier. Dans cet article, je vais retracer notre parcours afin d’améliorer considérablement le monitoring des performances et expliquer en quoi ces progrès aident notre équipe à se développer.

2013-2019 : solutions open source

Après la création de Malt en 2013, nous avons essayé pendant six ans pratiquement tous les outils de monitoring open source imaginables : Telegraf, Jaeger, Grafana, la liste est longue. L’équipe voulait créer une solution de monitoring open source qui aurait toutes les capacités d’une solution commerciale sans aucun des coûts qui y sont associés. Il s’agit d’une stratégie compréhensible de la part de notre équipe d’ingénieurs au service d’une start up aux budgets limités. Cependant, nous nous sommes finalement rendu compte que ce point de vue était naïf. À chaque étape du processus, nos solutions open source ont généré de la complexité et des coûts :

• Configuration

Chaque outil open source que nous avons essayé avait ses bons côtés. Mais le problème était la fragmentation de la solution, la complexité qu’elle engendrait et le temps nécessaire pour la mettre en place et la maintenir. Les outils open source ont des langages de requête, des interfaces et des méthodes différentes pour ingérer les données, et les membres de l’équipe doivent connaître chacun d’entre eux s’ils veulent créer des tableaux de bord fonctionnels et des alertes significatives. Cela prend énormément de temps et il est très difficile de faire les choses correctement.

• Alertes

Une fois les outils configurés, il reste à savoir si les développeurs en tirent réellement parti. Dans notre cas, nous avons constaté que les outils open source généraient beaucoup de données parasites. En raison de la fragmentation de la solution en plusieurs outils open source, chaque outil envoyait des alertes par e-mail ou sur Slack, et il n’était pas évident de savoir s’il y avait un réel problème, ni quel était le problème. (Et souvent, les données parasites étaient dues à une mauvaise configuration d’un outil de monitoring.)

• Gestion des incidents

A leur tour, les développeurs ont simplement cessé d’utiliser les outils, ce qui a créé une mauvaise dynamique. Ils ont demandé à leurs collègues chargés des opérations de traduire et d’interpréter les alertes et de les informer s’il y avait un problème important. Cette approche n’était pas efficace. Nous avions recréé par inadvertance la division classique selon laquelle les développeurs déploient le code et laissent simplement aux équipes opérationnelles le soin de s’inquiéter des problèmes qu’il peut causer.

• Maintenance

Enfin, il est important de mentionner que l’open source n’est pas gratuit. La gestion des serveurs et la maintenance de chaque outil nécessitent beaucoup de temps et d’argent. En tant qu’équipe, nous avons progressivement commencé à changer notre mentalité concernant notre stratégie de monitoring.

Première tentative avec une solution commerciale

Je dois mentionner que nous avons essayé une solution commerciale à un moment donné, mais cela a été de courte durée. À l’époque, le modèle de tarification par host et non par nœud de conteneurs n’était pas adapté à l’infrastructure cloud car trop couteux. Ce mauvais départ avec une solution de monitoring commerciale a renforcé notre désir de construire notre propre solution open source « gratuite ».

2019 : Mise en œuvre

En 2019, notre mentalité avait complètement changé : nous avons identifié les coûts cachés, la complexité et l’inefficacité de nos solutions de monitoring open source et avons voulu acheter une solution SaaS qui centralise tout. Nous voulions surtout que la solution soit efficace pour la gestion des logs, qui nous posait particulièrement problème. Nous avons essayé de nombreux outils de gestion de logs, mais nous avons à chaque fois constaté que lorsque nous avions un incident, il était très difficile de trouver les bons logs.

A cette époque, nous avons essayé trois plateformes de monitoring SaaS différentes et avons choisi d’investir dans Datadog, particulièrement utile pour résoudre notre problème de gestion de logs, où nous avions le plus de difficultés.

Aujourd’hui : une plateforme unique et centralisée

Aujourd’hui, Datadog est notre principal outil de monitoring. Il est très intuitif, ce qui signifie que chacun de nos ingénieurs peut l’utiliser et apprendre à s’en servir assez rapidement. Cet aspect est vraiment très important pour nous, car cela permet de diffuser rapidement les connaissances à toute l’équipe, ce qui est nécessaire à son progression. A propos du déploiement et du monitoring, les deux points clés de l’expérience des développeurs décrits ci-dessus, il est très inefficace d’avoir une situation où seules certaines personnes savent comment faire les choses. En éliminant les points de défaillance uniques et en permettant à n’importe quel membre de l’équipe d’effectuer le déploiement et le monitoring, nous augmentons le rythme auquel notre équipe peut se développer.

Étapes suivantes

Je suis fier que nous ayons résolu nos problèmes de monitoring des performances et que nous ayons amélioré l’expérience des développeurs au cours des deux dernières années. Je vois un schéma similaire se produire avec nos outils et processus de sécurité : un ensemble d’outils très fragmenté qui conduit à des processus inefficaces et à des cloisonnements entre les équipes. Datadog a lancé le monitoring de sécurité, qui est une extension logique de la plateforme. J’ai hâte d’explorer cela au cours de cette année. Nous sommes arrivés à l’étape DevOps, mais je vois le potentiel d’arriver à l’étape DevSecOps cette année.

Grâce à un monitoring centralisé et intuitif, nos développeurs sont désormais autonomes. Ils n’ont pas besoin de demander l’aide des opérations chaque fois qu’il y a un problème. Cela a permis d’améliorer considérablement nos temps de résolution des incidents et d’accroître la collaboration et la productivité. L’expertise en matière de monitoring de notre environnement ne se limite pas à une seule équipe ou à un petit groupe d’individus, mais s’étend rapidement à toute l’équipe. Cet aspect est très important pour nos activités, car nous nous étendons dans toute l’Europe