Smart Talk Épisode 7 : Naviguer Cardinalité, Contrôle et Coûts dans l'Observabilité

Nous avons discuté de l'observabilité et de l'espace complémentaire de l'AIOps plusieurs fois dans cette série mais cette fois, nous faisons une plongée plus pragmatique dans le sujet pour comprendre la mentalité de l'acheteur. Qu'est-ce qu'un CIO d'une organisation devrait chercher quand il est sur le marché pour une solution d'observabilité ? Rejoignez-nous sur cet épisode alors que Dinesh Chandrasekhar, Chief Analyst et Fondateur de Stratola, parle à Krishna Yadappanavar, CEO de Kloudfuse. Krishna explique l'observabilité à travers le prisme de trois facteurs — Cardinalité, Contrôle et Coûts. Ces 3 C sont clés pour comprendre et gérer les données d'observabilité en constante augmentation. Ces facteurs ne sont pas seulement importants pour gérer les données mais aussi pour les exploiter et les métadonnées pour des analytics additionnelles. Un nouveau développement dans le domaine de l'observabilité est l'observabilité des modèles, surtout les LLM qui pilotent l'IA générative. Les 3 C s'appliquent aussi à ce cas d'usage émergent.

Quelques-uns 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é en silos
• Considérer les métadonnées
• Insight sur les coûts

Invité
Krishna Yadappanavar, CEO, Kloudfuse
Krishna Yadappanavar est le Co-Fondateur et CEO de Kloudfuse, une plateforme d'observabilité unifiée. Il a précédemment co-fondé SpringPath, sécurisant 94 millions de dollars en financement et menant la société à une acquisition de 320 millions de dollars par Cisco. Avec plus de 20 brevets, Krishna a significativement impacté les technologies de données, virtualisation et stockage chez Veritas, Commvault, EMC, VMware et Cisco. Il a co-écrit VMware's VMFS et conçu des composants critiques de la stack de virtualisation de stockage pour ESX Server. De plus, Krishna conseille et investit dans des startups émergentes à travers Data, Virtualization, Cloud, Security, et AI/ML, contribuant à la vision, stratégie produit, engineering et efforts go-to-market.

Animateur : Dinesh Chandrasekhar est un évangéliste technologique, un leader d'opinion et un analyste industriel IT chevronné. Avec près de 30 ans d'expérience, Dinesh a travaillé sur des logiciels B2B d'entreprise ainsi que des produits SaaS livrant et commercialisant des solutions sophistiquées pour des clients aux architectures complexes. Il a également défini et exécuté des stratégies GTM hautement réussies pour lancer plusieurs produits à forte croissance sur le marché chez diverses entreprises comme LogicMonitor, Cloudera, Hortonworks, CA Technologies, Software AG, IBM etc. Il est un conférencier prolifique, blogueur et codeur le week-end. Dinesh détient un MBA de Santa Clara University et un Master en Applications Informatiques de l'Université de Madras. Actuellement, Dinesh dirige sa propre entreprise, Stratola, une société de conseil en stratégie business client-centric et services marketing full-stack.

Ressources
Smart Talk Épisode 6 : AIOps et l'Avenir du Monitoring IT
Smart Talk Épisode 5 : Désagrégation de la Stack 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 Modernes et LLM
Smart Talk Épisode 2 : L'Essor des Applications GenAI avec Data-in-Motion
Smart Talk Épisode 1 : Le Paysage de l'Écosystème Data-in-Motion
Voir la carte de l'écosystème data-in-motion ici
En savoir plus sur data-in-motion sur RTInsights ici

Transcription
Dinesh Chandrasekhar

Bonjour et bienvenue à cet épisode de Smart Talk, une série leadership Data in Motion. Et sur cet épisode nous avons un invité spécial, Krishna Yadappanavar. Il est le CEO de Kloudfuse. Il n'est pas étranger à l'écosystème startup. Il est un entrepreneur serial. Il a construit un couple d'entreprises avant celle-ci, et donc nous accueillons chaleureusement Krishna pour avoir cette conversation sur l'observabilité, qui est, encore, un thème favori dans cette série.

Krishna Yadappanavar

Merci.

Dinesh Chandrasekhar

Alors Krishna, comme façon de vous présenter, pourquoi ne pas nous parler de Kloudfuse et votre motivation pour créer l'entreprise ?

Krishna Yadappanavar (01:01) :

OK, absolument. Merci, Dinesh. Merci pour l'introduction chaleureuse. Salut les gens, je m'appelle Krishna. Ouais, je vis dans la Valley depuis presque deux décennies et plus et j'ai travaillé avec un bunch de startups et grandes entreprises. Le claim to fame c'est comme VMware quand c'était une startup early. J'ai rejoint et puis vu grandir de littéralement proche d'un million ERR à une entreprise de 64 milliards et j'ai été associé avec différentes technologies liées aux données, que ce soit écrire des systèmes de fichiers, systèmes distribués, bases de données ou OLAP ou OLTP. OK, donc tout au long de ce parcours ce que j'ai remarqué c'est que les données sont le secret de tous les insights, que ce soit du côté product analytics ou c'est fournir une solution comme virtualisation ou fournir une solution comme backup ou disaster recovery. Ayant fait ma startup, Springpath, qui était dans l'hyperconvergence, essayant d'apporter ensemble la convergence du stockage, networking, security altogether in a box je l'ai vendue à Cisco.

Et après avoir passé du temps chez Cisco, je pensais quels sont les prochains gros trends qui vont arriver ? C'est back in early 2020. Je suis tombé sur un couple de trends, comme certains trends liés à comment les données par rapport à un développeur DevOps ou SecOps grandissent exponentiellement. Comment les nouveaux trends dans le machine learning AI et modèles LLM back then les modèles LLM étaient dans les early stages vont disrupt le marché ? Et puis comme le cerveau humain commence à penser et réagir à certains incidents, vous voulez que les machines agissent de la même façon. Ce étaient quelques-uns des problèmes qu'on a rencontrés et dans l'intersection des trois, j'ai trouvé que hey, résoudre le problème de pas seulement l'observabilité, mais observabilité plus analytics et automation, on top des données, qui est focused sur les développeurs et les DevOps est très critique. Cela a mené au début de Kloudfuse–un a mené à l'autre et puis on est une team d'environ 40 plus personnes maintenant.

Dinesh Chandrasekhar (03:16) :

Bien, félicitations et c'est un excellent départ. Alors vous souhaitant bonne chance sur ce parcours. En parlant d'observabilité, ce n'était pas quelque chose qui vient juste d'arriver hier. J'ai travaillé dans cet espace aussi pour un fair amount de temps et le concept d'observabilité a évolué au fil des ans. Donc originalement 10, 12 ans il y a les gens étaient hyped up à parler d'infrastructure monitoring, network monitoring et tout ça, et puis lentement une chose a mené à l'autre et puis il y avait cloud monitoring et container monitoring capabilities qui se sont ajoutés. Et puis aujourd'hui on a cette notion d'observabilité qui est assez populaire. La plupart des entreprises qui vantaient le monitoring sont maintenant des entreprises d'observabilité. Et je sais que vous avez démarré from scratch dans l'espace observabilité voulant créer une différence. Comment décririez-vous cette évolution ? Qu'était-ce avant comparé à ce qu'on a aujourd'hui ? Comment avez-vous vu cette évolution ?

Krishna Yadappanavar (04:09) :

Ouais, excellente question. Dinesh. J'ai vu ça, je veux dire en tant que développeur moi-même écrivant une application monolithique tournant dans des machines physiques. Ensuite j'ai vu l'avènement de la virtualisation, que ce soit comme VMware ou Hyper-V ou les technologies de virtualisation open-source et la containerization est arrivée. Donc si vous regardez les problèmes core quand ça vient aux données pour l'observabilité, comme ces évaluations ont évolué, donc on a vu les attributs associés avec les données continuent d'augmenter, et quand vous prenez le produit cartésien de ces attributs, alors ça devient vraiment large dans l'ordre de multiples millions à milliards. Ce qu'ils appellent comme la cardinalité associée avec cette cardinalité est le volume de données. Comme le volume de données augmente, les gens veulent transformer data A en data B pour de meilleurs analytics. Ils veulent automatiser certains workflows on top des données.

Ils veulent slicer et dicer les données pour que ça puisse vous donner de meilleurs insights. Donc en court, comme le volume de données augmente la façon traditional de, hey, je monitorais so-called as the known knowns part, qui est le monitoring traditional. Ensuite vous regardez les known unknowns, qui est le début de l'observabilité et il y a les complete unknown unknowns où vous ne savez rien et vous êtes jeté à des multi-teraoctets à petaoctets de données et vous devez disséquer dans ces données et arriver au lack of better word où exactement le problème est, comment il est corrélé à l'incident, c'est quoi le root cause analysis, c'est quoi l'impact analysis. Donc aussi longtemps que les développeurs écrivent du code, cette complexité et plus et plus de services arrivent. Cette complexité va aller plus haut et plus haut et donc ça continue d'être un espace évolutif où de nouveaux défis émergent.

Dinesh Chandrasekhar (06:14) :

Fantastique. Donc l'observabilité est évidemment un problème difficile à résoudre. J'aimerais explorer pourquoi c'est ça ? Mais je pense que vous l'avez touché un peu aussi juste maintenant, mais c'est aussi qu'on a un marketplace encombré avec un dime-a-dozen vendors là dehors qui disent, on résout cette partie de l'observabilité et ce genre d'observabilité et tout ça, mais il y a encore une recherche pour la solution idéale. Donc chaque CIO que je parle est toujours à la recherche de cette magic bullet qui genre résout leurs problèmes. Pourquoi c'est ça ? Y a-t-il un different lens à travers lequel vous devez regarder pour comprendre pourquoi il y a une different urge pour obtenir cette solution idéale ?

Krishna Yadappanavar (07:04) :

Donc comme je l'alludais earlier laissez-moi step back un peu, right ? Qu'est-ce que ce client cherche quand ils pensent à une solution d'observing idéale ? Commençons par le problème. Je classe ce problème comme les trois Cs — la Cardinalité, le Contrôle, et le Coût. Laissez-moi aller au next level de détails. Qu'est-ce que ces trois Cs veulent dire ? Cardinalité, c'est tout sur comment on a certaines données, que ce soit un tricky metric point ou une logline ou un event ou un trace ou un span venant de votre distributed tracing ou un continuous profile's profile, ça gets attached avec des additional, for lack of a better word, labels ou tags. Quand vous prenez le produit cartésien des valeurs potentielles que ces labels peuvent prendre, ça va grow really, really high. Donc maintenant chaque data point needs to be associated with its tags.

Alors appelons tags comme les métadonnées. Et puis il y a les données. Différents schémas ont différents problèmes. Certains sont metadata heavy. Quand vous allez au matrix site, quand vous venez aux logs et aux spans comme le distributed tracing, ils sont comme data heavy, mais en effet, c'est l'augmentation tremendeuse dans le volume des données d'observabilité à cause de la cardinalité. Nowadays j'ai vu le reverse trend. Je veux dire back in the days les gens pensaient comme, Hey, laissez-moi envoyer mes données à un portail SaaS et puis le vendor SaaS gérerait tout ça. Mais quand je parle à que ce soit le CTO ou un CIO ou un head of engineering ou les développeurs ou les architectes et même le CFO, ils pensent, laissez-moi avoir le contrôle de mes données. Qu'est-ce qu'ils veulent dire par ça ? Il y a un reverse trend qui est en train d'arriver que j'ai tellement de données pour diverses raisons, que ce soit le egress en risque de coût, les aspects de sécurité, ou le volume des données lui-même.

Ils ne veulent pas envoyer ces données outside leur VPC et il y a un autre angle à ça. Ils veulent bring in toutes les interfaces possibles qu'ils peuvent penser que ce soit pour une interface observatory traditional comme créer vos dashboards, alerts, SLOs, ou n'importe quelles fonctions analytics qui pourraient être écrites en SQL traditional ou GraphQL ou il pourrait y avoir des advanced comme Spark jobs pour lancer certains analytics on top des données d'observabilité parce que l'observabilité est devenue ce pilier fondamental. Cela veut dire qu'ils doivent own les données. Les données ne devraient pas quitter le VPC. Quand je dis les données, les données qui sont ingérées, les données qui sont requêtées, et les données qui sont analysées et, last but not least, c'est le coût. Si vous allez à n'importe quel vendor là dehors, que ce soit un vendor commercial SaaS traditional ou un composant open source, et il y a beaucoup de solutions open source là dehors. Le coût d'infrastructure, le coût du vendor 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 qu'une organisation traditional qui cherche une solution idéale, une solution d'observabilité idéale cherche.

Dinesh Chandrasekhar (10:24) :

Cardinalité, contrôle, et coûts. Je pense que j'aime ça. Les trois Cs sont une excellente façon de regarder l'espace observabilité et comment vous inférez ce qui est important pour les utilisateurs actuels et ainsi de suite. En parlant de coûts, depuis qu'on l'a touché, je veux vous poser cette question aussi. De mon expérience personnelle, quand j'ai parlé avec des clients qui cherchent une solution d'observabilité, ce qu'ils se plaignent souvent c'est comme, Hey, j'ai au moins huit à 10 outils différents dans chaque département que j'ai. Je regarde peut-être 30 à 40 outils à travers l'organisation aujourd'hui. Je paie déjà beaucoup de coûts pour ces licences année après année. « Pourquoi je veux une solution d'observabilité de plus, » c'est un pushback que j'avais l'habitude d'avoir, right ? Donc je vais poser cette même question à vous maintenant que vous avez touché l'aspect coût. Comment vous approchez cette question avec un CIO et les convainquez ou leur dites pourquoi c'est mieux que d'avoir 30 ou 40 outils différents ?

Krishna Yadappanavar (11:23) :

OK, excellente question. Donc pour répondre à cette question, commençons avec le problème de pourquoi il y a une prolifération d'outils. Donc si vous regardez l'écosystème entier, traditionalement certains vendors, si je prends les vendors commerciaux, ils étaient pretty good dans certains streams. Si vous allez aux logs, vous pouvez penser à Splunk. Si vous pensez aux metrics, vous pensez à Datadog. Ensuite à l'intérieur de Google et tous les FANGs du monde. Ce mouvement whole de open source a commencé, especially avec l'avènement de Kubernetes, puis sont venus des trucs comme Prometheus, OpenTelemetry, et whatnot.

Et il y a ce whole shift qui est en train d'arriver vers et moving vers des solutions basées sur l'open source. Qu'est-ce que ça veut dire ? Cela veut dire que les développeurs, les architectes, les DevOps guys veulent ingérer leurs données d'observabilité dans un format ouvert. Signifiant, même si je pick n'importe quelle instrumentation pour instrumenter mon code ou mettre n'importe quel agent pour collecter mes données, ça devrait être hundred percent open-source compatible. Donc c'est pourquoi quand les vendors commerciaux ont aussi commencé à mettre leurs agents en open source, alors du côté query, ils veulent la whole visualization, le dashboarding, l'alerting — toutes ces capacités to be driven by les open-source query languages. C'est pourquoi l'émergence de PromQL, LockQL, TraceQL, OpenTelemetry, they're now trying another open-source query language.

Donc maintenant vous êtes dans ce monde où vous avez beaucoup d'options. Les clients ont déjà pické certain pour certain stream, certains vendors.

Puis il y a un mouvement open source et puis différentes teams utilisent différentes infrastructures. Certaines sont basées sur Kubernetes, certaines sont basées sur serverless, certaines sont basées sur ECS, Fargate whatnot. Donc ça ajoute une autre dimension et pour get to the speed et l'agilité de la whole product delivery, CI/CD a évolué dans cette intersection pour résoudre les problèmes très rapidement. Ils essaient de look for la pointed solution et hence end up choosing la very pointed solution. C'est quand we as an ideal observability solution, si je devais start my observability stack pour my company, je would step back et see comme, hey, si je veux réduire mon MTTR et MTTD, j'ai besoin de collecter all the end streams des données d'observabilité. Est-ce que je vais à n différents vendors et pick n différents streams, ou est-ce que je vais à un observability data lake où je peux put all the streams together pour que la correlation, les fonctions advanced comme outlier detection, anomalies, causation devient relatively easier ? Ce serait une solution idéale où vous pouvez consolider tout dans un data lake où vous pouvez préserver vos données within vos premises.

Dinesh Chandrasekhar (14:18) :

Fantastique. Et j'aimerais aussi ajouter que le coût pour la prolifération d'outils, j'accepte largely parce que les développeurs veulent build their own thing et ils ont added dans beaucoup d'open source tooling aussi au mix, mais c'est aussi des achats au niveau département. Donc un département IT se sent comme je peux résoudre ce problème parce que laissez-moi get a bandaid solution, laissez-moi buy this tool off the shelf et l'utiliser. Et puis over time ils réalisent qu'ils ont added one more tool à l'arsenal et without realizing qu'ils ne sont pas looking at the forest for the trees. Donc les conversations CIO sont toujours intéressantes et sur comment vous pouvez compact ou réduire le nombre d'outils vous avez across l'entreprise et have one observability platform looking across les départements, looking across applications, infrastructure containers, et whatnot.

Krishna Yadappanavar (15:08) :

Absolument. Donc je veux dire to add on to that now different personas dans la company sont aussi looking at les mêmes données. Comme DevOps développeurs, architectes sont all looking at les données d'observabilité with respect to infrastructure, containerization applications, et whatnot. Using the same logs. Les SecOps guys essaient de dissect les données pour look for la security et les threats. Looking at les similar données coming from les logs ou les traces. Même les DataOps guys sont looking comme, Hey, comment sont mes data operations ? Et maintenant avec l'avènement de LLM, même les LLM Ops guys regardent les similar données pour faire leur kind of analytics. Donc il y a une autre consolidation qui needs to happen. C'est one thing I would look for dans une solution d'observabilité idéale. Comment est-ce que j'apporte tous les different personas dans une organisation pour qu'ils puissent leverager les données from the same so-called data lake.

Dinesh Chandrasekhar (16:05) :

Vraiment le proverbial single pane of glass thing qu'on a tous été striving for. Donc c'est une good thing. Donc je veux toucher sur une autre chose que vous avez mentioned briefly comme vous expliquiez la previous response, qui était sur réduire MTTR, right ? Donc comme un primary crux de l'observabilité, c'est sur pas seulement le troubleshooting mais aussi le reducing le MTTR reducing alert noise et those kinds de metrics aussi. Donc ça definitely saves SREs et IT Ops from having to split hairs et figure out où le trouble est et all that comme a key fundamental requirement pour résoudre ce. Vous avez besoin d'accéder aux événements real-time comme ils arrivent. S'il y a un log qui got entered dans une application particulière ou un serveur particulier sur une activité malicieuse ou quelque chose comme ça, vous avez besoin d'accéder à cet event right away then and there pour que vous puissiez comprendre où cette anomalie est, ce qui se passe across votre infrastructure, pourquoi ce particular spike dans un particular memory thread ou whatever.

Donc vous avez besoin de figure that out et in order for that to happen, vous avez besoin de la capacité d'ingérer tout ça en real time aussi. Data immediacy, qui est un favorite term de moi over the last year I've been talking about it, et data freshness is kind of prime importance here. C'est ce qu'on est talking about, comment fresh les données sont, c'est comment quickly vous pouvez résoudre ce particular problem ou maybe even avert quelque chose qui est about to happen dans ce particular context de l'observabilité, particulièrement quand you're talking about hundreds et thousands de in a servers que vous monitoriez et all that, ou où est-ce que vous pinpoint saying, here's où le trouble est in terms of getting the data to be as fresh as possible ou not. Est-ce que c'est largely dependent sur les mécanismes d'ingestion ? Parce que vous avez parlé de TEL et d'autres types de techniques d'instrumentation et all that too. Donc comment else would you think about it ou look at it from this perspective de comment quickly can I get access to realtime data ?

Krishna Yadappanavar (18:03) :

OK, another great aspect of the observe team, you're absolutely right, Danesh. Donc la key dimension où les données d'observative sont getting consumed c'est comment quickly can I have the data, le moment the data a left from the source of the data, que ce soit votre application ou vos infrastructure components ou votre platform comme open source components et things like that. Donc pour ça, si vous regardez comment l'industrie a évolué dans les last five to 10 years or so, les realtime streaming services, realtime databases ont come along. Si vous regardez les traditional observ solutions, I mean they couldn't leverage those functionality parce que la technology was relatively older. Donc avec l'avènement du realtime streaming et le realtime databases, you can get to the access of the data as quickly as possible. Donc that is the measure of what is called as a freshness of the data from the moment it has left the application until it is readily queryable, that's all matters.

Puis il y a that aspect de comme, hey, j'ai all the data. Comment est-ce que je compartmentalize that data ? Comment est-ce que je find the relevant patterns I need to get to the root cause is the next set of the problems. Donc that means I should be able to transform data one data to the other data. Hey, I'm getting series of logs. Can I quickly look at a metric out of the logs ? I'm getting a series of spans. Can I look at some attribute within that span or a trace to analyze that data ? Parce que these attributes sont typically correlated et that's how the debugging happens. Donc that is the next dimension. Et puis the third dimension is the advanced analytics. On top of that data, can I bring some interesting statistical ou les large language models pour analyze the data pour find what is called the outliers in my system ?

Can I find the anomalies in my system ? OK, can I look into the seasonality aspect of my data ? Can I forecast my data based on what I have seen from the past ? The seasonal aspect of the data ? Donc all these is what I call as the package of the advanced analytics. Donc when you think of the overall solution after the freshnes sof the data is solved, you need to think about the data as a unit of a brick et then how each brick can be adjusted et then set of analytics function. Et then the natural thing that we'll need to is like, hey, I have analyzed this once, can I automate it ? That becomes the natural extension to the whole thing. Donc that's why along with the three Cs problem, we have seen the customers asking how can I observe, analyze and automate my observing data.

Dinesh Chandrasekhar (20:57) :

Very cool. Very cool. Et puis as a part of your response, you also mentioned the magic word LLMs, large language models. I mean these days you cannot have a conversation without talking about GenAI LLMs. So I'm glad you mentioned it because I could definitely ask you about this, which is LLM observability. It looks like that's an emerging space suddenly given that we have a proliferation of LLMs everywhere et people are struggling with understanding comment they're performing et so forth. So tell us about that. It looks like Kloufuse is also building something on that front as well, right ? So tell us more about it.

Krishna Yadappanavar (21:32) :

I mean, yes. I mean fundamentally the whole, the LLM models sont getting deployed in various use cases, right ? As for lack of better word. Le dynamism of the data changes, especially in the observability world, the data is very dynamic. Building the right LLM model pour do certain operations is always hard. So we have looked at the problem in two ways. Comment can I leverager certain LLM models on top of the existing observability data, qui est getting consumed by all the different personas I talked about, que ce soit DevOps ou SecOps ou DataOps guys ou les LLMOps guys. That's the one aspect of it. Et il y a the other aspect de, hey, I'm developing an application où le LLM is a very, very critical component. Comment do I look at the complete observability of an application qui est producing the data, qui est getting fed into the LLM, et then there are a lot of consumers qui sont consuming that data from those LLM models.

So we are thinking of, in fact, I can say that we are the first one to end to end think about what is the true observability for all the applications qui sont developed using the LLM models. Because I have come across a lot of solutions just looking at the model observability like drift et things like that. But we are looking end to end. That's a very interesting aspect because a lot of infrastructure application observability goes along with the model observability et the rest of the things. Et then last but not the least, if you go and ask any CIO or the CFO, le cost of the LLM, comme the current solutions, le cost is another key dimension. Comment do you keep that cost ou even provide any analytics on the cost metrics of the LLM models itself is another aspect of it. So you have to look into everything: performance, lack of, let's call it an APM for LLM applications, et then the cost. So these are the typical dimensions you would look at it.

Dinesh Chandrasekhar

Very cool, exciting space et I'm definitely excited about learning what's coming in that space in the upcoming few months. So thank you so much, Krishna. This has been a very, very wonderful conversation. Loved having you on our show. Love talking about observability. I'm going to remember your three Cs: Cardinalality, Control, and Costs. Je pense que c'est une great way, great mantra pour regarder l'observabilité. So thank you for all the insights. Appreciate you being here. Thank you.

Krishna Yadappanavar

Thanks a lot, Dinesh. Thanks for having me on your web chat.