Smart Talk Aflevering 7:Navigeren door kardinaliteit, controle en kosten in waarneembaarheid

We hebben de waarneembaarheid en de complementaire ruimte van AIOps een paar keer besproken in deze serie, maar deze keer duiken we pragmatischer in het onderwerp om de mentaliteit van de koper te begrijpen. Waar moet een CIO van een organisatie op letten als hij of zij op zoek is naar een observatieoplossing? Kijk mee in deze aflevering terwijl Dinesh Chandrasekhar, hoofdanalist en oprichter van Stratola, praat met Krishna Yadappanavar, CEO van Kloudfuse. Krishna legt de waarneembaarheid uit door de lens van drie factoren:kardinaliteit, controle en kosten.
Deze drie C’s zijn van cruciaal belang voor het begrijpen en beheren van de steeds grotere waarneembaarheidsgegevens. Deze factoren zijn niet alleen belangrijk voor het beheer van de gegevens, maar ook voor het benutten van de gegevens en metagegevens voor aanvullende analyses.
Een nieuwe ontwikkeling op het gebied van waarneembaarheid is de waarneembaarheid van modellen, vooral de LLM’s die generatieve AI aandrijven. De 3 C’s zijn ook van toepassing op deze opkomende use case.

Enkele onderwerpen die in deze aflevering van Smart Talk aan bod komen zijn:

• Het potentieel van waarneembaarheidsgegevens
• Proliferatie van tools
• Het overwinnen van geïsoleerde observatiegegevens
• Overweeg de metadata
• Inzicht in de kosten

Gast
Krishna Yadappanavar, CEO van Kloudfuse
Krishna Yadappanavar is medeoprichter en CEO van Kloudfuse, een uniform observatieplatform. Hij was eerder medeoprichter van SpringPath, verzekerde zich van $94 miljoen aan financiering en leidde het bedrijf naar een overname door Cisco van $320 miljoen. Met meer dan twintig patenten heeft Krishna een aanzienlijke impact gehad op data-, virtualisatie- en opslagtechnologieën bij Veritas, Commvault, EMC, VMware en Cisco. Hij was co-auteur van VMware’s VMFS en ontwierp cruciale componenten van de opslagvirtualisatiestack voor ESX Server. Daarnaast adviseert en investeert Krishna in opkomende startups op het gebied van data, virtualisatie, cloud, beveiliging en AI/ML, en draagt zo bij aan visie, productstrategie, engineering en go-to-market-inspanningen.

Host:  Dinesh Chandrasekhar is een technologie-evangelist, een thought leader en een doorgewinterde IT-industrieanalist. Met bijna 30 jaar ervaring heeft Dinesh gewerkt aan B2B-bedrijfssoftware en SaaS-producten, waarbij geavanceerde oplossingen worden geleverd en op de markt gebracht voor klanten met complexe architecturen. Hij heeft ook zeer succesvolle GTM-strategieën gedefinieerd en uitgevoerd om verschillende snelgroeiende producten op de markt te brengen bij verschillende bedrijven zoals LogicMonitor, Cloudera, Hortonworks, CA Technologies, Software AG, IBM enz. Hij is een productief spreker, blogger en weekendcodeur. Dinesh heeft een MBA-diploma van de Santa Clara Universiteit en een masterdiploma in computertoepassingen van de Universiteit van Madras. Momenteel runt Dinesh zijn eigen bedrijf, Stratola, een klantgericht advies- en full-stack marketingbureau voor bedrijfsstrategieën.

Bronnen
Smart Talk Aflevering 6:AIOps en de toekomst van IT-monitoring
Smart Talk Aflevering 5:Disaggregatie van de observatiestapel
Smart Talk Aflevering 4:Realtime gegevens- en vectordatabases
Smart Talk Aflevering 3:Moderne datapijplijnen en LLM's
Smart Talk Aflevering 2:De opkomst van GenAI-applicaties met Data-in-Motion
Smart Talk Aflevering 1:Het data-in-motion-ecosysteemlandschap
Bekijk hier de data-in-motion ecosysteemkaart
Lees hier meer over data-in-motion op RTInsights

Transcriptie
Dinesh Chandrasekhar

Hallo en welkom bij deze aflevering van Smart Talk, een Data in Motion-leiderschapsserie. En in deze aflevering hebben we een speciale gast, Krishna Yadappanavar. Hij is de CEO van Cloud Fuse. Hij is geen onbekende in het startup-ecosysteem. Hij is een serieel ondernemer. Hij heeft hiervoor een aantal bedrijven opgericht en daarom heten we Krishna van harte welkom voor dit gesprek over waarneembaarheid, wat wederom een ​​favoriet thema is in deze serie. 

Krishna Yadappanavar

Dank je.

Dinesh Chandrasekhar

Dus Krishna, om jezelf voor te stellen:waarom vertel je ons niet over Kloudfuse en je drive om het bedrijf te starten?

Krishna Yadappanavar (01:01):

Oké, absoluut. Bedankt, Dinesh. Bedankt voor de warme introductie. Hallo mensen, mijn naam is Krishna. Ja, ik woon al bijna twintig jaar in de Valley en heb met een aantal startups en grote bedrijven samengewerkt. De naam die beroemd is, lijkt op VMware toen het nog een vroege startup was. Ik werd lid en zag het groeien van letterlijk bijna een miljoen ERR naar een bedrijf van 64 miljard. Ik ben in verband gebracht met verschillende datagerelateerde technologieën, of het nu gaat om het schrijven van bestandssystemen, gedistribueerde systemen, databases of OLAP of OLTP. Oké, tijdens deze reis heb ik gemerkt dat data het geheim zijn van alle inzichten, of het nu gaat om de productanalyse of om het bieden van een oplossing zoals virtualisatie of het bieden van een oplossing zoals back-up of noodherstel. Nadat ik mijn startup Springpath had gedaan, die zich in de hyperconvergentie bevond, probeerde ik de convergentie van opslag, netwerken en beveiliging samen te brengen in een doos die ik aan Cisco verkocht.

En nadat ik enige tijd bij Cisco had doorgebracht, dacht ik:wat zijn de volgende grote trends die gaan komen? Dit is begin 2020. Ik kwam een ​​aantal trends tegen, zoals enkele trends die verband houden met hoe de gegevens met betrekking tot een ontwikkelaar DevOps of SecOps exponentieel groeien. Hoe zullen de nieuwe trends in de machine learning AI- en LLM-modellen van toen de LLM-modellen zich nog in de beginfase bevonden, de markt gaan ontwrichten? En als het menselijk brein dan begint te denken en te reageren op bepaalde incidenten, wil je dat de machines op dezelfde manier handelen. Dit waren enkele van de problemen die we tegenkwamen en op het kruispunt van alle drie ontdekte ik dat het oplossen van het probleem van niet alleen de waarneembaarheid, maar ook de waarneembaarheid plus analyse en automatisering, bovenop de gegevens, die gericht zijn op de ontwikkelaars en de DevOps, erg cruciaal is. Dat leidde tot het begin van de Kloudfuse. Het ene leidde tot het andere en we zijn nu een team van zo'n veertig mensen.

Dinesh Chandrasekhar (03:16):

Nou, gefeliciteerd en dit is een goed begin. Ik wens je dus veel succes op die reis. Over waarneembaarheid gesproken:dit was niet iets dat pas gisteren tot stand kwam. Ik heb ook een behoorlijke tijd in die ruimte gewerkt en het concept van waarneembaarheid is in de loop der jaren geëvolueerd. Dus oorspronkelijk 10, 12 jaar geleden waren mensen enthousiast over het praten over infrastructuurmonitoring, netwerkmonitoring en zo, en langzaam leidde het een tot het ander en toen kwamen er cloudmonitoring- en containermonitoringmogelijkheden bij. En dan hebben we vandaag de dag het idee van waarneembaarheid dat behoorlijk populair is. De meeste bedrijven die vroeger monitoring aanprezen, zijn nu observatiebedrijven. En ik weet dat je opnieuw bent begonnen op het gebied van waarneembaarheid en een verschil wilde creëren. Hoe zou jij deze evolutie omschrijven? Wat was vroeger vergeleken met wat we nu hebben? Hoe heb je deze evolutie gezien?

Krishna Yadappanavar (04:09):

Ja, goede vraag. Dinesh. Ik heb dit gezien, ik bedoel dat ik als ontwikkelaar zelf een monolithische applicatie schrijf die op fysieke machines draait. Toen zag ik de opkomst van virtualisatie, of het nu VMware of Hyper-V is of de open-source virtualisatietechnologieën, en de containerisatie kwam binnen. Dus als je naar de kernproblemen kijkt als het gaat om de data voor de observatie, terwijl deze evaluaties zijn geëvolueerd, hebben we gezien dat de attributen die aan de data zijn gekoppeld, blijven toenemen, en als je het cartesiaanse product van die attributen neemt, dan wordt het echt groot in de orde van meerdere miljoenen tot miljarden. Wat zij de kardinaliteit noemen die aan die kardinaliteit is gekoppeld, is het gegevensvolume. Naarmate het datavolume toeneemt, willen mensen data A transformeren naar data B voor betere analyses. Ze willen bepaalde workflows bovenop de data automatiseren.

Ze willen de gegevens in stukken snijden, zodat u betere inzichten kunt krijgen. Kortom, naarmate het datavolume toeneemt, was ik op de traditionele manier aan het monitoren, zoals het bekende bekende verdwijnt, wat de traditionele monitoring is. Dan kijk je naar de bekende onbekenden, wat het begin is van waarneembaarheid, en er zijn de volledig onbekende onbekenden waarbij je niets weet en je wordt geworpen op multi-terabyte tot petabytes aan gegevens en je moet binnen die gegevens ontleden en tot het gebrek aan een beter woord komen waar het probleem precies is, hoe het verband houdt met het incident, wat de analyse van de hoofdoorzaak is, wat de impactanalyse is. Dus zolang de ontwikkelaars code schrijven, komen deze complexiteit en steeds meer diensten eraan. Deze complexiteit zal steeds hoger worden en daarom blijft dit een evoluerende ruimte waar nieuwe uitdagingen ontstaan.

Dinesh Chandrasekhar (06:14):

Fantastisch. Waarneembaarheid is dus duidelijk een moeilijk op te lossen probleem. Ik zou graag willen onderzoeken waarom dat zo is? Maar ik denk dat je het zojuist ook een beetje hebt aangestipt, maar het is ook dat we een drukke markt hebben met dertien in een dozijn verkopers die zeggen:we lossen dit deel van de waarneembaarheid op en dat soort waarneembaarheid en zo, maar er is nog steeds een zoektocht naar de ideale oplossing. Dus elke CIO met wie ik praat, is altijd op zoek naar dat ene wondermiddel dat hun problemen oplost. Waarom is dat? Is er een andere lens waardoor je ernaar moet kijken om te begrijpen waarom er een andere drang is om tot die ideale oplossing te komen?

Krishna Yadappanavar (07:04):

Dus zoals ik al eerder aangaf, laat me een stapje terug doen, toch? Waar kijkt die klant naar als hij aan een ideale observatieoplossing denkt? Laten we beginnen bij het probleem. Ik classificeer dit probleem als de drie C’s:de kardinaliteit, controle en de kosten. Laat me ingaan op het volgende detailniveau. Wat betekenen deze drie C’s? Kardinaliteit, het gaat allemaal om hoe we bepaalde gegevens hebben, of het nu een lastig metrisch punt is of een loglijn of een gebeurtenis of een spoor of een spanwijdte afkomstig van de tracering van uw distributeur of het profiel van een doorlopend profiel, het wordt bijgevoegd met extra, bij gebrek aan een beter woord, labels of tags. Als je het cartesiaanse product neemt van de potentiële waarden die deze labels kunnen aannemen, zal het heel erg hoog worden. Dus nu moet elk datapunt aan zijn tags worden gekoppeld.

Laten we tags dus de metadata noemen. En dan zijn er nog gegevens. Verschillende schema's hebben verschillende problemen. Sommige zijn zwaar metagegevens. Als je naar de matrixsite gaat, als je naar de logs en de reeksen komt, zoals de gedistribueerde tracering, zijn ze als datazwaar, maar in feite is het de enorme toename van het volume van de waarneembaarheidsgegevens vanwege de kardinaliteit. Tegenwoordig zie ik de omgekeerde trend. Ik bedoel, vroeger dachten mensen van:Hé, laat me mijn gegevens naar een SaaS-portaal sturen en dan zou de SaaS-leverancier al die gegevens beheren. Maar als ik praat met de CTO of een CIO of een hoofd engineering of de ontwikkelaars of de architecten en zelfs de CFO, denken ze:laat mij de controle hebben over mijn gegevens. Wat bedoelen ze daarmee? Er is een omgekeerde trend gaande:ik heb om verschillende redenen zoveel gegevens, of het nu gaat om de risicokosten, de beveiligingsaspecten ervan of de hoeveelheid gegevens zelf.

Ze willen die gegevens niet buiten hun VPC verzenden en er zit een andere invalshoek aan. Ze willen alle mogelijke interfaces inbrengen die ze maar kunnen bedenken, of het nu gaat om een ​​traditionele interface van een observatorium, zoals het maken van dashboards, waarschuwingen, SLO's of andere analysefuncties die in een traditionele SQL of een GraphQL kunnen worden geschreven, of die geavanceerd kunnen zijn, zoals Spark-taken, om wat analyses uit te voeren bovenop de waarneembaarheidsgegevens, omdat waarneembaarheid die fundamentele pijler is geworden. Dat betekent dat zij eigenaar moeten zijn van de data. De gegevens mogen de VPC niet verlaten. Als ik het heb over de gegevens, de gegevens die worden opgenomen, de gegevens die worden opgevraagd en de gegevens die worden geanalyseerd, en, last but not least, de kosten. Als je naar een willekeurige leverancier gaat, of het nu een traditionele commerciële SaaS-leverancier is of een open source-component, en er zijn veel open source-oplossingen. De infrastructuurkosten, de kosten van de leverancier, zijn recht evenredig met de hoeveelheid gegevens, recht evenredig met het aantal zoekopdrachten en recht evenredig met het aantal gebruikers. Deze drie dingen zijn de problemen waarnaar een traditionele organisatie die op zoek is naar een ideale oplossing, een ideale waarneembaarheidsoplossing, op zoek is

Dinesh Chandrasekhar (10:24):

Kardinaliteit, controle en kosten. Ik denk dat ik daar dol op ben. De drie C's zijn een geweldige manier om naar de waarneembaarheidsruimte te kijken en hoe je afleidt wat belangrijk is voor de daadwerkelijke gebruikers, enzovoort. Nu we het toch over de kosten hebben, aangezien we het er al over gehad hebben, wil ik u deze vraag ook stellen. Vanuit mijn eigen persoonlijke ervaring, als ik met klanten heb gesproken die op zoek zijn naar een oplossing voor observatie, klagen ze vaak over:Hé, ik heb op elke afdeling minstens acht tot tien verschillende tools. Ik kijk vandaag naar misschien 30 tot 40 tools in de hele organisatie. Ik heb al veel kosten om jaar na jaar voor deze licenties te betalen. “Waarom wil ik nog een oplossing voor observatie”, is een tegenreactie die ik vroeger kreeg, toch? Dus ik ga u dezelfde vraag stellen nu u het kostenaspect hebt besproken. Hoe benader je die vraag met een CIO en overtuig je hem of vertel je hem waarom dit beter is dan het hebben van 30 of 40 verschillende tools?

Krishna Yadappanavar (11:23):

Oké, goede vraag. Laten we, om die vraag te beantwoorden, beginnen met het probleem waarom er sprake is van een wildgroei aan tools. Dus als je naar het hele ecosysteem kijkt, traditioneel waren sommige leveranciers, als ik de commerciële leveranciers neem, behoorlijk goed in bepaalde stromen. Als je naar logs gaat, kun je aan Splunk denken. Als je aan statistieken denkt, denk je aan Datadog. Dan binnen Google en alle FANG's van de wereld. Deze hele beweging van open source begon, vooral met de komst van Kubernetes, en toen kwamen dingen als Prometheus, OpenTelemetry en wat dan ook.

En er is een hele verschuiving gaande in de richting van en op weg naar de op open source gebaseerde oplossing. Wat betekent het? Dat betekent dat de ontwikkelaars, de architecten en de DevOps-jongens hun observatiegegevens in een open formaat willen opnemen. Dit betekent dat zelfs als ik een instrument kies om mijn code te instrumenteren of een agent inschakel om mijn gegevens te verzamelen, dat honderd procent open-source-compatibel zou moeten zijn. Dus toen de commerciële leveranciers hun agenten ook in open source gingen inzetten, wilden ze aan de querykant dat de hele visualisatie, de dashboarding en de waarschuwingen zouden worden aangestuurd door de open-source querytalen. Dat is de reden waarom PromQL, LockQL, TraceQL en OpenTelemetry opkomen. Ze proberen nu een andere open-source querytaal.

 Dus nu ben je in deze wereld waar je veel opties hebt. De klanten hebben al bepaalde leveranciers voor een bepaalde stroom uitgekozen.

Dan is er een open source-beweging en dan gebruiken verschillende teams verschillende infrastructuren. Sommige zijn gebaseerd op Kubernetes, sommige zijn gebaseerd op serverloos, sommige zijn gebaseerd op ECS, Fargate wat dan ook. Dat voegt dus een nieuwe dimensie toe en om de snelheid en flexibiliteit van de hele productlevering te bereiken, is CI/CD op dit kruispunt geëvolueerd om de problemen zeer snel op te lossen. Ze proberen te zoeken naar de scherpe oplossing en kiezen uiteindelijk voor de zeer scherpe oplossing. Dat is het moment waarop we, als ideale waarneembaarheidsoplossing, als ik mijn waarneembaarheidsstack voor mijn bedrijf zou starten, een stap terug zou doen en zou zien:als ik mijn MTTR en MTTD wil verminderen, moet ik alle eindstromen van de waarneembaarheidsgegevens verzamelen. Ga ik naar n verschillende leveranciers en kies n verschillende stromen, of ga ik naar een waarneembaar datameer waar ik alle stromen bij elkaar kan brengen, zodat de correlatie, de geavanceerde functies zoals detectie van uitschieters, afwijkingen en causaliteit relatief eenvoudiger worden? Dat zou een ideale oplossing zijn waarbij u alles kunt consolideren in een datameer waar u uw gegevens binnen uw locatie kunt bewaren.

Dinesh Chandrasekhar (14:18):

Fantastisch. En ik zou ook willen toevoegen dat ik het grotendeels eens ben met de kosten voor de verspreiding van tools, omdat ontwikkelaars hun eigen ding willen bouwen en ze ook veel open source-tools aan de mix hebben toegevoegd, maar het zijn ook aankopen op afdelingsniveau. Dus een IT-afdeling heeft het gevoel dat ik dit probleem kan oplossen, want laat mij een pleisteroplossing krijgen, laat mij dit hulpmiddel van de plank kopen en gebruiken. En na verloop van tijd beseften ze dat ze nog een stuk gereedschap aan het arsenaal hadden toegevoegd, zonder te beseffen dat ze door de bomen niet meer naar het bos keken. De CIO-gesprekken zijn dus altijd interessant en gaan over hoe je het aantal tools dat je binnen de onderneming hebt, kunt comprimeren of verminderen en één observatieplatform hebt dat over de afdelingen heen kijkt, over applicaties, infrastructuurcontainers en wat dan ook heen. 

Krishna Yadappanavar (15:08):

Absoluut. Dus ik wil daaraan toevoegen dat verschillende persona's in het bedrijf ook naar dezelfde gegevens kijken. Net als DevOps-ontwikkelaars kijken architecten allemaal naar de observatiegegevens met betrekking tot infrastructuur, containerisatietoepassingen en dergelijke. Met dezelfde logboeken. De jongens van SecOps proberen de gegevens te ontleden om te zoeken naar de beveiliging en de bedreigingen. Kijkend naar de vergelijkbare gegevens die uit de logboeken of de sporen komen. Zelfs de jongens van DataOps vragen zich af:Hé, hoe goed zijn mijn gegevensactiviteiten? En nu, met de komst van LLM, kijken zelfs de jongens van LLM Ops naar vergelijkbare gegevens om hun soort analyses uit te voeren. Er moet dus nog een consolidatie plaatsvinden. Dat is iets waar ik naar zou zoeken in een ideale observatieoplossing. Hoe breng ik alle verschillende persona's in een organisatie binnen, zodat ze de data uit hetzelfde zogenaamde datameer kunnen benutten.

Dinesh Chandrasekhar (16:05):

Echt het spreekwoordelijke ding met één ruit waar we allemaal naar hebben gestreefd. Het is dus een goede zaak. Dus ik wil iets anders bespreken dat je kort noemde toen je de vorige reactie uitlegde, namelijk het verminderen van MTTR, toch? Dus als primaire crux van waarneembaarheid gaat het niet alleen om het oplossen van problemen, maar ook om het verminderen van de MTTR, het verminderen van waarschuwingsgeluiden en dat soort statistieken. Het bespaart dus zeker SRE's en IT-ops dat ze hun haren moeten kloven en moeten uitzoeken waar het probleem zit, en dat alles als een belangrijke fundamentele vereiste om dit op te lossen. U hebt toegang nodig tot realtime gebeurtenissen terwijl ze plaatsvinden. Als er een logbestand is ingevoerd in een bepaalde applicatie of een bepaalde server over een kwaadaardige activiteit of iets dergelijks, dan heb je meteen toegang tot die gebeurtenis nodig, zodat je kunt begrijpen waar die anomalie zich bevindt, wat er in je infrastructuur gebeurt, waarom deze specifieke piek in een bepaalde geheugenthread of wat dan ook.

Dus je moet dat uitzoeken en om dat te laten gebeuren, heb je de mogelijkheid nodig om dit allemaal in realtime op te nemen. Data-onmiddellijkheid, wat een favoriete term van mij is het afgelopen jaar dat ik erover heb gesproken, en de versheid van data is hier van het allergrootste belang. Dit is waar we het over hebben, hoe actueel de gegevens zijn, hoe snel je dat specifieke probleem kunt oplossen of misschien zelfs iets kunt voorkomen dat gaat gebeuren in deze specifieke context van waarneembaarheid, vooral als je het hebt over honderden en duizenden servers die je in de gaten houdt en zo. Is het grotendeels afhankelijk van de opnamemechanismen? Omdat je sprak over TEL en andere soorten instrumentatietechnieken en dat soort dingen. Dus hoe zou je er anders over nadenken of ernaar kijken vanuit dit perspectief:hoe snel kan ik toegang krijgen tot realtime gegevens?

Krishna Yadappanavar (18:03):

Oké, nog een geweldig aspect van het observatieteam. Je hebt volkomen gelijk, Danesh. Dus de belangrijkste dimensie waar de observatiegegevens worden geconsumeerd, is hoe snel ik over de gegevens kan beschikken, op het moment dat de gegevens de bron van de gegevens hebben verlaten, of het nu uw applicatie is of uw infrastructuurcomponenten of uw platform, zoals open source-componenten en dat soort dingen. Dus als je kijkt naar hoe de industrie zich de afgelopen vijf tot tien jaar heeft ontwikkeld, zijn er realtime streamingdiensten en realtime databases verschenen. Als je naar de traditionele observatieoplossingen kijkt, bedoel ik dat ze die functionaliteit niet konden benutten omdat de technologie relatief ouder was. Met de komst van realtime streaming en realtime databases kunt u dus zo snel mogelijk toegang krijgen tot de gegevens. Dus dat is de maatstaf voor wat de recentheid van de gegevens wordt genoemd vanaf het moment dat ze de applicatie hebben verlaten totdat ze gemakkelijk opvraagbaar zijn, dat is het enige wat telt.

Dan is er dat aspect van:hé, ik heb alle gegevens. Hoe kan ik die gegevens in compartimenten verdelen? Hoe vind ik de relevante patronen die ik nodig heb om de hoofdoorzaak te achterhalen, is de volgende reeks problemen. Dat betekent dus dat ik gegevens van de ene gegevens naar de andere gegevens zou moeten kunnen transformeren. Hé, ik krijg een reeks logboeken. Kan ik snel een statistiek uit de logboeken bekijken? Ik krijg een reeks overspanningen. Kan ik naar een attribuut binnen dat bereik of een trace kijken om die gegevens te analyseren? Omdat deze kenmerken doorgaans gecorreleerd zijn en dat is hoe het foutopsporing plaatsvindt. Dat is dus de volgende dimensie. En dan is de derde dimensie de geavanceerde analyses. Kan ik naast die gegevens een aantal interessante statistische of grote taalmodellen meenemen om de gegevens te analyseren en de zogenaamde uitbijters in mijn systeem te vinden?

Kan ik de afwijkingen in mijn systeem vinden? Oké, kan ik het seizoensaspect van mijn gegevens bekijken? Kan ik mijn gegevens voorspellen op basis van wat ik in het verleden heb gezien? Het seizoensgebonden aspect van de gegevens? Dit noem ik dus allemaal het pakket van de geavanceerde analyses. Dus als je nadenkt over de algehele oplossing nadat de gegevens zijn opgelost, moet je nadenken over de gegevens als een eenheid van een steen en vervolgens hoe elke steen kan worden aangepast en vervolgens een reeks analysefuncties. En dan is het natuurlijk dat we moeten zeggen:hé, ik heb dit een keer geanalyseerd, kan ik het automatiseren? Dat wordt de natuurlijke uitbreiding van het geheel. Daarom hebben we, naast het drie C-probleem, klanten zien vragen hoe ik mijn observatiegegevens kan observeren, analyseren en automatiseren.

Dinesh Chandrasekhar (20:57):

Heel gaaf. Heel gaaf. En als onderdeel van uw antwoord noemde u ook het magische woord LLM's, grote taalmodellen. Ik bedoel dat je tegenwoordig geen gesprek meer kunt voeren zonder over GenAI LLM's te praten. Dus ik ben blij dat je het hebt genoemd, want ik zou je hier zeker naar kunnen vragen, wat LLM-waarneembaarheid is. Het lijkt erop dat dit plotseling een opkomende ruimte is, aangezien we overal een wildgroei aan LLM's hebben en mensen moeite hebben om te begrijpen hoe ze presteren, enzovoort. Dus vertel ons daarover. Het lijkt erop dat Kloufuse ook op dat front iets bouwt, toch? Vertel ons er dus meer over.

Krishna Yadappanavar (21:32):

Ik bedoel, ja. Ik bedoel fundamenteel het geheel, de LLM-modellen worden ingezet in verschillende gebruiksscenario's, toch? Wat het gebrek aan een beter woord betreft. De dynamiek van de gegevens verandert, vooral in de waarneembaarheidswereld zijn de gegevens zeer dynamisch. Het bouwen van het juiste LLM-model om bepaalde bewerkingen uit te voeren is altijd moeilijk. We hebben het probleem dus op twee manieren bekeken. Hoe kan ik bepaalde LLM-modellen gebruiken bovenop de bestaande observatiegegevens, die worden gebruikt door alle verschillende persona's waar ik het over had, of het nu DevOps of SecOps of DataOps-jongens zijn of de LLMops-jongens. Dat is het enige aspect ervan. En er is nog een ander aspect:ik ben een applicatie aan het ontwikkelen waarbij de LLM een heel, heel cruciaal onderdeel is. Hoe kijk ik naar de volledige waarneembaarheid van een applicatie die de gegevens produceert, die in de LLM worden ingevoerd, en dan zijn er veel consumenten die die gegevens uit die LLM-modellen gebruiken.

We denken dus aan, ik kan zeggen dat wij de eersten zijn die nadenken over wat de werkelijke waarneembaarheid is voor alle toepassingen die zijn ontwikkeld met behulp van de LLM-modellen. Omdat ik veel oplossingen ben tegengekomen die alleen maar naar de waarneembaarheid van het model kijken, zoals drift en dat soort dingen. Maar we kijken van begin tot eind. Dat is een heel interessant aspect, omdat veel waarneembaarheid van infrastructuurapplicaties samengaat met de waarneembaarheid van modellen en de rest van de dingen. En als laatste, maar daarom niet minder belangrijk, als je een CIO of CFO vraagt:de kosten van de LLM zijn, net als de huidige oplossingen, een andere belangrijke dimensie. Hoe je die kosten kunt behouden of zelfs maar analyses kunt maken van de kostenstatistieken van de LLM-modellen zelf is een ander aspect ervan. Je moet dus naar alles kijken:prestaties, gebrek aan, laten we het een APM voor LLM-applicaties noemen, en dan de kosten. Dit zijn dus de typische afmetingen waar je naar zou kijken.

Dinesh Chandrasekhar

Een hele coole, opwindende ruimte en ik ben absoluut enthousiast over wat er de komende maanden in die ruimte gaat gebeuren. Dus heel erg bedankt, Krishna. Dit was een heel, heel mooi gesprek. Ik vond het leuk om je in onze show te hebben. Ik hou ervan om over waarneembaarheid te praten. Ik ga uw drie C’s onthouden:kardinaliteit, controle en kosten. Ik vind het een geweldige manier, een geweldige mantra om naar waarneembaarheid te kijken. Bedankt dus voor alle inzichten. Ik waardeer het dat je hier bent. Dank je.

Krishna Yadappanavar

Hartelijk dank, Dinesh. Bedankt dat je mij op je webchat hebt.