Réduction des coûts et amélioration du monitoring chez IGS

Responsable de l'ingénierie de plateforme chez IGS, ma tâche est d'aider les développeurs à générer de la valeur commerciale avec des outils, une infrastructure et un processus de bout en bout (du lancement à la publication) sans les coûts de maintenance du monitoring et de résolution des erreurs. De par la nature de notre produit – des tours de culture verticale accueillant différentes plantes, il nous faut une fiabilité élevée. En cas de panne de courant, nos cultures peuvent mourir. Comme nous sommes une petite entreprise, nous avons besoin de données sur la fiabilité de notre système, d'autant plus que nous devons nous adapter pour traiter et visualiser de plus grands volumes de données tout en contrôlant nos coûts.

Quand j'ai débuté chez IGS, nous utilisions Application Insights intégré nativement à Microsoft Azure mais également Kubernetes sur lequel nous nous appuyons fortement. Cependant, ce dernier n'était pas bien intégré au vu de la quantité de données que nous recueillons. Au départ, nous avions envisagé des solutions open source. Cette recherche peut cependant devenir chronophage et nous n'avions que trois personnes dans l'équipe qui pouvaient s'en occuper. Nous avons donc fini par examiner différentes solutions SaaS. Un de nos principaux critères était une bonne conformité aux normes ouvertes pour que nous puissions faire à la fois du monitoring, du logging et du tracing. Nous souhaitions également une application compatible avec Kubernetes qui devenait notre outil cible de calcul des temps d'exécution. Plusieurs facteurs nous ont fait choisir New Relic.

L'approche Kubernetes du monitoring

Nous utilisons énormément Kubernetes et sommes impliqués dans la communauté eBPF. New Relic est LA solution complète pour nous grâce à sa compatibilité avec l'open source, comme OpenTelemetry et ses intégrations à Prometheus. C'est l'acquisition de Pixie qui a attiré notre attention. Cet outil permet d'obtenir un monitoring Kubernetes avec une vue des traces axée sur les développeurs. C'est une dimension qui nous faisait défaut pour les données d'application sans que nous le réalisions : un tracing de bout en bout facilement consommé. 

Instrumentation rapide

La phase d'instrumentation s'est révélée particulièrement facile. Nous nous attendions à avoir quelques difficultés pour instrumenter le code manuellement. La bonne surprise, c'est que pour 90 % du travail requis, nous avions juste besoin d'ajouter l'agent APM au conteneur. Tout simplement ! Pour les bibliothèques plus spécialisées, nous avons dû ajouter un peu d'instrumentation personnalisée, sans que cela nous prenne trop de temps. Même chose pour les logs ! New Relic utilise des méthodes relativement courantes pour recueillir les logs dans une langue donnée. Nous nous sommes appuyés sur notre configuration de logging existante mais en y ajoutant une ligne supplémentaire pour New Relic. La plupart de notre domaine a été instrumenté en une journée et demie.

Réduction des coûts et du temps de développement

New Relic a également eu un impact positif significatif sur notre budget et nos dépenses mensuelles. Ces dernières ont baissé de 58 %. Cela nous a permis de libérer de nombreuses ressources qui ont alimenté directement notre proposition de valeur auprès de notre clientèle. Notre délai moyen de résolution (MTTR) a également baissé de 80 %. Nous pouvons identifier ce qu'il s'est passé dans le code et l'impact que cela aura dans le reste du domaine. Nous pouvons effectuer un monitoring proactif pour mieux prévenir tout problème avant qu'il ne se produise. Il nous est possible de visualiser une dégradation des performances ou une augmentation des erreurs qui pourrait indiquer une instabilité sous-jacente. Monitorer de manière évolutive n'est plus un problème. Au lieu d'avoir des personnes en charge du monitoring, nos équipes peuvent se concentrer sur les parties qui apportent de la valeur à notre clientèle et à notre équipe de développement.

Les fonctionnalités passent du code aux clients en quelques jours

Le riche écosystème d'intégration New Relic nous a également permis de rationaliser notre cycle de production. Grâce à Flagger, un outil intégré à New Relic et utilisé comme portail de qualité, nous pouvons implémenter une stratégie de déploiement en anneaux. Le passage d'un anneau à l'autre est décidé par des données de monitoring réelles. Nous pouvons ainsi exploiter l'auto-instrumentation de New Relic grâce aux contrôles d'intégrité par service et aux workloads New Relic. Nous avons donc plus confiance en notre processus de sortie sans avoir à créer des outils personnalisés. Avec cette stratégie de sortie rationalisée, il nous faut 4 jours au lieu de 22 de la première ligne de code à la mise à disposition de la fonctionnalité auprès de la clientèle.

Les logs en contexte

Nous utilisons de multiples environnements qui comprennent de nombreux microservices pour lesquels de nombreux systèmes génèrent des logs. Auparavant, pour examiner les logs, nous les récupérions directement dans le pod. Il n'y avait aucune connexion entre la fonctionnalité, la partie commerciale pour laquelle ce service était utilisé, ce que les développeurs voyaient et ce que le côté infrastructure considérait comme logging : tout était séparé. Nous avions les logs et les traces, ou les logs associés à un service. Rien n'était connecté. Pour aider à la gestion des logs, il fallait se référer à un Wiki interne contenant des centaines de requêtes. Pour chercher des informations, il fallait aller dans le Wiki, trouver la requête correspondante en espérant qu'elle fonctionne. Si ce n'était pas le cas, il fallait essayer de la modifier. Savoir si quelqu'un avait déjà trouvé une solution demandait également un travail assez poussé. 

Notre environnement distribué implique une utilisation conséquente des logs. Avec New Relic, nous tirons parti des logs en contexte. Nous pouvons associer un log à une seule trace et les afficher ensemble dans une seule vue : on voit un service, ce dont il dépend et les logs générés. Dans New Relic, nous pouvons visualiser ce qu'est le service et savoir comment il est connecté au reste de notre domaine, et donc consulter les logs pour ce service dans le contexte de son interaction avec les autres services de notre domaine : c'est sur cette capacité que repose en grande partie notre réussite. Maintenant, nous pouvons afficher la vue de l'application et explorer les logs. Le tout se fait en quelques clics rapides et ça réduit beaucoup la charge cognitive.

Des alertes pour améliorer la productivité

Nous avons personnalisé nos alertes pour qu'elles soient envoyées à notre canal Microsoft Teams. Avec New Relic, il est possible de partager un lien vers une alerte. C'est une fonctionnalité toute simple mais vraiment indispensable. Chaque page comporte un bouton Partager. Par exemple, si nous avons une trace spécifique, il nous suffit de copier le lien qui inclut l'intervalle temporel de la trace et de le partager dans le chat. Avant, il fallait organiser une réunion où une personne devait charger des données spécifiques pour essayer de reproduire sa requête pour la partager avec ses collègues. Maintenant, nous pouvons partager ces données en quelques secondes. 

Terraform pour l'automatisation

New Relic propose également une API enrichie comportant un fournisseur Terraform. Chez IGS, nous avons de nombreux environnements dynamiques. Nous en créons un à chaque changement de code. Comme nous pouvons utiliser Terraform pour créer des dashboards et des vues de workload et pour ajouter les personnalisations ou les alertes nécessaires à un environnement donné, ces alertes sont donc intégrées à la révision du code. Pouvoir utiliser la même technologie dans les mêmes langages a changé la donne. Nous pouvons écrire le code d'infrastructure de la même manière que nous écrivons le reste. Ensuite, nous pouvons le déployer dans les environnements choisis. Nous avons donc un workflow rationalisé à la fois dans l'ingénierie logicielle et sur le site.