Lors de son événement Dash 2022, le spécialiste de la supervision a dévoilé les nouveautés qui compléteront sa plateforme. Datadog se concentre entre autres sur l’approche FinOps et sur les tests d’intégration en continu.
Après un an de bêta, Datadog annonce la disponibilité générale de Cloud Cost Management (CCM).
Ce service rattaché à sa plateforme de monitoring vise plus particulièrement les product owners, les équipes FinOps et les SRE « sensibles aux coûts » selon Renaud Boutet, Senior vice-président of Product Management chez Datadog.
Au lancement, CCM couvre une grande partie des actifs présents dans AWS, un des grands partenaires de Datadog et son propre fournisseur cloud. Plus tard, au cours de l’année 2023, l’éditeur étendra cette couverture à Azure et GCP.
Comme beaucoup d’éditeurs, Datadog est le premier utilisateur de son produit. « Nous avons d’abord dû régler une problématique de labélisation », indique Renaud Boutet.
Pour cela, l’éditeur s’est appuyé sur les avancées de son produit Infrastructure Monitoring. « Nous avions déjà automatisé l’identification des instances de stockages, des clusters Kubernetes, et tout un ensemble de ressources cloud », rappelle le responsable.
Adapter les préceptes du monitoring à la gestion des dépenses cloud
Il s’agissait d’étiqueter des services afin de lier les données au bon prix, mais aussi de relier les ressources entre elles pour estimer la consommation des applications.
CCM remonte directement les coûts des services exprimés en dollars. Ces dépenses peuvent être attribuées à des applications et à des équipes.
« Il est aussi possible de filtrer les dépenses avec ou sans taxes, les crédits obtenus, etc. », ajoute Renaud Boutet. « Ce n’est pas courant de voir ce type d’informations financières dans Datadog ».
CCM permet d’identifier les prix des services AWS, mais également les prix négociés par les clients dans le cadre de leur contrat annuel ou pluriannuel.
Un tableau de bord affiche les dépenses totales mensuelles et facilite la comparaison au mois précédent ou à l’année précédente. La traçabilité des ressources est, elle, effectuée en presque temps réel, « pratiquement à la minute près ».
« De manière générale, les différentes vues visent à guider un peu plus l’utilisateur. »
Renaud BoutetSenior vice-président of Product Management, Datadog
« Cela permet d’être informé lors de pics de consommation », indique Renaud Boutet. « De manière générale, les différentes vues visent à guider un peu plus l’utilisateur. Au lancement de la bêta privée, il s’agissait avant tout d’un outil pour explorer les centres de coûts ».
Une autre vue permet de détailler les services AWS les plus consommés et donc les plus coûteux. Dans la démonstration effectuée auprès du MagIT, l’application surveillée consommait principalement des ressources EC2.
Il est également possible d’identifier les équipes qui dépensent le plus de ressources cloud. « Les ressources sont automatiquement associées aux équipes qui les consomment ».
Pour l’instant, point d’alertes proactives. Les entreprises qui utilisent les services peuvent manuellement mettre en place des notifications en cas de dépassement.
Il n’y a pas non plus de vues prévisionnelles des dépenses. Cela arrivera plus tard avec l’intégration de Watchdog, anticipe Renaud Boutet.
« Il y a un ensemble d’indicateurs qui permet de notifier les équipes qui surconsomment », précise-t-il. « En outre, dans Watchdog, nous avons déjà développé des prévisionnels pour la consommation de ressources de calcul et de stockage. Ils seront aisément adaptables ».
Cloud Cost Monagement donne par ailleurs accès à des notebooks permettant aux équipes responsables de la supervision des coûts de collaborer sur certaines métriques ou indicateurs.
« La fonctionnalité notebook est déjà très utilisée pour rédiger des postmortems », avance Renaud Boutet. « Il est possible de commenter des analyses financières afin qu’une équipe FinOps interroge des développeurs ».
Une fonction d’exploration doit permettre de filtrer les données des tags afin de pousser l’analyse proposée par défaut dans l’outil.
Enfin, en bêta, une interface en glisser-déposer doit permettre de regrouper ces étiquettes en fonction des équipes FinOps.
Plus tard, service catalog intégrera une vue consacrée à CCM. « De cette manière, la problématique de gestion de coût sera associée au management des services ».
Dans un communiqué de presse, Datadog met en avant un seul retour d’expérience, celui de Stitch Fix, une startup américaine qui propose un service de stylisme personnalisé en ligne.
« Datadog Cloud Cost Management nous a aidés à attribuer les dépenses à un niveau granulaire sur des dizaines de comptes pour réaliser des économies importantes », affirme Martin Amps, ingénieur principal chez Stitch Fix.
« Il nous a également permis de rapprocher les données relatives aux coûts des mesures opérationnelles dans un environnement familier pour nos équipes d’ingénieurs afin de surveiller les coûts dans le cadre de la santé globale du service ».
Datadog s’attaque aux tests d’intégration en continu
Un autre axe de développement pour Datadog touche aux tests en continu.
Selon Renaud Boutet, le produit intéressera les développeurs front-end ou full stack, les responsables qualité, et les bussines owners.
En disponibilité générale, le service Continuous Testing doit aider à automatiser les tests d’intégration de bout en bout. Le service compatible avec les orchestrateurs CI est câblé pour le test d’application Web et mobile. Il est compatible avec GitHub Actions, Azure DevOps, Circle CI et Jenkins.
« Continuous Testing vise à tester l’interface ainsi que les processus critiques d’une application », explique Renaud Boutet.
L’outil permet de tester une séquence d’appels API, par exemple pour vérifier que des utilisateurs arrivent à se connecter à une application. Une séquence peut contenir jusqu’à 25 étapes. Un seul test incluant 50 étapes compte pour deux.
Continuous Testing a été développée sur les fondations d’un équivalent de Selenium, un enregistreur Web. Au lieu de créer des scripts, les utilisateurs peuvent renseigner en mode no-code une fiche interprétée comme un test synthétique d’un navigateur. Une fois validée, la fiche permet de lancer des tests sur plusieurs navigateurs Web et d’enregistrer les tests. Ces tests peuvent être appelés depuis les orchestrateurs CI et être exécutés en parallèle.
L’éditeur mise également sur une fonctionnalité de « réparation » automatique des tests.
« Les tests suivent automatiquement les modifications de l’interface utilisateur d’une application et s’adaptent aux changements sans intervention humaine », promet la documentation de Datadog.
« C’est une couverture du cycle DevOps. Nous commençons à “Shift Left”. Mais pour nos utilisateurs c’est un développement naturel, puisqu’ils retrouvent les données de tests et de supervision au même endroit. »
Renaud BoutetSenior vice-président of Product Management, Datadog
Les tests peuvent être lancés en développement ou en production. Si l’utilisateur emploie la plupart des fonctionnalités de la plateforme Datadog, il peut corréler traces, métriques, logs depuis l’interface de Datadog APM.
« C’est une couverture du cycle DevOps. Nous commençons à “Shift Left” », déclare Renaud Boutet. « Mais pour nos utilisateurs c’est un développement naturel, puisqu’ils retrouvent les données de tests et de supervision au même endroit. De plus, nous pouvons indiquer une cause profonde à l’échec d’un test ».
Plus tard, Datadog prévoit d’améliorer son support des tests d’applications mobiles. Une bêta privée donne déjà accès à des fermes de smartphones physiques. « Échouer à faire un déploiement dans un app store est beaucoup plus douloureux, il faut souvent attendre deux semaines avant de redéployer », affirme Renaud Boutet.
En bêta privée, Datadog annonce une solution d’instrumentation dynamique. « Nous sommes capables de pointer vers une portion de code source et obtenir un snapshot (un ensemble de logs) d’un élément dans un environnement en production », présente Renaud Boutet. « Cela va aussi permettre de réduire la remontée de logs ».
Enfin, une bêta privée est consacrée à la supervision des flux Apache Kafka et des files de messages RabbitMQ. Le marché serait encore très jeune, voire « non existant », selon Renaud Boutet.
« Nous nous rendons compte qu’il y a une opportunité de lancer un produit quand plusieurs clients font un usage détourné de nos outils », explique-t-il. « Nous avons vu nos clients utiliser nos outils APM pour tenter de tracer des flux asynchrones. Or l’APM est pensé pour suivre des flux HTTP. Plus de 80 clients nous ont demandé un tel service ».
Pour approfondir sur Administration et supervision du Cloud
