Smart Talk Episode 7: Cardinality, Control und Kosten in Observability meistern

Wir haben Observability und den komplementären Bereich AIOps bereits ein paar Mal in dieser Serie besprochen, aber diesmal tauchen wir pragmatischer in das Thema ein, um die Käufer-Mentalität zu verstehen. Wonach sollte ein CIO suchen, wenn er auf dem Markt für eine Observability-Lösung ist? Begleiten Sie uns in dieser Episode, während Dinesh Chandrasekhar, Chief Analyst und Founder von Stratola, mit Krishna Yadappanavar, CEO von Kloudfuse, spricht. Krishna erklärt Observability durch die Linse von drei Faktoren – Cardinality, Control und Costs. Diese 3 Cs sind der Schlüssel zum Verständnis und Management immer weiter wachsender Observability-Daten. Diese Faktoren sind nicht nur wichtig für das Datenmanagement, sondern auch für die Nutzung von Daten und Metadaten für zusätzliche Analytik.

Eine neue Entwicklung im Bereich Observability ist Model Observability – besonders die LLMs, die generative KI antreiben. Die 3 Cs gelten auch für diesen aufstrebenden Use Case.

Einige der in dieser Smart-Talk-Episode behandelten Themen:

• Potenzial von Observability-Daten
• Tool-Proliferation
• Überwindung siloierter Observability-Daten
• Metadaten berücksichtigen
• Einblick in Kosten

Gast
Krishna Yadappanavar, CEO, Kloudfuse
Krishna Yadappanavar ist Co-Founder und CEO von Kloudfuse, einer unified Observability-Plattform. Er gründete zuvor SpringPath, sicherte 94 Millionen Dollar Funding und führte das Unternehmen zu einer 320-Millionen-Dollar-Akquisition durch Cisco. Mit über 20 Patenten hat Krishna Daten-, Virtualisierungs- und Speichertechnologien bei Veritas, Commvault, EMC, VMware und Cisco maßgeblich beeinflusst. Er co-authored VMware's VMFS und entwarf kritische Komponenten des Storage-Virtualization-Stacks für ESX Server. Zudem berät und investiert Krishna in aufstrebende Startups across Data, Virtualization, Cloud, Security und AI/ML – und trägt zu Vision, Produktstrategie, Engineering und Go-to-Market bei.

Moderator: Dinesh Chandrasekhar ist Technologie-Evangelist, Thought Leader und erfahrener IT-Industrieanalyst. Mit fast 30 Jahren Erfahrung arbeitete er an B2B-Unternehmenssoftware und SaaS-Produkten, die anspruchsvolle Lösungen für Kunden mit komplexen Architekturen liefern. Er definierte und führte hocherfolgreiche GTM-Strategien aus, um mehrere High-Growth-Produkte bei Unternehmen wie LogicMonitor, Cloudera, Hortonworks, CA Technologies, Software AG, IBM usw. auf den Markt zu bringen. Er ist ein produktiver Sprecher, Blogger und Wochenend-Coder. Dinesh hat einen MBA von der Santa Clara University und einen Master in Computer Applications von der University of Madras. Derzeit führt er sein eigenes Unternehmen Stratola, eine kundenorientierte Business-Strategie-Beratung und Full-Stack-Marketing-Services-Firma.

Ressourcen
Smart Talk Episode 6: AIOps und die Zukunft des IT-Monitorings
Smart Talk Episode 5: Disaggregation des Observability Stacks
Smart Talk Episode 4: Echtzeitdaten und Vektordatenbanken
Smart Talk Episode 3: Moderne Data Pipelines und LLMs
Smart Talk Episode 2: Der Aufstieg von GenAI-Anwendungen mit Data-in-Motion
Smart Talk Episode 1: Die Data-in-Motion-Ökosystem-Landschaft
Data-in-Motion-Ökosystem-Map hier ansehen
Mehr über Data-in-Motion auf RTInsights hier erfahren

Transkript
Dinesh Chandrasekhar:

Hallo und willkommen zu dieser Episode von Smart Talk, einer Data-in-Motion Leadership Series. In dieser Episode haben wir einen besonderen Gast, Krishna Yadappanavar. Er ist CEO von Kloudfuse. Er ist der Startup-Ökosystem nicht fremd. Er ist ein Serial Entrepreneur. Er hat vor diesem ein paar Unternehmen gebaut, und so heißen wir Krishna herzlich willkommen zu diesem Gespräch über Observability – wieder ein Lieblingsthema in dieser Serie.

Krishna Yadappanavar:
Danke.

Dinesh Chandrasekhar:
Also Krishna, zur Einführung: Warum erzählen Sie uns nicht von Kloudfuse und Ihrer Motivation, das Unternehmen zu gründen?

Krishna Yadappanavar (01:01):
Okay, absolut. Danke, Dinesh. Danke für die warme Einführung. Hi Leute, ich bin Krishna. Ja, ich lebe seit fast zwei Jahrzehnten im Valley und habe mit einer Reihe von Startups und großen Unternehmen gearbeitet. Der Name, der Ruhm brachte, war VMware, als es ein frühes Startup war. Ich trat bei und sah es wachsen von buchstäblich nahe einer Million ARR zu einem 64-Milliarden-Unternehmen. Ich war mit verschiedenen datenbezogenen Technologien assoziiert – ob Dateisysteme schreiben, verteilte Systeme, Datenbanken oder OLAP oder OLTP. Okay, durch diese Journey hinweg fiel mir auf: Daten sind das Geheimnis aller Insights – ob auf der Produkt-Analytics-Seite oder bei der Bereitstellung einer Lösung wie Virtualisierung oder Backup oder Disaster Recovery. Nachdem ich mein Startup Springpath gemacht hatte, das im Hyperconvergence-Bereich war – versuchte, Speicher, Netzwerk, Sicherheit altogether in einer Box zusammenzubringen – verkaufte ich an Cisco.

Und nach einiger Zeit bei Cisco dachte ich: Was sind die nächsten großen Trends? Das war zurück in early 2020. Ich stieß auf ein paar Trends – wie Trends dazu, wie Daten mit Bezug auf Developer DevOps oder SecOps exponentiell wachsen. Wie neue Trends in Machine Learning, AI und LLM Models – damals waren LLM Models in frühen Stadien – den Markt disrupten werden. Und dann, wie der menschliche Hirn denkt und auf bestimmte Incidents reagiert, wollen Sie, dass Maschinen ähnlich agieren. Das waren einige der Probleme, auf die wir stießen, und in der Schnittmenge aller drei fand ich: Hey, das Problem nicht nur der Observability, sondern Observability plus Analytics und Automation auf Top der Daten, fokussiert auf Developer und DevOps, ist sehr kritisch. Das führte zum Beginn von Kloudfuse – eins führte zum anderen und wir sind jetzt ein Team von rund 40+ Leuten.

Dinesh Chandrasekhar (03:16):
Glückwunsch und ein großartiger Start. Alles Gute für diese Journey. Über Observability – das kam nicht gestern. Ich arbeitete auch eine Weile in diesem Bereich und das Konzept von Observability hat sich über Jahre entwickelt. Ursprünglich vor 10-12 Jahren waren Leute gehyped über Infrastructure Monitoring, Network Monitoring und all das, und dann langsam kam Cloud Monitoring und Container Monitoring dazu. Und heute haben wir diese Vorstellung von Observability, die recht populär ist. Die meisten Firmen, die Monitoring anpriesen, sind jetzt Observability-Firmen. Und ich weiß, Sie starteten frisch im Observability-Space, um einen Unterschied zu machen. Wie beschreiben Sie diese Evolution? Was war vorher im Vergleich zu heute? Wie haben Sie diese Evolution gesehen?

Krishna Yadappanavar (04:09):
Gute Frage, Dinesh. Ich habe das gesehen – als Developer selbst, der monolithische Applikationen in physischen Maschinen schrieb. Dann sah ich das Aufkommen von Virtualisierung – ob VMware, Hyper-V oder Open-Source-Virtualisierungstechnologien – und Containerisierung kam dazu. Wenn Sie die Kernprobleme bei Daten für Observability betrachten: Mit diesen Evolutionen haben sich die Attribute, die mit den Daten assoziiert sind, erhöht. Und wenn Sie das kartesische Produkt der potenziellen Werte dieser Labels nehmen, wird es wirklich, wirklich groß – in der Größenordnung von Millionen bis Milliarden. Was sie Cardinality nennen – die Cardinality ist das Datenvolumen. Mit steigendem Datenvolumen wollen Leute Daten A in Daten B transformieren für bessere Analytik. Sie wollen bestimmte Workflows auf Top der Daten automatisieren. Sie wollen Daten slice and dice für bessere Insights. Kurz: Mit steigendem Datenvolumen verschwindet der traditionelle Weg – „Hey, ich monitorte so-called known knowns“ – das ist traditionelles Monitoring. Dann schauen Sie auf „known unknowns“ – der Beginn von Observability. Und es gibt „unknown unknowns“, wo Sie nichts wissen und auf Multi-Terabyte bis Petabytes Daten geworfen werden und innerhalb dieser Daten dissecten müssen, um – mangels besserem Wort – genau das Problem zu finden, wie es zum Incident korreliert, Root Cause Analysis, Impact Analysis. Solange Developer Code schreiben und mehr und mehr Services kommen, wird diese Komplexität immer höher – und deshalb bleibt das ein evolvierender Space, wo neue Herausforderungen entstehen.

Dinesh Chandrasekhar (06:14):
Fantastisch. Observability ist offensichtlich ein schwieriges Problem zu lösen. Ich würde gerne erkunden, warum das so ist. Aber ich denke, Sie haben es gerade etwas angerissen. Es ist auch ein überfüllter Marktplatz mit Dutzenden Vendors, die sagen: „Wir lösen diesen Teil Observability und jenen Teil Observability“ – aber die Suche nach der idealen Lösung bleibt. Jeder CIO, mit dem ich spreche, sucht nach dieser einen Magic Bullet, die ihre Probleme löst. Warum ist das? Gibt es eine andere Linse, durch die man schauen muss, um zu verstehen, warum es diesen Drang nach der idealen Lösung gibt?

Krishna Yadappanavar (07:04):
Lassen Sie mich einen Schritt zurücktreten. Was sucht der Kunde, wenn er an eine ideale Observability-Lösung denkt? Fangen wir beim Problem an. Ich klassifiziere dieses Problem als die drei Cs – Cardinality, Control und Cost. Lassen Sie mich in die nächste Detailebene gehen. Was bedeuten diese drei Cs? Cardinality – es geht darum, wie wir bestimmte Daten haben, ob es ein tricky Metric Point, eine Logzeile, ein Event, ein Trace, ein Span aus Distributed Tracing oder ein Continuous Profile's Profile ist – es wird mit zusätzlichen, mangels besserem Wort, Labels oder Tags angereichert. Wenn Sie das kartesische Produkt der potenziellen Werte nehmen, die diese Labels annehmen können, wächst es wirklich, wirklich hoch. Jetzt muss jeder Datenpunkt mit seinen Tags assoziiert sein.

Nennen wir Tags Metadaten. Und dann gibt es Daten. Verschiedene Schemata haben unterschiedliche Probleme. Einige sind metadata-heavy. Bei Metriken, bei Logs und Spans wie Distributed Tracing sind sie data-heavy. Aber effektiv ist es der tremende Anstieg im Volumen der Observability-Daten wegen der Cardinality. Heutzutage sehe ich einen umgekehrten Trend. Früher dachten Leute: „Hey, lass mich meine Daten an ein SaaS-Portal senden und der SaaS-Vendor managed das alles.“ Aber wenn ich mit CTO, CIO, Head of Engineering, Developern, Architekten und sogar CFO spreche – sie denken: „Lass mich Kontrolle über meine Daten haben.“ Was meinen sie? Es gibt einen umgekehrten Trend: Ich habe so viele Daten aus verschiedenen Gründen – Egress-Kosten, Sicherheitsaspekte, oder das Datenvolumen selbst. Sie wollen die Daten nicht außerhalb ihrer VPC senden. Ein weiterer Winkel: Sie wollen alle möglichen Interfaces reinbringen – ob traditionelles Observability-Interface wie Dashboards, Alerts, SLOs, oder Analytics-Funktionen in traditionellem SQL oder GraphQL, oder fortgeschrittene Spark-Jobs für Analytik auf Observability-Daten, weil Observability zu diesem fundamentalen Pfeiler geworden ist. Das bedeutet, sie müssen die Daten besitzen. Die Daten dürfen die VPC nicht verlassen. Wenn ich Daten sage – die ingested werden, die gequeryed werden, die analysiert werden, und last but not least: Cost. Wenn Sie zu irgendeinem Vendor gehen – ob traditioneller SaaS-Commercial-Vendor oder Open-Source-Komponente, und es gibt viele Open-Source-Lösungen – die Infrastrukturkosten, die Vendor-Kosten sind direkt proportional zum Datenvolumen, direkt proportional zur Anzahl der Queries, direkt proportional zur Anzahl der User. Diese drei Dinge sind die Probleme, die eine traditionelle Organisation sucht, die nach einer idealen Observability-Lösung sucht.

Dinesh Chandrasekhar (10:24):
Cardinality, Control, Costs. Ich liebe das. Die drei Cs sind eine großartige Art, den Observability-Space zu betrachten und zu inferieren, was für tatsächliche Nutzer wichtig ist. Über Costs – da wir drauf zu sprechen kamen – will ich Sie das fragen: Aus eigener Erfahrung, wenn ich mit Kunden sprach, die nach Observability-Lösungen suchten, beschwerten sie sich oft: „Hey, ich habe mindestens 8-10 verschiedene Tools in jedem Department. Ich schaue auf vielleicht 30-40 Tools across der Organisation. Ich habe schon viele Kosten für Lizenzen Jahr für Jahr. ‚Warum will ich noch eine Observability-Lösung?‘ – war ein Pushback, den ich bekam. Ich stelle Ihnen dieselbe Frage jetzt, da Sie den Cost-Aspekt angerissen haben. Wie gehen Sie die Frage mit einem CIO an und überzeugen ihn oder sagen ihm, warum das besser ist als 30-40 verschiedene Tools?

Krishna Yadappanavar (11:23):
Okay, gute Frage. Um die zu beantworten, fangen wir beim Problem an: Warum gibt es Tool-Proliferation? Wenn Sie das gesamte Ökosystem anschauen – traditionell waren einige Vendors in bestimmten Streams gut. Bei Logs denken Sie an Splunk. Bei Metriken an Datadog. Dann bei Google und all den FANGs. Diese ganze Open-Source-Bewegung begann – besonders mit Kubernetes – kamen Dinge wie Prometheus, OpenTelemetry, und was nicht. Und da ist dieser ganze Shift Richtung Open-Source-basierte Lösungen. Was bedeutet das? Developer, Architects, DevOps wollen Observability-Daten in einem offenen Format ingestieren. Heißt: Selbst wenn ich irgendeine Instrumentierung wähle, um meinen Code zu instrumentieren, oder irgendeinen Agenten, um Daten zu sammeln – das sollte 100 % Open-Source-kompatibel sein. Deshalb, als Commercial Vendors auch ihre Agents Open Source machten, wollen sie auf der Query-Seite die ganze Visualisierung, Dashboarding, Alerting – all diese Capabilities durch Open-Source-Query-Languages getrieben. Deshalb das Entstehen von PromQL, LogQL, TraceQL, OpenTelemetry – sie probieren jetzt eine weitere Open-Source-Query-Language. Jetzt sind Sie in dieser Welt, wo Sie viele Optionen haben. Kunden haben bereits bestimmte Vendors für bestimmte Streams gepickt. Dann die Open-Source-Bewegung und verschiedene Teams nutzen verschiedene Infrastrukturen – einige Kubernetes, einige Serverless, einige ECS, Fargate, was nicht. Das fügt eine weitere Dimension hinzu. Und um Speed und Agility der gesamten Product Delivery zu erreichen, hat sich CI/CD in dieser Intersection entwickelt, um Probleme sehr schnell zu lösen. Sie versuchen, pointed Solutions zu finden und enden damit, sehr pointed Solutions zu wählen. Das ist der Moment, wo wir als ideale Observability-Lösung – wenn ich meinen Observability-Stack für meine Firma starten würde – einen Schritt zurücktreten und sehen: „Hey, wenn ich MTTR und MTTD reduzieren will, muss ich alle End-Streams der Observability-Daten sammeln. Gehe ich zu n verschiedenen Vendors und picke n verschiedene Streams, oder gehe ich zu einem Observability Data Lake, wo ich alle Streams zusammenlegen kann, sodass Korrelation, fortgeschrittene Funktionen wie Outlier Detection, Anomalies, Causation relativ einfacher werden?“ Das wäre eine ideale Lösung, wo Sie alles in einem Data Lake konsolidieren können, wo Sie Ihre Daten on-premises bewahren.

Dinesh Chandrasekhar (14:18):
Fantastisch. Und ich möchte hinzufügen: Cost für Tool-Proliferation – ich stimme weitgehend zu, weil Developer ihr eigenes Ding bauen wollen und viel Open-Source-Tooling zum Mix hinzugefügt haben. Aber es sind auch Department-Level-Käufe. Ein IT-Department fühlt: „Ich kann dieses Problem lösen, lass mich eine Band-Aid-Lösung kaufen, dieses Tool off-the-shelf kaufen und nutzen.“ Und über die Zeit realisierten sie, sie haben ein weiteres Tool zum Arsenal hinzugefügt, ohne zu realisieren, dass sie nicht den Wald vor lauter Bäumen sehen. CIO-Gespräche sind immer interessant – wie man die Anzahl der Tools across Enterprise kompaktieren oder reduzieren kann und eine Observability-Plattform hat, die across Departments, Applikationen, Infrastructure, Container schaut.

Krishna Yadappanavar (15:08):
Absolut. Um das anzufügen: Jetzt schauen verschiedene Personas in der Firma auf dieselben Daten. DevOps, Developers, Architects schauen alle auf Observability-Daten bezüglich Infrastructure, Containerization, Applikationen. Mit denselben Logs. SecOps Jungs versuchen, Daten zu dissecten für Security und Threats. Schauen auf ähnliche Daten aus Logs oder Traces. Sogar DataOps schauen: „Hey, wie gut sind meine Data Operations?“ Und jetzt mit LLM auch LLMOps schauen auf ähnliche Daten für ihre Art von Analytik. Da ist eine weitere Konsolidierung nötig. Das ist etwas, wonach ich in einer idealen Observability-Lösung schaue: Wie bringe ich alle verschiedenen Personas in einer Organisation rein, damit sie Daten aus demselben so-genannten Data Lake nutzen können.

Dinesh Chandrasekhar (16:05):
Wahrhaftig das proverbial Single Pane of Glass, wonach wir alle streben. Gut. Ich will noch was anfassen, das Sie kurz erwähnten, als Sie die vorherige Response erklärten – MTTR reduzieren. Als primärer Kern von Observability geht es nicht nur um Troubleshooting, sondern auch MTTR reduzieren, Alert Noise reduzieren und solche Metriken. Das rettet SREs und IT Ops definitiv davor, Haare zu spalten und rauszufinden, wo das Problem ist. Als fundamentale Anforderung dafür brauchen Sie Zugriff auf Echtzeit-Events, während sie passieren. Wenn ein Log in einer bestimmten Applikation oder einem Server über bösartige Aktivität eingeht, brauchen Sie Zugriff auf dieses Event sofort, um zu verstehen: Wo ist die Anomalie? Was passiert across Ihrer Infrastructure? Warum dieser Spike in einem bestimmten Memory Thread? Sie müssen das herausfinden. Und dafür brauchen Sie die Fähigkeit, all das in Echtzeit zu ingestieren. Data Immediacy – mein Lieblingstermin letztes Jahr – und Data Freshness sind hier von primärer Wichtigkeit. Wie frisch die Daten sind, bestimmt, wie schnell Sie das Problem lösen oder vielleicht sogar etwas abwenden können, das passieren wird – besonders bei hunderten, tausenden Servern, die Sie monitoren. Wo sagen Sie: „Hier ist das Problem“? In Bezug auf Data Freshness – hängt es largely von Ingestion-Mechanismen ab? Weil Sie über OTEL und andere Instrumentierungstechniken sprachen. Wie sonst würden Sie darüber nachdenken oder es aus dieser Perspektive betrachten – wie schnell kann ich Zugriff auf Echtzeitdaten bekommen?

Krishna Yadappanavar (18:03):
Okay, ein weiterer großartiger Aspekt des Observe-Teams. Sie haben absolut recht, Dinesh. Die Schlüssel-Dimension, wo Observability-Daten konsumiert werden: Wie schnell kann ich die Daten haben, sobald sie die Quelle verlassen – ob Ihre Applikation, Infrastructure-Komponenten, Plattform wie Open-Source-Komponenten etc. Wenn Sie anschauen, wie die Industrie sich in den letzten 5-10 Jahren entwickelt hat – Real-Time Streaming Services, Real-Time Databases kamen dazu. Traditionelle Observability-Lösungen konnten diese Funktionalität nicht nutzen, weil die Technologie relativ älter war. Mit dem Aufkommen von Real-Time Streaming und Real-Time Databases können Sie Zugriff auf Daten so schnell wie möglich bekommen. Das ist das Maß für Data Freshness – vom Moment, wo es die Applikation verlässt, bis es readily queryable ist. Das ist alles, was zählt.

Dann der Aspekt: „Hey, ich habe alle Daten. Wie kompartimentiere ich sie? Wie finde ich die relevanten Patterns für Root Cause?“ Das ist der nächste Problem-Satz. Heißt: Ich sollte Daten transformieren können – Data A zu Data B. „Hey, ich bekomme Series von Logs. Kann ich schnell eine Metrik aus den Logs schauen? Ich bekomme Series von Spans. Kann ich ein Attribut innerhalb des Spans oder Trace anschauen, um die Daten zu analysieren?“ Weil diese Attribute typischerweise korreliert sind – so passiert Debugging. Das ist die nächste Dimension. Und die dritte Dimension: Advanced Analytics. Auf Top dieser Daten – kann ich interessante statistische oder Large Language Models bringen, um Daten zu analysieren, um das zu finden, was man Outliers nennt? Kann ich Anomalien in meinem System finden? OK, kann ich in den Saisonalitäts-Aspekt meiner Daten schauen? Kann ich meine Daten basierend auf dem, was ich aus der Vergangenheit gesehen habe, forecasten? Der saisonale Aspekt der Daten? All das nenne ich das Package der Advanced Analytics. Wenn Sie an die Gesamtlösung denken – nachdem Data Freshness gelöst ist – müssen Sie über Daten als Einheit eines Ziegels denken und wie jeder Ziegel angepasst werden kann und dann Set von Analytics-Funktionen. Und das Natürliche, was wir brauchen: „Hey, ich habe das einmal analysiert, kann ich es automatisieren?“ Das wird die natürliche Extension zum Ganzen. Deshalb sehen wir junto mit dem 3-Cs-Problem Kunden fragen: „Wie kann ich observe, analyze und automate meine Observability-Daten.“

Dinesh Chandrasekhar (20:57):
Sehr cool. Sehr cool. Und als Teil Ihrer Response erwähnten Sie auch das Magic Word LLMs – Large Language Models. Heutzutage kann man kein Gespräch ohne GenAI LLMs führen. Ich bin froh, dass Sie es erwähnten, weil ich Sie definitiv danach fragen konnte – LLM Observability. Sieht aus wie ein aufstrebender Space, gegeben der Proliferation von LLMs überall und Leute kämpfen damit, zu verstehen, wie sie performen. Erzählen Sie uns davon. Scheint, Kloudfuse baut da auch was? Mehr dazu.

Krishna Yadappanavar (21:32):
Ich meine, ja. Fundamental werden LLM Models in verschiedenen Use Cases deployed – mangels besserem Wort. Die Dynamik der Daten ändert sich, besonders in der Observability-Welt – Daten sind sehr dynamisch. Das richtige LLM Model für bestimmte Operationen zu bauen, ist immer hart. Wir haben das Problem in zwei Arten angeschaut. Wie kann ich gewisse LLM Models auf Top der bestehenden Observability-Daten nutzen, die von all den verschiedenen Personas konsumiert werden – DevOps, SecOps, DataOps, LLMOps. Das ist ein Aspekt. Der andere: „Hey, ich entwickle eine Applikation, wo LLM eine sehr, sehr kritische Komponente ist. Wie schaue ich auf die komplette Observability einer Applikation, die Daten produziert, die in den LLM gefeedet werden, und dann gibt es viele Consumers, die Daten von diesen LLM Models konsumieren.“

Wir denken – in der Tat kann ich sagen, wir sind die Ersten, die end-to-end darüber nachdenken, was wahre Observability für alle Applikationen ist, die mit LLM Models entwickelt werden. Weil ich viele Lösungen gesehen habe, die nur Model Observability anschauen – Drift und so. Aber wir schauen end-to-end. Das ist ein sehr interessanter Aspekt, weil viel Infrastructure-Applikation-Observability mit Model Observability und dem Rest einhergeht. Und last but not least: Wenn Sie irgendeinen CIO oder CFO fragen – Cost des LLM, wie aktuelle Lösungen, Cost ist eine weitere Key Dimension. Wie man diesen Cost niedrig hält oder sogar Analytik auf Cost-Metriken der LLM Models selbst liefert – ein weiterer Aspekt. Man muss alles anschauen: Performance, nennen wir es APM für LLM Applikationen, und dann Cost. Das sind die typischen Dimensionen.

Dinesh Chandrasekhar:
Sehr cool, aufregender Space und ich bin definitiv gespannt, was in den kommenden Monaten kommt. Vielen Dank, Krishna. Das war ein sehr, sehr wunderbares Gespräch. Liebte, Sie in unserer Show zu haben. Liebte das Reden über Observability. Ich werde mir Ihre drei Cs merken: Cardinality, Control, Costs. Ich denke, das ist eine großartige Art, ein großartiges Mantra, Observability anzuschauen. Danke für all die Insights. Schätze, dass Sie hier waren. Danke.

Krishna Yadappanavar:
Vielen Dank, Dinesh. Danke, dass Sie mich in Ihrem Web Chat hatten.