Smart Talk Épisode 7 :Naviguer dans la cardinalité, le contrôle et les coûts dans l'observabilité

Nous avons discuté de l'observabilité et de l'espace complémentaire de l'AIOps à plusieurs reprises dans cette série, mais cette fois, nous approfondissons le sujet de manière plus pragmatique pour comprendre la mentalité de l'acheteur. Que doit rechercher le DSI d'une organisation lorsqu'il est à la recherche d'une solution d'observabilité ? Rejoignez-nous dans cet épisode alors que Dinesh Chandrasekhar, analyste en chef et fondateur de Stratola, s'entretient avec Krishna Yadappanavar, PDG de Kloudfuse. Krishna explique l'observabilité à travers le prisme de trois facteurs :la cardinalité, le contrôle et les coûts.
Ces 3 C sont essentiels pour comprendre et gérer des données d’observabilité toujours croissantes. Ces facteurs sont non seulement importants pour gérer les données, mais également pour exploiter les données et les métadonnées à des fins d'analyses supplémentaires.
Un nouveau développement dans le domaine de l’observabilité est l’observabilité des modèles, en particulier les LLM qui pilotent l’IA générative. Les 3 C s'appliquent également à ce cas d'utilisation émergent.

Certains des sujets abordés dans cet épisode de Smart Talk sont :

• Le potentiel des données d'observabilité
• Prolifération des outils
• Surmonter les données d'observabilité cloisonnées
• Considérer les métadonnées
• Aperçu des coûts

Invité
Krishna Yadappanavar, PDG, Kloudfuse
Krishna Yadappanavar est le co-fondateur et PDG de Kloudfuse, une plateforme d'observabilité unifiée. Il a auparavant cofondé SpringPath, obtenant un financement de 94 millions de dollars et menant l'entreprise à une acquisition de 320 millions de dollars par Cisco. Avec plus de 20 brevets, Krishna a eu un impact significatif sur les technologies de données, de virtualisation et de stockage chez Veritas, Commvault, EMC, VMware et Cisco. Il est co-auteur du VMFS de VMware et a conçu les composants critiques de la pile de virtualisation du stockage pour ESX Server. De plus, Krishna conseille et investit dans des startups émergentes dans les domaines des données, de la virtualisation, du cloud, de la sécurité et de l'IA/ML, contribuant ainsi à la vision, à la stratégie produit, à l'ingénierie et aux efforts de mise sur le marché.

Hôte :  Dinesh Chandrasekhar est un évangéliste technologique, un leader d'opinion et un analyste chevronné du secteur informatique. Avec près de 30 ans d'expérience, Dinesh a travaillé sur des logiciels d'entreprise B2B ainsi que sur des produits SaaS, fournissant et commercialisant des solutions sophistiquées pour des clients dotés d'architectures complexes. Il a également défini et exécuté des stratégies GTM très réussies pour lancer plusieurs produits à forte croissance sur le marché dans diverses sociétés telles que LogicMonitor, Cloudera, Hortonworks, CA Technologies, Software AG, IBM, etc. Il est un conférencier prolifique, un blogueur et un codeur le week-end. Dinesh est titulaire d'un MBA de l'Université de Santa Clara et d'une maîtrise en applications informatiques de l'Université de Madras. Actuellement, Dinesh dirige sa propre entreprise, Stratola, une société de conseil en stratégie commerciale et de services de marketing complets axée sur le client.

Ressources
Smart Talk Épisode 6 : AIOps et l'avenir de la surveillance informatique
Smart Talk Épisode 5 : Désagrégation de la pile d'observabilité
Smart Talk Épisode 4 :Données en temps réel et bases de données vectorielles
Smart Talk Épisode 3 :Pipelines de données et LLM modernes
Smart Talk Épisode 2 :L'essor des applications GenAI avec Data-in-Motion
Smart Talk Épisode 1 : Le paysage de l'écosystème des données en mouvement
Consultez la carte de l'écosystème data-in-motion ici
Apprenez-en davantage sur les données en mouvement sur RTInsights ici

Transcription
Dinesh Chandrasekhar

Bonjour et bienvenue dans cet épisode de Smart Talk, une série de leadership Data in Motion. Et dans cet épisode, nous avons un invité spécial, Krishna Yadappanavar. Il est le PDG de Cloud Fuse. Il n’est pas étranger à l’écosystème des startups. C'est un entrepreneur en série. Il a construit quelques entreprises avant cela, et nous invitons donc chaleureusement Krishna à avoir cette conversation sur l'observabilité, qui est, encore une fois, un thème favori de cette série. 

Krishna Yadappanavar

Merci.

Dinesh Chandrasekhar

Alors Krishna, pour vous présenter, pourquoi ne nous parlez-vous pas de Kloudfuse et de votre volonté de créer l'entreprise ?

Krishna Yadappanavar (01:01) :

D'accord, absolument. Merci, Dinesh. Merci pour cette introduction chaleureuse. Salut les amis, je m'appelle Krishna. Oui, je vis dans la Valley depuis près de deux décennies et j'ai travaillé avec de nombreuses startups et grandes entreprises. Le nom de la renommée ressemble à celui de VMware lorsqu'il s'agissait d'une des premières startups. J'ai rejoint l'entreprise et je l'ai ensuite vu passer d'un million d'ERR à une entreprise de 64 milliards d'euros et j'ai été associé à différentes technologies liées aux données, qu'il s'agisse d'écriture de systèmes de fichiers, de systèmes distribués, de bases de données ou d'OLAP ou OLTP. D'accord, tout au long de ce parcours, ce que j'ai remarqué, c'est que les données sont le secret de toutes les informations, que ce soit du côté de l'analyse des produits ou qu'elles fournissent une solution comme la virtualisation ou qu'elles fournissent une solution comme la sauvegarde ou la reprise après sinistre. Après avoir créé ma startup, Springpath, qui était dans l'hyperconvergence, essayant de rassembler la convergence du stockage, de la mise en réseau et de la sécurité dans une boîte que j'ai vendue à Cisco.

Et après avoir passé du temps chez Cisco, je me demandais quelles seraient les prochaines grandes tendances à venir ? C'était au début de 2020. J'ai découvert quelques tendances, comme certaines tendances liées à la croissance exponentielle des données relatives à un développeur DevOps ou SecOps. Comment les nouvelles tendances dans les modèles d’apprentissage automatique IA et LLM à l’époque où les modèles LLM en étaient à leurs débuts vont-elles perturber le marché ? Et puis, à mesure que le cerveau humain commence à penser et à réagir à certains incidents, vous souhaitez que les machines agissent de la même manière. Ce sont quelques-uns des problèmes que nous avons rencontrés et à l'intersection des trois, j'ai trouvé que résoudre le problème non seulement de l'observabilité, mais aussi de l'observabilité plus de l'analyse et de l'automatisation, en plus des données, qui se concentrent sur les développeurs et le DevOps, est très critique. Cela a conduit au début de Kloudfuse – l’un a conduit à l’autre, et nous sommes désormais une équipe d’environ 40 personnes.

Dinesh Chandrasekhar (03:16) :

Eh bien, félicitations et c'est un bon début. Je vous souhaite donc bonne chance dans ce voyage. En parlant d’observabilité, ce n’est pas quelque chose qui s’est produit hier. J'ai également travaillé dans cet espace pendant pas mal de temps et le concept d'observabilité a évolué au fil des ans. Donc, à l'origine, il y a 10 ou 12 ans, les gens étaient excités à l'idée de parler de surveillance des infrastructures, de surveillance des réseaux et tout ça, puis lentement, une chose en a entraîné une autre, puis des capacités de surveillance du cloud et de surveillance des conteneurs ont été ajoutées. Et puis aujourd’hui, nous avons cette notion d’observabilité qui est assez populaire. La plupart des entreprises qui vantaient autrefois la surveillance sont désormais des sociétés d’observabilité. Et je sais que vous avez recommencé dans le domaine de l'observabilité en voulant créer une différence. Comment décririez-vous cette évolution ? Qu’était-ce avant par rapport à ce que nous avons aujourd’hui ? Comment avez-vous vu cette évolution ?

Krishna Yadappanavar (04:09) :

Ouais, excellente question. Dinesh. J'ai vu cela, je veux dire en tant que développeur écrivant moi-même une application monolithique exécutée sur des machines physiques. Ensuite, j'ai vu l'avènement de la virtualisation, qu'il s'agisse de VMware ou d'Hyper-V ou des technologies de virtualisation open source et de la conteneurisation. Donc, si vous regardez les principaux problèmes liés aux données pour l'observabilité, à mesure que ces évaluations ont évolué, nous avons vu les attributs associés aux données continuer à augmenter, et lorsque vous prenez le produit cartésien de ces attributs, alors il devient vraiment important, de l'ordre de plusieurs millions à plusieurs milliards. Ce qu'ils appellent la cardinalité associée à cette cardinalité est le volume de données. À mesure que le volume de données augmente, les utilisateurs souhaitent transformer les données A en données B pour de meilleures analyses. Ils souhaitent automatiser certains flux de travail en plus des données.

Ils veulent découper les données afin qu'elles puissent vous donner de meilleures informations. En bref, à mesure que le volume de données augmente de la manière traditionnelle, je surveillais ce qu'on appelle à mesure que les connus disparaissent, ce qui est la surveillance traditionnelle. Ensuite, vous regardez les inconnues connues, qui sont le début de l'observabilité et il y a les inconnues totales inconnues où vous ne savez rien et vous êtes jeté entre plusieurs téraoctets et pétaoctets de données et vous devez disséquer ces données et arriver à l'absence de meilleur mot où se situe exactement le problème, comment il est corrélé à l'incident, quelle est l'analyse des causes profondes, quelle est l'analyse d'impact. Ainsi, tant que les développeurs écrivent du code, cette complexité et de plus en plus de services arrivent. Cette complexité va aller de plus en plus haut et cela continue donc d'être un espace en évolution où de nouveaux défis émergent.

Dinesh Chandrasekhar (06:14) :

Fantastique. L’observabilité est donc évidemment un problème difficile à résoudre. J'adorerais découvrir pourquoi ? Mais je pense que vous en avez également parlé un peu tout à l'heure, mais c'est aussi que nous avons un marché encombré avec une douzaine de vendeurs qui disent, nous résolvons cette partie de l'observabilité et ce type d'observabilité et tout ça, mais il reste encore à chercher la solution idéale. Ainsi, chaque DSI à qui je parle est toujours à la recherche de la solution miracle qui résoudrait en quelque sorte ses problèmes. Pourquoi donc? Existe-t-il un angle différent à travers lequel vous devez examiner les choses pour comprendre pourquoi il existe un besoin différent d'obtenir cette solution idéale ?

Krishna Yadappanavar (07:04) :

Alors comme je le disais plus tôt, permettez-moi de prendre un peu de recul, n'est-ce pas ? Que recherche ce client lorsqu’il réfléchit à une solution d’observation idéale ? Commençons par le problème. Je classe ce problème selon les trois C :la cardinalité, le contrôle et le coût. Permettez-moi d'entrer dans le niveau de détails suivant. Que signifient ces trois C ? La cardinalité, tout dépend de la façon dont nous obtenons certaines données, qu'il s'agisse d'un point métrique délicat ou d'une ligne de connexion ou d'un événement ou d'une trace ou d'une étendue provenant du traçage de votre distributeur ou du profil d'un profil continu, elles sont associées à des éléments supplémentaires, faute d'un meilleur mot, des étiquettes ou des tags. Lorsque vous prenez le produit cartésien des valeurs potentielles que ces étiquettes peuvent prendre, il deviendra vraiment très élevé. Alors maintenant, chaque point de données doit être associé à ses balises.

Appelons donc les balises les métadonnées. Et puis il y a une donnée. Différents régimes posent des problèmes différents. Certains sont lourds en métadonnées. Quand vous allez sur le site matriciel, quand vous arrivez aux journaux et aux étendues comme le traçage distribué, ils sont comme des données lourdes, mais en fait, c'est l'énorme augmentation du volume des données d'observabilité en raison de la cardinalité. Aujourd’hui, j’ai constaté la tendance inverse. Je veux dire à l'époque, les gens pensaient :« Hé, laissez-moi envoyer mes données vers un portail SaaS et ensuite le fournisseur SaaS gérerait toutes ces données. Mais quand je demande s’il s’agit du CTO, du CIO, du responsable de l’ingénierie, des développeurs, des architectes et même du directeur financier, ils pensent :laissez-moi contrôler mes données. Que veulent-ils dire par là ? Il y a une tendance inverse qui se produit :j'ai tellement de données pour diverses raisons, qu'il s'agisse du coût du risque, des aspects de sécurité ou du volume des données elles-mêmes.

Ils ne veulent pas envoyer ces données en dehors de leur VPC et cela présente un autre angle. Ils veulent intégrer toutes les interfaces possibles auxquelles ils peuvent penser, qu'il s'agisse d'une interface de type observatoire traditionnelle comme la création de vos tableaux de bord, d'alertes, de SLO ou de toute fonction d'analyse qui pourrait être écrite dans un SQL traditionnel ou un GraphQL ou qui pourrait être avancée comme les tâches Spark pour exécuter des analyses au-dessus des données d'observabilité, car l'observabilité est devenue ce pilier fondamental. Cela signifie qu’ils doivent posséder les données. Les données ne doivent pas quitter le VPC. Quand je parle de données, de données qui sont ingérées, de données interrogées et de données analysées, et enfin et surtout, il y a le coût. Si vous vous adressez à n'importe quel fournisseur, qu'il s'agisse d'un fournisseur commercial SaaS traditionnel ou d'un composant open source, il existe de nombreuses solutions open source. Le coût de l'infrastructure, le coût du fournisseur est directement proportionnel au volume de données, directement proportionnel au nombre de requêtes et directement proportionnel au nombre d'utilisateurs. Ces trois choses sont les problèmes que recherche une organisation traditionnelle qui recherche une solution idéale, une solution d'observabilité idéale.

Dinesh Chandrasekhar (10:24) :

Cardinalité, contrôle et coûts. Je pense que j'adore ça. Les trois C sont un excellent moyen d'examiner l'espace d'observabilité et de déterminer ce qui est important pour les utilisateurs réels, etc. Parlant de coûts, puisque nous en avons parlé, je veux également vous poser cette question. D'après ma propre expérience personnelle, lorsque j'ai parlé avec des clients qui recherchent une solution d'observabilité, ce dont ils se plaignent souvent, c'est :Hé, j'ai au moins huit à 10 outils différents dans chaque service dont je dispose. J’examine aujourd’hui entre 30 et 40 outils dans l’organisation. Je dois déjà payer beaucoup de frais pour ces licences année après année. « Pourquoi est-ce que je veux une solution d'observabilité supplémentaire », est une réticence que j'avais l'habitude de recevoir, n'est-ce pas ? Je vais donc vous poser la même question maintenant que vous avez abordé l’aspect coût. Comment aborder cette question avec un DSI et le convaincre ou lui expliquer pourquoi c'est mieux que d'avoir 30 ou 40 outils différents ?

Krishna Yadappanavar (11:23) :

D'accord, excellente question. Donc, pour répondre à cette question, commençons par le problème de savoir pourquoi il y a une prolifération d’outils. Donc, si vous regardez l’ensemble de l’écosystème, traditionnellement certains fournisseurs, si je prends les fournisseurs commerciaux, ils étaient plutôt bons dans certains flux. Si vous consultez les logs, vous pouvez penser à Splunk. Si vous pensez aux métriques, vous pensez à Datadog. Puis à l'intérieur de Google et de tous les FANG du monde. Tout ce mouvement de l'open source a commencé, en particulier avec l'avènement de Kubernetes, puis sont arrivés des choses comme Prometheus, OpenTelemetry, etc.

Et il y a tout ce changement qui se poursuit vers une solution basée sur l’open source. Qu'est-ce que ça veut dire? Cela signifie que les développeurs, les architectes et les responsables DevOps souhaitent ingérer leurs données d'observabilité dans un format ouvert. Cela signifie que même si je choisis une instrumentation pour instrumenter mon code ou si je mets n'importe quel agent pour collecter mes données, cela devrait être compatible à 100 % avec l'open source. C'est pourquoi, lorsque les fournisseurs commerciaux ont également commencé à mettre leurs agents en open source, puis du côté des requêtes, ils souhaitent que l'ensemble de la visualisation, des tableaux de bord, des alertes – toutes ces fonctionnalités soient pilotées par les langages de requête open source. C'est pourquoi, avec l'émergence de PromQL, LockQL, TraceQL, OpenTelemetry, ils essaient maintenant un autre langage de requête open source.

 Alors maintenant, vous êtes dans ce monde où vous avez de nombreuses options. Les clients ont déjà choisi certains fournisseurs pour certains flux.

Ensuite, il y a un mouvement open source et différentes équipes utilisent différentes infrastructures. Certains sont basés sur Kubernetes, certains sont basés sur le sans serveur, certains sont basés sur ECS, Fargate et ainsi de suite. Cela ajoute donc une autre dimension et pour atteindre la rapidité et l'agilité de l'ensemble de la livraison du produit, CI/CD a évolué dans cette intersection pour résoudre les problèmes très rapidement. Ils essaient de rechercher la solution pointue et finissent donc par choisir la solution très pointue. C'est à ce moment-là que nous sommes une solution d'observabilité idéale, si je devais démarrer ma pile d'observabilité pour mon entreprise, je prendrais du recul et verrais, hé, si je veux réduire mon MTTR et MTTD, je dois collecter tous les flux finaux des données d'observabilité. Dois-je aller à n différents fournisseurs et choisissez n différents flux, ou dois-je accéder à un lac de données d'observabilité où je peux rassembler tous les flux afin que la corrélation, les fonctions avancées telles que la détection des valeurs aberrantes, les anomalies, la causalité deviennent relativement plus faciles ? Ce serait une solution idéale où vous pouvez tout consolider dans un lac de données où vous pouvez conserver vos données dans vos locaux.

Dinesh Chandrasekhar (14:18) :

Fantastique. Et je voudrais également ajouter que le coût de la prolifération des outils, je suis en grande partie d'accord parce que les développeurs veulent créer leur propre système et ils ont également ajouté de nombreux outils open source au mélange, mais il s'agit également d'achats au niveau du département. Ainsi, un service informatique a le sentiment que je peux résoudre ce problème, car laissez-moi trouver une solution de fortune, laissez-moi acheter cet outil dans le commerce et l'utiliser. Et puis, au fil du temps, ils ont réalisé qu’ils avaient ajouté un outil supplémentaire à leur arsenal, sans se rendre compte qu’ils ne cherchaient pas les arbres dans la forêt. Les conversations des DSI sont donc toujours intéressantes sur la façon dont vous pouvez compacter ou réduire le nombre d'outils dont vous disposez dans toute l'entreprise et disposer d'une plate-forme d'observabilité qui examine tous les départements, examine les applications, les conteneurs d'infrastructure, etc. 

Krishna Yadappanavar (15:08) :

Absolument. Je veux donc ajouter que désormais, différentes personnalités de l'entreprise examinent également les mêmes données. À l'instar des développeurs DevOps, les architectes examinent tous les données d'observabilité concernant l'infrastructure, les applications de conteneurisation, etc. En utilisant les mêmes journaux. Les gars de SecOps essaient de disséquer les données pour rechercher la sécurité et les menaces. En regardant les données similaires provenant des journaux ou des traces. Même les gars de DataOps se demandent :Hé, quelle est la qualité de mes opérations de données ? Et maintenant, avec l'avènement du LLM, même les gars du LLM Ops examinent des données similaires pour effectuer leur type d'analyse. Il y a donc une autre consolidation qui doit avoir lieu. C’est une chose que je rechercherais dans une solution d’observabilité idéale. Comment puis-je intégrer tous les différents personnages d'une organisation afin qu'ils puissent exploiter les données du même lac de données.

Dinesh Chandrasekhar (16:05) :

Vraiment la proverbiale vitre unique que nous recherchons tous. C'est donc une bonne chose. Je voudrais donc aborder une autre chose que vous avez mentionnée brièvement en expliquant la réponse précédente, qui concernait la réduction du MTTR, n'est-ce pas ? Ainsi, en tant que point essentiel de l'observabilité, il s'agit non seulement du dépannage, mais également de la réduction du MTTR, de la réduction du bruit d'alerte et de ce type de mesures également. Cela évite donc définitivement aux SRE et aux opérateurs informatiques d'avoir à couper les cheveux en quatre et à déterminer où se trouve le problème et tout cela comme une exigence fondamentale pour résoudre ce problème. Vous devez accéder aux événements en temps réel au fur et à mesure qu’ils se produisent. S'il existe un journal entré dans une application particulière ou un serveur particulier concernant une activité malveillante ou quelque chose du genre, vous devez accéder immédiatement à cet événement afin de pouvoir comprendre où se trouve cette anomalie, ce qui se passe dans votre infrastructure, pourquoi ce pic particulier dans un thread de mémoire particulier ou autre.

Vous devez donc comprendre cela et pour que cela se produise, vous devez également pouvoir ingérer tout cela en temps réel. L'immédiateté des données, qui est l'un de mes termes préférés au cours de la dernière année, et la fraîcheur des données sont ici d'une importance primordiale. C'est de cela dont nous parlons, de la fraîcheur des données, de la rapidité avec laquelle vous pouvez résoudre ce problème particulier ou peut-être même d'éviter quelque chose qui est sur le point de se produire dans ce contexte particulier d'observabilité, en particulier lorsque vous parlez de centaines et de milliers de serveurs que vous surveillez et tout ça, ou où vous situez-vous en disant, voici où se situe le problème en termes d'obtention de données aussi fraîches que possible ou non. Est-ce largement dépendant des mécanismes d’ingestion ? Parce que vous avez parlé de TEL et d'autres types de techniques d'instrumentation et tout ça aussi. Alors, comment pourriez-vous y penser autrement ou l'envisager du point de vue de la rapidité avec laquelle puis-je accéder aux données en temps réel ?

Krishna Yadappanavar (18:03) :

D'accord, un autre aspect formidable de l'équipe d'observation, vous avez tout à fait raison, Danesh. Ainsi, la dimension clé dans laquelle les données d'observation sont consommées est la rapidité avec laquelle je peux obtenir les données, au moment où les données ont quitté la source des données, qu'il s'agisse de votre application ou de vos composants d'infrastructure ou de votre plate-forme comme des composants open source et des choses comme ça. Donc pour cela, si vous regardez comment l’industrie a évolué au cours des cinq à dix dernières années, les services de streaming en temps réel et les bases de données en temps réel sont apparus. Si vous regardez les solutions d’observation traditionnelles, je veux dire qu’elles ne pouvaient pas exploiter ces fonctionnalités car la technologie était relativement ancienne. Ainsi, avec l’avènement du streaming en temps réel et des bases de données en temps réel, vous pouvez accéder aux données le plus rapidement possible. C'est donc la mesure de ce qu'on appelle la fraîcheur des données à partir du moment où elles ont quitté l'application jusqu'à ce qu'elles soient facilement interrogeables, c'est tout ce qui compte.

Ensuite, il y a cet aspect du genre, hé, j'ai toutes les données. Comment compartimenter ces données ? Comment puis-je trouver les modèles pertinents dont j'ai besoin pour identifier la cause profonde ? C'est la prochaine série de problèmes. Cela signifie donc que je devrais être capable de transformer des données d'une donnée à l'autre. Hé, je reçois une série de journaux. Puis-je consulter rapidement une métrique à partir des journaux ? J'obtiens une série de travées. Puis-je examiner un attribut dans cette période ou une trace pour analyser ces données ? Parce que ces attributs sont généralement corrélés et c’est ainsi que se produit le débogage. C’est donc la prochaine dimension. Et puis la troisième dimension concerne l’analyse avancée. En plus de ces données, puis-je apporter des statistiques intéressantes ou des modèles de langage étendus pour analyser les données et trouver ce qu'on appelle les valeurs aberrantes dans mon système ?

Puis-je trouver les anomalies dans mon système ? D'accord, puis-je examiner l'aspect saisonnier de mes données ? Puis-je prévoir mes données en fonction de ce que j'ai vu dans le passé ? L’aspect saisonnier des données ? C’est donc tout cela que j’appelle le package d’analyses avancées. Ainsi, lorsque vous pensez à la solution globale une fois la fraîcheur des données résolue, vous devez considérer les données comme une unité d'une brique, puis comment chaque brique peut être ajustée, puis définir une fonction d'analyse. Et puis la chose naturelle dont nous devrons faire, c'est :hé, j'ai analysé cela une fois, puis-je l'automatiser ? Cela devient le prolongement naturel de l’ensemble. C'est pourquoi, parallèlement au problème des trois C, nous avons vu les clients se demander comment puis-je observer, analyser et automatiser mes données d'observation.

Dinesh Chandrasekhar (20:57) :

Très cool. Très cool. Et puis, dans le cadre de votre réponse, vous avez également mentionné le mot magique LLM, grands modèles de langage. Je veux dire que de nos jours, vous ne pouvez pas avoir une conversation sans parler des GenAI LLM. Je suis donc heureux que vous en ayez parlé car je pourrais certainement vous poser des questions à ce sujet, à savoir l'observabilité LLM. Il semble que ce soit un espace émergent soudainement étant donné que nous avons une prolifération de LLM partout et que les gens ont du mal à comprendre leurs performances, etc. Alors parlez-nous de ça. Il semble que Kloufuse construit également quelque chose dans ce sens, n'est-ce pas ? Alors dites-nous-en plus.

Krishna Yadappanavar (21:32) :

Je veux dire, oui. Je veux dire, fondamentalement, dans l'ensemble, les modèles LLM sont déployés dans divers cas d'utilisation, n'est-ce pas ? Quant au manque de meilleur mot. Le dynamisme des données change, notamment dans le monde de l'observabilité, les données sont très dynamiques. Construire le bon modèle LLM pour effectuer certaines opérations est toujours difficile. Nous avons donc examiné le problème de deux manières. Comment puis-je exploiter certains modèles LLM en plus des données d'observabilité existantes, qui sont consommées par tous les différents personnages dont j'ai parlé, qu'il s'agisse des gars DevOps, SecOps, DataOps ou LLMOps. C’est le seul aspect de la question. Et il y a l’autre aspect, hé, je développe une application où le LLM est un composant très, très critique. Comment puis-je examiner l'observabilité complète d'une application qui produit les données, qui sont introduites dans le LLM, et puis il y a beaucoup de consommateurs qui consomment ces données à partir de ces modèles LLM.

Nous réfléchissons donc, en fait, je peux dire que nous sommes les premiers à réfléchir de bout en bout à ce qu'est la véritable observabilité pour toutes les applications qui sont développées à l'aide des modèles LLM. Parce que j'ai trouvé beaucoup de solutions rien qu'en regardant l'observabilité du modèle, comme la dérive et des choses comme ça. Mais nous regardons bout à bout. C’est un aspect très intéressant car une grande partie de l’observabilité des applications d’infrastructure va de pair avec l’observabilité du modèle et le reste. Et enfin, si vous demandez à n’importe quel CIO ou CFO, le coût du LLM, comme les solutions actuelles, le coût est une autre dimension clé. Comment conserver ce coût ou même fournir des analyses sur les mesures de coût des modèles LLM eux-mêmes en est un autre aspect. Il faut donc tout examiner : les performances, leur manque, appelons cela un APM pour les applications LLM, et puis le coût. Voici donc les dimensions typiques que vous examineriez.

Dinesh Chandrasekhar

Espace très cool et passionnant et j’ai vraiment hâte d’apprendre ce qui s’y passera dans les prochains mois. Alors merci beaucoup, Krishna. Cela a été une conversation très, très merveilleuse. J'ai adoré vous avoir dans notre émission. J'adore parler d'observabilité. Je vais me souvenir de vos trois C :  Cardinalalité, Contrôle et Coûts. Je pense que c’est une excellente façon, un excellent mantra d’examiner l’observabilité. Merci donc pour toutes ces informations. Merci d'être ici. Merci.

Krishna Yadappanavar

Merci beaucoup, Dinesh. Merci de m'avoir invité sur votre chat en ligne.