Observability as code : Dynatrace veut donner les rênes aux développeurs
Dynatrace a étendu ses outils d’« observability as code » pour permettre aux développeurs et aux ingénieurs DevOps de déterminer comment les services en production retournent des informations via une interface en libre-service. Reste à convaincre les développeurs réfractaires.
Les utilisateurs de Dynatrace ont pu découvrir pour la première fois un ensemble de mises à jour des API de configuration, de l’interface en ligne de commande (CLI) Monaco et du produit Cloud Automation de l’éditeur lors de l’événement virtuel Perform cette semaine. Ces mises à jour, baptisées Software Intelligence as Code, élargissent le nombre de paramètres de l’API de configuration auxquels les développeurs peuvent accéder via Monaco. Elles ajoutent des garde-fous, des contrôles d’accès, qui limitent les ressources de production que les développeurs peuvent programmer.
Software Intelligence as Code : Monaco revu et corrigé
L’observabilité en tant que code n’est ni nouvelle sur le marché ni inédite pour Dynatrace. New Relic, le rival de Dynatrace en matière de gestion des performances des applications (APM), propose des alertes sous forme de code. D’autres concurrents, tels que SignalFx de Splunk et Datadog, automatisent les déploiements d’outils d’« observability as code » grâce à des partenariats avec HashiCorp Terraform.
De son côté, Dynatrace offre des fonctionnalités d’observability as code qui intègrent des données d’objectifs de niveau de service (SLO) dans les pipelines de test des applications depuis la grande époque de son outil patrimonial AppMon, que l’éditeur a remplacé par la plateforme Dynatrace en 2019.
Certains composants du volet Software Intelligence as Code présenté cette semaine, tels que les politiques de configuration de sécurité, étaient déjà disponibles en préversion l’année dernière. Les autres devraient être accessibles d’ici trois mois.
« Nous sommes en train de passer à un framework d’API entièrement nouveau », assure Stefan Greifeneder, directeur principal de la gestion des produits chez Dynatrace. « Nous étendons cette approche à un plus grand nombre de points de terminaison d’API, et dans les 90 prochains jours, nous aurons couvert la plupart d’entre eux. Les exemples de terminaux incluent les conteneurs et les processus, les applications web et mobiles, les services côté serveur, le marquage, les alertes, les profils de notification et les moniteurs synthétiques. »
D’autres responsables de Dynatrace rappellent que le lancement de Software Intelligence as Code, basé sur le CLI open source Monaco, est analogue à la disponibilité générale l’année dernière de sa plateforme Cloud Automation, basée sur son projet open source Keptn.
« Alors que nos efforts en matière d’open source et d’ouverture se poursuivent, nos API et l’interface en ligne de commande [Monaco] sont assurés de rester à jour grâce à notre architecture – avec des paramètres déclaratifs communs », vante Wolfgang Heider, directeur de la gestion produit chez Dynatrace, dans une session de question-réponse en ligne pendant l’événement virtuel.
Observability as code : les Ops tentent de convaincre les Devs de son intérêt
L’approche de Dynatrace en matière d’observability as code s’inscrit dans les grandes tendances IT, notamment l’essor des plateformes DevOps administrées par des équipes de développement ou SRE, qui fournissent aux développeurs un accès contrôlé en libre-service à l’infrastructure. L’émergence de ces plateformes coïncide avec une pénurie de compétences et un manque de « développeurs full stack » capable de gérer à la fois les applications et l’ensemble de la pile technologique « cloud-native ».
Le nouveau set d’outils d’observability as code de Dynatrace n’est pas destiné aux introuvables full stack, selon un ingénieur en solutions de Dynatrace.
« Les développeurs ne veulent absolument pas administrer la production », affirme Kyle Harrington, ingénieur principal en solutions pour l’Amérique du Nord chez Dynatrace, lors des questions-réponses de l’événement virtuel en ligne. « [Les développeurs] peuvent obtenir les données de métrique et de performance à travers Dynatrace pour s’assurer que tous les SLO sont atteints dans tous les environnements, sans avoir besoin d’intervenir ou de regarder un tableau de bord idiot, croisant [leurs] doigts pour qu’il ne devienne pas rouge… sans instrumentation manuelle et sans avoir à reconstruire un autre pipeline Jenkins. »
Dans certaines organisations, les pros des opérations IT ont déjà commencé à intégrer les outils SLO-as-code de Dynatrace dans les pipelines DevOps pour le compte des développeurs.
« En tant qu’ingénieurs responsables des performances, nous savons que lorsque nous exécutons des tests, il y a des milliers de lignes de données à examiner », affirme Michael Kobush, ingénieur qualité logiciel à l’Association nationale des commissaires d’assurance basé à Kansas City. « Il y a des tableaux et des graphiques à examiner, des comparaisons à faire, puis nous devons rédiger un rapport et le remettre à nos équipes de projet – cela peut prendre des heures, mais avec Cloud Automation et les tableaux de bord basés sur SLO, nous pouvons réduire ce temps de plusieurs heures à quelques secondes. »
Dans ce même panel, Andreas Grabner, évangéliste chez Dynatrace, a affirmé qu’il parlait depuis des années d’étendre l’accès en libre-service aux outils d’observabilité en tant que code. Mais lors d’un entretien mené après cette session, Michael Kobush indique qu’il devait encore convaincre les équipes de développement de s’intéresser aux tests d’application basés sur les SLO.
« J’ai mis en place un galon d’essai avec une équipe applicative pour montrer aux autres à quel point nous pouvons être plus productifs », explique Michael Kobush. « C’est tout un processus… Les [développeurs] ne veulent pas s’en occuper. C’est là le problème. Ce que je leur dis, c’est que plus tard vous testez les performances, moins vous avez de temps pour résoudre les problèmes, donc le fait d’adopter l’approche “shift left” permet d’avoir une application plus saine et d’économiser de l’argent. »
« Si nous pouvons identifier [les problèmes ou exceptions] plus tôt, nous pourrons demander à l’équipe responsable de travailler sur une correction au lieu de les transmettre au support pour résolution. »
Scarlette ClaytonAnalyste des systèmes de vente IT, Tractor Supply Co
Pendant ce temps, un autre participant à la conférence de Dynatrace considère que les équipes de développeurs au sein de son organisation ont été convaincues de l’intérêt de l’approche observability as code après avoir vécu de mauvaises expériences
« Pour être honnête, je constate à quel point il est douloureux de ne pas avoir une couche d’observabilité. C’est particulièrement vrai pour nos ingénieurs développeurs – notamment lorsqu’ils sont aveuglés par un problème de triage en production ou une escalade sous la contrainte », note Mark Tomlinson, architecte responsable des performances pour une société de paiements en ligne qui évalue un passage à la plateforme Dynatrace. « Ils ont tout à gagner d’une meilleure introspection du code – y compris celui qu’ils n’ont pas écrit – pour mieux comprendre comment leur propre code fonctionne à l’échelle. »
Les développeurs n’ont pas nécessairement envie de s’occuper du suivi réactif des problèmes de performance et de modifier la configuration de l’observabilité après coup, déclare Scarlette Clayton, analyste des systèmes de vente IT chez Tractor Supply Co, qui envisage également d’adopter l’observability as code en libre-service pour les équipes de développement.
« Dans certaines situations, nous ne découvrons un problème ou une exception qu’après la fin de la période [de réponse aux incidents] », témoigne-t-elle. « Si nous pouvons les identifier plus tôt, nous pourrons demander à l’équipe responsable de travailler sur une correction au lieu de les transmettre au support pour résolution. »
