Smart Talk Episode 7: Cardinality, Control en Costs in Observability navigeren

We hebben observability en de complementaire ruimte van AIOps een paar keer in deze serie besproken, maar deze keer duiken we pragmatischer in het onderwerp om de mentaliteit van de koper te begrijpen. Wat moet een CIO van een organisatie zoeken wanneer ze op de markt zijn voor een observability-oplossing? Doe mee aan deze aflevering terwijl Dinesh Chandrasekhar, Chief Analyst en Founder van Stratola, praat met Krishna Yadappanavar, CEO van Kloudfuse. Krishna verduidelijkt observability door de lens van drie factoren – Cardinality, Control en Costs.
Deze 3 Cs zijn cruciaal om ooit toenemende observability-data te begrijpen en te managen. Deze factoren zijn niet alleen belangrijk voor het managen van de data maar ook voor het benutten van de data en meta-data voor additionele analytics.
Een nieuwe ontwikkeling in het veld van observability is model observability, met name de LLMs die generatieve AI drijven. De 3 Cs gelden ook voor deze opkomende use case.

Onderwerpen die in deze aflevering van Smart Talk behandeld worden:

• Potentieel van observability-data
• Tools-proliferatie
• Siloed observality-data overwinnen
• Metadata in overweging nemen
• Inzicht in kosten

Gast
Krishna Yadappanavar, CEO, Kloudfuse
Krishna Yadappanavar is de Co-Founder en CEO van Kloudfuse, een unified observability platform. Hij co-foundeerde eerder SpringPath, $94 miljoen aan financiering wervend en het bedrijf leidend tot een $320 miljoen overname door Cisco. Met meer dan 20 octrooien heeft Krishna data, virtualisatie en storage-technologieën bij Veritas, Commvault, EMC, VMware en Cisco significant beïnvloed. Hij co-auteurde VMware's VMFS en ontwierp kritieke componenten van de storage-virtualisatiestack voor ESX Server. Daarnaast adviseert en investeert Krishna in opkomende startups over Data, Virtualisatie, Cloud, Beveiliging en AI/ML, bijdragend aan visie, productstrategie, engineering en go-to-market-inspanningen.

Host: Dinesh Chandrasekhar is een technology evangelist, thought leader en ervaren IT-industrie-analist. Met bijna 30 jaar ervaring heeft Dinesh gewerkt aan B2B enterprise software en SaaS-producten die geavanceerde oplozingen leveren en markten voor klanten met complexe architecturen. Hij heeft ook highly successful GTM-strategieën gedefinieerd en uitgevoerd om verschillende high-growth producten op de markt te brengen bij bedrijven als LogicMonitor, Cloudera, Hortonworks, CA Technologies, Software AG, IBM etc. Hij is een prolific spreker, blogger en weekend-coder. Dinesh heeft een MBA-graad van Santa Clara University en een Master in Computer Applications van de Universiteit van Madras. Momenteel runt Dinesh zijn eigen bedrijf, Stratola, een klantgerichte business strategy consulting en full-stack marketing services firma.

Bronnen
Smart Talk Episode 6: AIOps en de Toekomst van IT Monitoring
Smart Talk Episode 5: Disaggregatie van de Observability Stack
Smart Talk Episode 4: Real-Time Data en Vector Databases
Smart Talk Episode 3: Moderne Data Pipelines en LLMs
Smart Talk Episode 2: De Opkomst van GenAI Applicaties met Data-in-Motion
Smart Talk Episode 1: Het Data-in-Motion Ecosysteem Landschap
Bekijk de data-in-motion ecosystem map hier
Leer meer over data-in-motion op RTInsights hier

Transcript
Dinesh Chandrasekhar

Hallo en welkom bij deze aflevering van Smart Talk, een Data in Motion leadership serie. En in deze aflevering hebben we een speciale gast, Krishna Yadappanavar. Hij is de CEO van Cloud Fuse. Hij is geen vreemde voor het startup-ecosysteem. Hij is een serial entrepreneur. Hij heeft een paar bedrijven voor dit gebouwd, en dus verwelkomen we Krishna warm om dit gesprek over observability te voeren, wat weer een favoriet thema in deze serie is.

Krishna Yadappanavar

Dank je.

Dinesh Chandrasekhar

Dus Krishna, als manier van je voorstellen, waarom vertel je ons niet over Kloudfuse en jouw drijfveer om het bedrijf op te richten?

Krishna Yadappanavar (01:01):

Oké, absoluut. Dank je, Dinesh. Dank je voor de warme introductie. Hallo iedereen, mijn naam is Krishna. Ja, ik woon al bijna twee-plus decennia in de Valley en heb gewerkt met een boel startups en grote bedrijven. De claim to fame is zoals VMware toen het een vroege startup was. Ik trad toe en zag het groeien van letterlijk bijna een miljoen ARR tot een 64 miljard bedrijf en ik ben geassocieerd met verschillende data-gerelateerde technologieën, of het nu is bestandsystemen schrijven, gedistribueerde systemen, databases of OLAP of OLTP. Oke, door deze reis heen wat ik opmerkte is dat data het geheim is van alle inzichten, of het nu is op de product analytics-kant of het is een oplossing leveren zoals virtualisatie of een oplossing leveren zoals backup of disaster recovery. Mijn startup, Springpath, gedaan, wat in de hyperconvergentie zat, probeerde de convergentie van storage, networking, security altogether in a box te brengen, ik verkocht aan Cisco.

En na wat tijd bij Cisco door te brengen, dacht ik wat zijn de volgende grote trends die gaan komen? Dit is terug in early 2020. Ik kwam een paar trends tegen, zoals sommige trends gerelateerd aan hoe de data met betrekking tot een developer DevOps of SecOps exponentieel groeit. Hoe de nieuwe trends in machine learning AI en LLM-modellen toen LLM-modellen in de vroege stadia waren de markt gaan disrupteren? En dan als de menselijke hersenen begint te denken en te reageren op bepaalde incidenten, wil je dat machines op een vergelijkbare manier handelen. Dit waren enkele van de problemen die we tegenkwamen en in het snijpunt van alle drie, vond ik dat hey, het oplossen van het probleem van niet alleen de observability, maar observability plus analytics en automation, bovenop de data, wat gefocust is op de developers en de DevOps, is heel kritiek. Dat leidde tot het begin van Kloudfuse – een leidde tot de andere en dan zijn we een team van ongeveer 40 plus mensen nu.

Dinesh Chandrasekhar (03:16):

Gefeliciteerd en dit is een geweldige start. Dus wens je geluk op die reis. Praten over observability, dit was niet iets dat net gisteren ontstond. Ik werkte in die ruimte ook voor een behoorlijke hoeveelheid tijd en het concept van observability heeft zich over de jaren ontwikkeld. Dus oorspronkelijk 10, 12 jaar geleden waren gehyped over praten over infrastructuur-monitoring, netwerk-monitoring en al dat, en dan langzaam leidde een ding tot het andere en dan waren er cloud-monitoring en container-monitoring capabilities die erbij kwamen. En dan vandaag hebben we deze notion van observability die vrij populair is. Meeste bedrijven die monitoring uithingen zijn nu observability-bedrijven. En ik weet dat je vanaf nul in de observability-ruimte begon om een verschil te maken. Hoe zou je deze evolutie beschrijven? Wat was ervoor vergeleken met wat we vandaag hebben? Hoe heb je deze evolutie gezien?

Krishna Yadappanavar (04:09):

Ja, geweldige vraag. Dinesh. Ik heb dit gezien, ik bedoel als developer mezelf een monolithische applicatie schrijfend draaiend in fysieke machines. Toen zag ik het avontuur van virtualisatie, of het nu is als VMware of Hyper-V of de open-source virtualisatietechnologieën en containerisatie kwam erin. Dus als je kijkt naar de kernproblemen wanneer het aankomt op de data voor de observability, naarmate deze evaluaties geëvolueerd zijn, dus hebben we gezien dat de attributen geassocieerd met de data blijft toenemen, en als je de Cartesische product van die attributen neemt, dan wordt het echt groot in orde van meerdere miljoenen tot miljarden. Wat ze noemen als de cardinality geassocieerd met die cardinality is het datavolume. Naarmate het datavolume toeneemt, willen mensen data A transformeren naar data B voor betere analytics. Ze willen bepaalde workflows automatiseren bovenop de data.

Ze willen de data slicen en dicen zodat het je betere inzichten kan geven. Kortom, naarmate het datavolume toeneemt, verdwijnt de traditionele manier van, hey, ik was monitoring so-called as the known knowns, wat de traditionele monitoring is. Dan kijk je naar de known unknowns, wat het begin is van observability en er zijn de complete unknown unknowns waar je niets weet en je wordt gegooid met multi-terabyte tot petabytes aan data en je moet daarin dissecteren en komen tot het gebrek aan beter woord waar precies het probleem is, hoe het gecorreleerd is met het incident, wat is de root cause analyse, wat is de impact analyse. Zolang developers code schrijven, deze complexiteit en meer en meer services komen. Deze complexiteit gaat hoger en hoger en dus blijft dit een evolutieruimte waar nieuwe uitdagingen opduiken.

Dinesh Chandrasekhar (06:14):

Fantastisch. Dus observability is duidelijk een moeilijk probleem op te lossen. Ik zou graag willen verkennen waarom dat zo is? Maar ik denk dat je er net op heen wees net nu, maar het is ook dat we een crowded marketplace hebben met een dime-a-dozen vendors die zeggen, we lossen dit deel van observability op en dat soort observability en al dat, maar er is nog steeds een zoektocht naar de ideale oplossing. Dus elke CIO die ik spreek zoekt altijd naar deze ene magic bullet die hun problemen oplost. Waarom is dat? Is er een andere lens door je moet kijken om te begrijpen waarom er een andere urge is om die ideale oplossing te krijgen?

Krishna Yadappanavar (07:04):

Dus zoals ik eerder aankeek laten we even een stapje teruggaan, toch? Wat is die klant zoekt als ze denken aan een ideale observing-oplossing? Laten we beginnen bij het probleem. Ik classificeer dit probleem als de drie Cs – de Cardinality, Control, en de Cost. Laten we in het volgende detailniveau gaan. Wat betekenen deze drie Cs? Cardinality, het gaat allemaal om hoe we bepaalde data hebben, of het nu een tricky metric point is of een logline of een event of een trace of een span afkomstig van je distributed tracing of een continuous profile's profile, het wordt bijgelaagd met additionele, voor gebrek aan een beter woord, labels of tags. Wanneer je het Cartesische product neemt van de potentiële waarden die die labels kunnen aannemen, groeit het echt, echt hoog. Dus nu heeft elk datapunt zijn tags nodig.

Laten we tags noemen als de metadata. En dan is er data. Verschillende schema's hebben verschillende problemen. Sommige zijn metadata-zwaar. Wanneer je naar de matrix-site gaat, wanneer je komt bij de logs en de spans zoals distributed tracing, zijn ze als data-zwaar, maar in effect is het de enorme toename in het volume van de observability-data door de cardinality. Tegenwoordig heb ik de reverse trend gezien. Ik bedoel terug in de dagen dachten mensen zoals, Hey, laat me mijn data naar een SaaS-portaal sturen en dan zou de SaaS-vendor al die data managen. Maar als ik praat met of het nu de CTO of een CIO of een head of engineering of de developers of de architects en zelfs de CFO, ze denken, laat me controle hebben over mijn data. Wat bedoelen ze daarmee? Er is een reverse trend gaande die ik zoveel data heb om verschillende redenen, of het nu is de egress-kosten, de beveiligingsaspecten ervan, of het volume van de data zelf.

Ze willen die data niet buiten hun VPC sturen en er is nog een hoek. Ze willen alle mogelijke interfaces meenemen die ze kunnen bedenken of het nu is voor een traditionele observatory-achtige interface zoals dashboards creëren, alerts, SLO's, of enige analytics-functies die in een traditionele SQL of een GraphQL geschreven kunnen zijn of er kunnen geavanceerde zijn zoals Spark-jobs om enkele analytics bovenop de observability-data te draaien omdat observability die fundamentele pilaar is geworden. Dat betekent dat ze de data moeten bezitten. De data mag de VPC niet verlaten. Wanneer ik de data zeg, de data die wordt geïngest, de data die gequeryd wordt, en de data die geanalyseerd wordt, en last but not least, is de kost. Als je naar enige vendor gaat daarbuiten, of het nu is een traditionele SaaS-commerciële vendor of een open source-component, en er zijn veel open source-oplossingen daarbuiten. De infrastructuurkost, de kost van de vendor is direct evenredig aan het volume van data, direct evenredig aan het aantal queries, en direct evenredig aan het aantal gebruikers. Die drie dingen zijn de problemen die een traditionele organisatie die zoekt naar een ideale oplossing, een ideale observability-oplossing zoekt.

Dinesh Chandrasekhar (10:24):

Cardinality, control, en costs. Ik denk dat ik dat leuk vind. De drie Cs zijn een geweldige manier om te kijken naar de observability-ruimte en hoe je afleidt wat belangrijk is voor de daadwerkelijke gebruikers en zo voort. Praten over kosten, aangezien we het erover hadden, wil ik je deze vraag ook stellen. Uit mijn eigen persoonlijke ervaring, toen ik met klanten sprak die op zoek waren naar een observability-oplossing, wat ze vaak klagen over is als, Hey, ik heb minstens acht tot 10 verschillende tools in elke afdeling die ik heb. Ik kijk naar misschien 30 tot 40 tools over de organisatie heen vandaag. Ik heb al veel kosten betaald voor deze licenties jaar na jaar. „Waarom wil ik nog een observability-oplossing,“ is een pushback die ik krijg, toch? Dus ik ga diezelfde vraag nu aan jou stellen nu je de kostenaspect hebt aangeraakt. Hoe benader je die vraag met een CIO en overtuig ze of vertel ze waarom dit beter is dan 30 of 40 verschillende tools hebben?

Krishna Yadappanavar (11:23):

Oké, geweldige vraag. Om die vraag te beantwoorden, laten we beginnen met het probleem van waarom er tool-proliferatie is. Dus als je kijkt naar het gehele ecosysteem, traditioneel sommige vendors, als ik de commerciële vendors neem, waren ze pretty good in bepaalde streams. Als je naar logs gaat, kun je aan Splunk denken. Als je aan metrics denkt, denk je aan Datadog. Dan binnen Google en alle FANGs van de wereld. Deze hele beweging van open source begon, met name met het avontuur van Kubernetes, toen kwamen dingen als Prometheus, OpenTelemetry, en wat niet.

En er is deze hele shift gaande naar en moving to the open-source based solution. Wat betekent dat? Dat betekent dat de developers, de architects, de DevOps-mensen hun observability-data in een open formaat willen ingesten. Betekent, zelfs als ik enige instrumentatie kies om mijn code te instrumenteren of enige agent om mijn data te verzamelen, dat zou 100% open-source-compatibel moeten zijn. Dus dat is waarom toen de commerciële vendors ook hun agents in open source begonnen te zetten, dan aan de query-kant, willen ze de hele visualisatie, het dashboarden, alerting – al deze capabilities gedreven worden door de open-source query-talen. Dat is waarom de opkomst van PromQL, LockQL, TraceQL, OpenTelemetry, ze proberen nu nog een open-source query-taal.

Dus nu ben je in deze wereld waar je veel opties hebt. De klanten hebben al bepaalde gekozen voor bepaalde stream, bepaalde vendors.

Dan is er een open source-beweging en dan gebruiken verschillende teams verschillende infrastructures. Sommige zijn gebaseerd op Kubernetes, sommige op serverless, sommige op ECS, Fargate wat niet. Dus dat voegt een andere dimensie toe en om te komen tot de snelheid en de wendbaarheid van de hele productlevering, heeft CI/CD zich in dit snijpunt ontwikkeld om de problemen heel snel op te lossen. Ze proberen naar de pointed solution te kijken en dus eindigen ze met de erg pointed solution te kiezen. Dat is wanneer we als een ideale observability-oplossing, als ik mijn observability-stack voor mijn bedrijf zou starten, ik zou een stapje teruggaan en kijken als, hey, als ik mijn MTTR en MTTD wil verminderen, heb ik alle eind-stromen van de observability-data nodig. Ga ik naar n verschillende vendors en kies n verschillende streams, of ga ik naar een observability data lake waar ik alle streams samen kan zetten zodat de correlatie, de geavanceerde functies als outlier detection, anomalies, causation relatief makkelijker wordt? Dat zou een ideale oplossing zijn waar je alles in een data lake kunt consolideren waar je je data binnen je eigen premises kunt bewaren.

Dinesh Chandrasekhar (14:18):

Fantastisch. En ik zou ook willen toevoegen dat de kost voor tool-proliferatie, ik ben het er grootendeels mee eens omdat developers hun eigen ding willen bouwen en ze hebben veel open source-tooling aan de mix toegevoegd, maar het is ook department-level aankopen. Dus een IT-afdeling voelt als ik dit probleem kan oplossen omdat laat me een band-aid oplossing halen, laat me deze tool van de plank kopen en gebruiken. En dan over tijd realiseerden ze zich dat ze er nog een tool aan het arsenal toegevoegd hebben zonder te realiseren dat ze niet naar het bos kijken voor de bomen. Dus de CIO-gesprekken zijn altijd interessant en over hoe je het aantal tools over het enterprise kunt compacten of reduceren en één observability-platform hebt dat over de afdelingen kijkt, over applicaties, infrastructuur containers, en wat niet.

Krishna Yadappanavar (15:08):

Absoluut. Dus ik bedoel om toe te voegen aan dat nu verschillende personas in het bedrijf ook naar dezelfde data kijken. Als DevOps developers, architects kijken allemaal naar de observability-data met betrekking tot infrastructuur, containerisatie applicaties, en wat niet. Met dezelfde logs. De SecOps-mensen proberen de data te dissecteren om te zoeken naar beveiliging en dreigingen. Kijken naar de vergelijkbare data afkomstig van de logs of de traces. Zelfs de DataOps-mensen kijken als, Hey, hoe goed zijn mijn data-operaties? En nu met het avontuur van LLM, zelfs de LLM Ops-mensen kijken naar de vergelijkbare data om hun soort analytics te doen. Dus er is een andere consolidatie die moet gebeuren. Dat is een ding waar ik naar zou kijken in een ideale observability-oplossing. Hoe breng ik al de verschillende personas in een organisatie zodat ze de data van de dezelfde so-genoemde data lake kunnen benutten.

Dinesh Chandrasekhar (16:05):

Waarachtig de proverbiale single pane of glass die we alle nastreven. Dus het is een goed ding. Dus ik wil een ander ding aanraken dat je kort noemde toen je het vorige antwoord uitlegde, wat was over het verminderen van MTTR, toch? Dus als een primaire kern van observability, gaat het niet alleen om troubleshooting maar ook het verminderen van MTTR, alert noise verminderen en die soorten metrics ook. Dus het bespaart zeker SREs en IT Ops om haren te splitsten en uit te zoeken waar het probleem zit en al dat als een key fundamentale vereiste voor het oplossen van dit. Je hebt toegang nodig tot real-time events zoals ze gebeuren. Als er een log is die in een bepaalde applicatie of een bepaalde server is gegaan over een malicious activiteit of zo, heb je toegang tot dat event direct toen en daar zodat je kunt begrijpen waar die anomaly zit, wat er gaande is over je infrastructuur, waarom deze specifieke piek in een specifieke memory-thread of wat dan ook.

Dus je moet dat uitvinden en om dat te laten gebeuren, heb je de mogelijkheid nodig om al dit in real-time te ingesten ook. Data immediatecy, wat een favoriete term van mij is over het afgelopen jaar, ik heb erover gepraat, en data freshness is van prime importance hier. Dit is waar we over praten, hoe vers de data is, is hoe snel je dat specifieke probleem kunt oplossen of misschien zelfs iets afwenden dat over het punt staat te gebeuren in deze specifieke context van observability, met name als je het hebt over honderden en duizenden in een servers die je monitor en al dat, of waar duid je aan zeggend, hier is waar het probleem zit in termen van hoe snel kan ik toegang krijgen tot realtime data? Is het grotendeels afhankelijk van de ingestie-mechanismen? Omdat je sprak over OTEL en andere typen instrumentatietechnieken en al dat ook. Hoe anders zou je erover nadenken of ernaar kijken vanuit dit perspectief van hoe snel kan ik toegang krijgen tot realtime data?

Krishna Yadappanavar (18:03):

Oké, nog een geweldig aspect van het observe-team, je hebt absolutelijk gelijk, Danesh. Dus de sleuteldimensie waar de observatieve data wordt geconsumeerd is hoe snel kan ik de data hebben, het moment dat de data heeft verlaten van de bron van de data, of het nu is jouw applicatie of jouw infrastructuur-componenten of jouw platform als open source-componenten en dingen als die. Dus daarvoor, als je kijkt hoe de industrie geëvolueerd is in de laatste vijf tot 10 jaar of zo, zijn realtime streaming services, realtime databases gekomen. Als je kijkt naar de traditionele observ-oplossingen, ik bedoel ze konden die functionaliteit niet benutten omdat de technologie relatief ouder was. Dus met het avontuur van de realtime streaming en de realtime databases, kun je toegang krijgen tot de data zo snel mogelijk. Dus dat is de maat van wat genoemd wordt als een freshness van de data vanaf het moment dat het de applicatie heeft verlaten tot het readily queryable is, dat is wat allemaal uitmaakt.

Dan is er dat aspect van zoals, hey, ik heb al de data. Hoe compartmentaliseer ik die data? Hoe vind ik de relevante patronen die ik nodig heb om tot de root cause te komen is de volgende set van de problemen. Dus dat betekent dat ik in staat zou moeten zijn om data één data te transformeren naar de andere data. Hey, ik krijg een reeks logs. Kan ik snel een metric uit de logs kijken? Ik krijg een reeks spans. Kan ik een attribuut binnen die span of een trace bekijken om die data te analyseren? Omdat deze attributen typisch gecorreleerd zijn en dat is hoe het debuggen gebeurt. Dus dat is de volgende dimensie. En dan de derde dimensie is de geavanceerde analytics. Bovenop die data, kan ik enkele interessante statistische of de large language models brengen om de data te analyseren om te vinden wat genoemd wordt de outliers in mijn systeem?

Kan ik de anomalies in mijn systeem vinden? Oke, kan ik in het seasonaliteit-aspect van mijn data kijken? Kan ik mijn data voorspellen gebaseerd op wat ik heb gezien uit het verleden? Het seizoensaspect van de data? Dus al deze is wat ik noem als het pakket van de geavanceerde analytics. Dus als je denkt aan de overall-oplossing na de freshnes van de data opgelost is, moet je denken over de data als een unit van een brick en dan hoe elke brick aangepast kan worden en dan set van analytics-functie. En dan het natuurlijke ding dat we zullen nodig hebben is als, hey, ik heb dit een keer geanalyseerd, kan ik het automatiseren? Dat wordt de natuurlijke extensie van het hele ding. Dus dat is waarom langs de drie Cs-probleem, we hebben de klanten gezien vragen hoe kan ik observeren, analyseren en automatiseren mijn observerende data.

Dinesh Chandrasekhar (20:57):

Heel cool. Heel cool. En dan als deel van je antwoord, noemde je ook het toverwoord LLMs, large language models. Ik bedoel deze dagen kun je geen gesprek hebben zonder over GenAI LLMs te praten. Dus ik ben blij dat je het noemde omdat ik je daar zeker over kon vragen, wat is LLM-observability. Het lijkt alsof dat een emerging-ruimte is plotseling gegeven dat we een proliferatie van LLMs overal hebben en mensen worstelen met begrijpen hoe ze performen en zo voort. Dus vertel ons over dat. Het lijkt alsof Kloufuse ook iets op die front bouwt, toch? Dus vertel ons meer over het.

Krishna Yadappanavar (21:32):

Ik bedoel, ja. Ik bedoel fundamenteel de hele, de LLM-modellen worden gedeployed in verschillende use cases, toch? Als voor gebrek aan beter woord. De dynamiek van de data verandert, met name in de observability-wereld, de data is heel dynamisch. Het bouwen van het juiste LLM-model om bepaalde operaties te doen is altijd hard. Dus we hebben naar het probleem op twee manieren gekeken. Hoe kan ik bepaalde LLM-modellen benutten bovenop de bestaande observability-data, wat wordt geconsumeerd door alle verschillende personas die ik besprak, of het nu is DevOps of SecOps of DataOps-mensen of de LLMOps-mensen. Dat is het ene aspect ervan. En er is het andere aspect van, hey, ik ontwikkel een applicatie waar de LLM een heel, heel kritisch component is. Hoe kijk ik naar de complete observability van een applicatie die de data produceert, wat in de LLM wordt gevoed, en dan zijn er veel consumenten die die data consumeren van die LLM-modellen.

Dus we denken aan, in feite, ik kan zeggen dat we de eerste zijn om end-to-end te denken over wat de echte observability is voor alle applicaties die ontwikkeld worden met de LLM-modellen. Omdat ik tegen veel oplozingen ben aangekomen die gewoon kijken naar de model-observability zoals drift en dingen als die. Maar we kijken end-to-end. Dat is een heel interessant aspect omdat veel infrastructuur-applicatie-observability mee gaat met de model-observability en de rest van de dingen. En dan last but not the least, als je gaat en vraagt aan enige CIO of de CFO, de kost van de LLM, zoals de huidige oplozingen, de kost is een andere key-dimensie. Hoe houd je die kost in of bied je enige analytics op de kost-metrics van de LLM-modellen zelf is een ander aspect ervan. Dus je moet in alles kijken: performance, gebrek aan, laten we het een APM noemen voor LLM-applicaties, en dan de kost. Dus dit zijn de typische dimensies waar je naar zou kijken.

Dinesh Chandrasekhar

Heel cool, spannende ruimte en ik ben zeker geenthousiasteerd over leren wat er in die ruimte in de komende paar maanden komt. Dus dank je wel, Krishna. Dit is een heel, heel geweldig gesprek geweest. Genoten van je op onze show. Liefs praten over observability. Ik ga je drie Cs onthouden: Cardinality, Control, en Costs. Ik denk dat het een geweldige manier is, geweldige mantra om naar observability te kijken. Dus dank je voor alle inzichten. Waardeer je hier te zijn. Dank je.

Krishna Yadappanavar

Dank je wel, Dinesh. Dank je voor me op je webchat te hebben.