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 ».