Smart Talk Episodio 7: Navegando Cardinalidad, Control y Costos en Observabilidad

Hemos discutido observabilidad y el espacio complementario de AIOps un par de veces en esta serie pero esta vez, damos un vistazo más pragmático al tema para entender la mentalidad del comprador. ¿Qué debería buscar un CIO de una organización cuando está en el mercado para una solución de observabilidad? Únete a nosotros en este episodio mientras Dinesh Chandrasekhar, Analista Jefe y Fundador de Stratola, habla con Krishna Yadappanavar, CEO de Kloudfuse. Krishna explica observabilidad a través de la lente de tres factores – Cardinalidad, Control y Costos.
Estas 3 Cs son clave para entender y gestionar datos de observabilidad siempre crecientes. Estos factores no solo son importantes para gestionar los datos sino también para aprovechar los datos y metadatos para analítica adicional.
Un nuevo desarrollo en el campo de la observabilidad es la observabilidad de modelos, especialmente los LLMs que impulsan IA generativa. Las 3 Cs también aplican a este caso de uso emergente.

Algunos de los temas cubiertos en este episodio de Smart Talk son:

• Potencial de datos de observabilidad
• Proliferación de herramientas
• Superando datos de observabilidad aislados
• Considerando los metadatos
• Insight en costos

Invitado
Krishna Yadappanavar, CEO, Kloudfuse
Krishna Yadappanavar es el Co-Fundador y CEO de Kloudfuse, una plataforma de observabilidad unificada. Previamente co-fundó SpringPath, asegurando $94 millones en financiamiento y liderando la compañía a una adquisición de $320 millones por Cisco. Con más de 20 patentes, Krishna ha impactado significativamente tecnologías de datos, virtualización y almacenamiento en Veritas, Commvault, EMC, VMware y Cisco. Co-escribió VMFS de VMware y diseñó componentes críticos del stack de virtualización de almacenamiento para ESX Server. Adicionalmente, Krishna asesora e invierte en startups emergentes a través de Datos, Virtualización, Cloud, Seguridad e IA/ML, contribuyendo a visión, estrategia de producto, ingeniería y esfuerzos de go-to-market.

Anfitrión: Dinesh Chandrasekhar es un evangelista tecnológico, líder de pensamiento y analista experimentado de la industria IT. Con cerca de 30 años de experiencia, Dinesh ha trabajado en software empresarial B2B así como productos SaaS entregando y comercializando soluciones sofisticadas para clientes con arquitecturas complejas. También ha definido y ejecutado estrategias GTM altamente exitosas para lanzar varios productos de alto crecimiento al mercado en varias empresas como LogicMonitor, Cloudera, Hortonworks, CA Technologies, Software AG, IBM etc. Es un orador prolífico, blogger y programador de fin de semana. Dinesh tiene un MBA de Santa Clara University y una Maestría en Aplicaciones Informáticas de la University of Madras. Actualmente, Dinesh dirige su propia empresa, Stratola, una firma de consultoría de estrategia empresarial enfocada en el cliente y servicios de marketing full-stack.

Recursos
Smart Talk Episodio 6: AIOps y el Futuro del Monitoreo IT
Smart Talk Episodio 5: Desagregación de la Pila de Observabilidad
Smart Talk Episodio 4: Datos en Tiempo Real y Bases de Datos Vectoriales
Smart Talk Episodio 3: Pipelines de Datos Modernos y LLMs
Smart Talk Episodio 2: El Auge de Aplicaciones GenAI con Data-in-Motion
Smart Talk Episodio 1: El Panorama del Ecosistema Data-in-Motion
Ver el mapa del ecosistema data-in-motion aquí
Aprende más sobre data-in-motion en RTInsights aquí

Transcripción
Dinesh Chandrasekhar

Hola y bienvenidos a este episodio de Smart Talk, una serie de liderazgo Data in Motion. Y en este episodio tenemos un invitado especial, Krishna Yadappanavar. Él es el CEO de Kloudfuse. No es ajeno al ecosistema de startups. Es un emprendedor serial. Ha construido un par de empresas antes de esta, y así que damos la bienvenida calurosamente a Krishna para tener esta conversación sobre observabilidad, que es, de nuevo, un tema favorito en esta serie.

Krishna Yadappanavar

Gracias.

Dinesh Chandrasekhar

Así que Krishna, como forma de presentarte, ¿por qué no nos cuentas sobre Kloudfuse y tu motivación para iniciar la empresa?

Krishna Yadappanavar (01:01):

Ok, absolutamente. Gracias, Dinesh. Gracias por la cálida introducción. Hola a todos, mi nombre es Krishna. Sí, he estado viviendo en el Valley por casi dos décadas y media y he estado trabajando con un montón de startups y grandes empresas. El nombre a la fama es como VMware cuando era una startup temprana. Me uní y luego la vi crecer de literalmente cerca de un millón de ARR a una compañía de 64 billones y he estado asociado con diferentes tecnologías relacionadas con datos, ya sea escribiendo sistemas de archivos, sistemas distribuidos, bases de datos u OLAP u OLTP. Ok, así que a lo largo de este viaje lo que noté es que los datos son el secreto de todos los insights, ya sea en el lado de analítica de producto o es proporcionando una solución como virtualización o proporcionando una solución como backup o disaster recovery. Habiendo hecho mi startup, Springpath, que estaba en hiperconvergencia, intentando traer la convergencia de almacenamiento, redes, seguridad todo en una caja la vendí a Cisco.

Y después de pasar un tiempo en Cisco, estaba pensando cuáles son las próximas grandes tendencias que van a venir. Esto es a principios de 2020. Me encontré con un par de tendencias, como algunas tendencias relacionadas con cómo los datos con respecto a un desarrollador DevOps o SecOps están creciendo exponencialmente. Cómo las nuevas tendencias en machine learning IA y modelos LLM en ese entonces los modelos LLM estaban en etapas tempranas van a disrumpir el mercado. Y luego como el cerebro humano empieza a pensar y reaccionar a ciertos incidentes, quieres que las máquinas actúen de manera similar. Estos fueron algunos de los problemas con los que nos topamos y en la intersección de los tres, encontré que oye, resolver el problema no solo de la observabilidad, sino observabilidad más analítica y automatización, encima de los datos, que está enfocado en los desarrolladores y los DevOps es muy crítico. Eso llevó al comienzo de Kloudfuse–uno llevó al otro y ahora somos un equipo de alrededor de 40 más personas.

Dinesh Chandrasekhar (03:16):

Bueno, felicitaciones y este es un gran comienzo. Así que te deseo buena suerte en ese viaje. Hablando de observabilidad, esto no fue algo que surgió ayer. Trabajé en ese espacio también por una cantidad justa de tiempo y el concepto de observabilidad ha evolucionado a lo largo de los años. Así que originalmente hace 10, 12 años la gente estaba emocionada hablando sobre monitoreo de infraestructura, monitoreo de red y todo eso, y luego lentamente una cosa llevó a otra y luego hubo capacidades de monitoreo de cloud y contenedores que se agregaron. Y luego hoy tenemos esta noción de observabilidad que es bastante popular. La mayoría de las empresas que solían promocionar monitoreo ahora son empresas de observabilidad. Y sé que empezaste desde cero en el espacio de observabilidad queriendo crear una diferencia. ¿Cómo describirías esta evolución? ¿Qué había antes comparado con lo que tenemos hoy? ¿Cómo has visto esta evolución?

Krishna Yadappanavar (04:09):

Sí, gran pregunta. Dinesh. He visto esto, quiero decir como desarrollador yo mismo escribiendo una aplicación monolítica corriendo en máquinas físicas. Luego vi el advenimiento de virtualización, ya sea como VMware o Hyper-V o tecnologías de virtualización open-source y la contenerización llegó. Así que si miras los problemas centrales cuando se trata de los datos para la observabilidad, a medida que estas evaluaciones han evolucionado, hemos visto que los atributos asociados con los datos siguen aumentando, y cuando tomas el producto cartesiano de esos atributos, se vuelve realmente grande en orden de múltiples millones a billones. Lo que llaman cardinalidad asociada con esa cardinalidad es el volumen de datos. A medida que el volumen de datos aumenta, la gente quiere transformar datos A a datos B para mejor analítica. Quieren automatizar ciertos flujos de trabajo encima de los datos.

Quieren rebanar y cortar los datos para que puedan darte mejores insights. Así que en resumen, a medida que el volumen de datos aumenta la forma tradicional de, oye, estaba monitoreando los llamados known knowns se va, que es el monitoreo tradicional. Luego estás mirando los known unknowns, que es el comienzo de la observabilidad y están los complete unknown unknowns donde no sabes nada y te lanzan multi-terabytes a petabytes de datos y tienes que diseccionar dentro de esos datos y llegar a la falta de mejor palabra donde exactamente está el problema, cómo se correlaciona con el incidente, cuál es el análisis de causa raíz, cuál es el análisis de impacto. Así que mientras los desarrolladores escriban código, esta complejidad y más y más servicios vienen. Esta complejidad va a ir más y más alto y por eso esto continúa siendo un espacio en evolución donde nuevos desafíos emergen.

Dinesh Chandrasekhar (06:14):

Fantástico. Así que observabilidad obviamente es definitivamente un problema difícil de resolver. Me encantaría explorar por qué es eso? Pero creo que lo tocaste un poco también justo ahora, pero también es que tenemos un mercado abarrotado con un montón de vendedores por ahí que están diciendo, resolvemos esta parte de observabilidad y esa observabilidad y todo eso, pero aún hay una búsqueda de la solución ideal. Así que cada CIO con el que hablo siempre está buscando esta bala mágica que medio resuelve sus problemas. ¿Por qué es eso? ¿Hay una lente diferente a través de la cual tienes que mirarlo para entender por qué hay un impulso diferente para obtener esa solución ideal?

Krishna Yadappanavar (07:04):

Así que como aludía antes déjame dar un paso atrás, ¿verdad? ¿Qué es ese cliente buscando cuando están pensando en una solución de observabilidad ideal? Empecemos desde el problema. Clasifico este problema como las tres Cs–la Cardinalidad, Control y el Costo. Déjame ir al siguiente nivel de detalles. ¿Qué significan estas tres Cs? Cardinalidad, se trata de cómo tenemos ciertos datos, ya sea un punto de métrica tricky o una línea de log o un evento o un trace o un span viniendo de tu tracing distribuido o un profile de perfil continuo, se adjunta con adicionales, por falta de mejor palabra, labels o tags. Cuando tomas el producto cartesiano de los valores potenciales que esos labels pueden tomar, crecerá realmente, realmente alto. Así que ahora cada punto de datos necesita ser asociado con sus tags.

Así que llamemos tags como los metadatos. Y luego hay un dato. Diferentes esquemas tienen diferentes problemas. Algunos son metadata heavy. Cuando vas al sitio de métricas, cuando vienes a los logs y los spans como el distributed tracing, son como data heavy, pero en efecto, es el tremendo aumento en el volumen de los datos de observabilidad debido a la cardinalidad. Hoy en día he visto la tendencia inversa. Quiero decir en los días pasados la gente pensaba como, Oye, déjame mandar mis datos a un portal SaaS y luego el vendedor SaaS manejaría todo eso. Pero cuando hablo con ya sea el CTO o un CIO o un head of engineering o los desarrolladores o los arquitectos e incluso el CFO, están pensando, déjame tener control de mis datos. ¿Qué quieren decir con eso? Hay una tendencia inversa que está pasando que tengo tantos datos por varias razones, ya sea el riesgo de costo de egress, los aspectos de seguridad de ello, o el volumen de los datos mismo.

No quieren mandar esos datos fuera de su VPC y hay otro ángulo. Quieren traer todas las interfaces posibles que puedan pensar ya sea para una interfaz de observabilidad tradicional como crear tus dashboards, alerts, SLOs, o cualquier función de analítica que pueda ser escrita en un SQL tradicional o un GraphQL o podría haber avanzados como Spark jobs para correr alguna analítica encima de los datos de observabilidad porque la observabilidad se ha vuelto ese pilar fundamental. Eso significa que tienen que poseer los datos. Los datos no deben salir del VPC. Cuando digo los datos, los datos que se están ingiriendo, los datos siendo consultados, y los datos que están siendo analizados y, último pero no menos importante, es el costo. Si vas a cualquier vendedor por ahí, ya sea un vendedor comercial SaaS tradicional o un componente open source, y hay un montón de soluciones open source por ahí. El costo de infraestructura, el costo del vendedor es directamente proporcional al volumen de datos, directamente proporcional al número de consultas y directamente proporcional al número de usuarios. Esas tres cosas son los problemas que una organización tradicional que busca una solución ideal, una solución ideal de observabilidad está buscando.

Dinesh Chandrasekhar (10:24):

Cardinalidad, control y costos. Creo que me encanta eso. Las tres Cs son una gran forma de ver el espacio de observabilidad y cómo infieres qué es importante para los usuarios reales y así sucesivamente. Hablando de costos, ya que lo tocamos, quiero hacerte esta pregunta también. De mi propia experiencia personal, cuando he hablado con clientes que buscan una solución de observabilidad, a menudo se quejan como, Oye, tengo al menos ocho a 10 herramientas diferentes en cada departamento que tengo. Estoy mirando tal vez 30 a 40 herramientas a través de la organización hoy. Ya estoy teniendo un montón de costos pagando por estas licencias año tras año. "¿Por qué quiero una solución de observabilidad más," es un pushback que solía recibir, ¿verdad? Así que voy a plantear esa misma pregunta a ti ahora que has tocado el aspecto de costo. ¿Cómo abordas esa pregunta con un CIO y los convences o les dices por qué esto es mejor que tener 30 o 40 herramientas diferentes?

Krishna Yadappanavar (11:23):

Ok, gran pregunta. Para responder esa pregunta, empecemos con el problema de por qué hay proliferación de herramientas. Así que si miras el ecosistema entero, tradicionalmente algunos vendedores, si tomo los vendedores comerciales, eran bastante buenos en ciertos streams. Si vas a logs, puedes pensar en Splunk. Si piensas en métricas, piensas en Datadog. Luego dentro de Google y todos los FANGs del mundo. Todo este movimiento de open source empezó, especialmente con el advenimiento de Kubernetes, luego vinieron cosas como Prometheus, OpenTelemetry y qué no.

Y hay todo este cambio que está yendo hacia y moviéndose a la solución basada en open source. ¿Qué significa eso? Significa que los desarrolladores, los arquitectos, los DevOps quieren ingestar sus datos de observabilidad en un formato abierto. Significando, incluso si elijo cualquier instrumentación para instrumentar mi código o poner cualquier agente para recopilar mis datos, eso debería ser cien por ciento compatible con open source. Así que por eso cuando los vendedores comerciales también empezaron a poner sus agentes en open source, entonces en el lado de la query, quieren toda la visualización, el dashboarding, alerting–todas estas capacidades para ser impulsadas por lenguajes de query open source. Por eso la emergencia de PromQL, LockQL, TraceQL, OpenTelemetry, ahora están intentando otro lenguaje de query open source.

Así que ahora estás en este mundo donde tienes muchas opciones. Los clientes ya han elegido ciertos para ciertos streams, ciertos vendedores.

Luego hay un movimiento open source y luego diferentes equipos están usando diferentes infraestructuras. Algunos están basados en Kubernetes, algunos en serverless, algunos en ECS, Fargate qué no. Así que eso está añadiendo otra dimensión y para llegar a la velocidad y la agilidad de la entrega del producto completa, CI/CD ha evolucionado en esta intersección para resolver los problemas muy rápido. Intentan buscar la solución puntual y por eso terminan eligiendo la solución muy puntual. Eso es cuando nosotros como una solución de observabilidad ideal, si yo fuera a empezar mi stack de observabilidad para mi compañía, daría un paso atrás y vería como, oye, si quiero reducir mi MTTR y MTTD, necesito recopilar todos los end streams de los datos de observabilidad. ¿Voy a n diferentes vendedores y elijo n diferentes streams, o voy a un data lake de observabilidad donde puedo poner todos los streams juntos para que la correlación, las funciones avanzadas como detección de outliers, anomalías, causalidad se vuelve relativamente más fácil? Esa sería una solución ideal donde puedes consolidar todo en un data lake donde puedes preservar tus datos dentro de tus premisas.

Dinesh Chandrasekhar (14:18):

Fantástico. Y también me gustaría añadir que el costo por proliferación de herramientas, estoy de acuerdo en gran parte porque los desarrolladores quieren construir su propia cosa y han añadido un montón de tooling open source también a la mezcla, pero también son compras a nivel de departamento. Así que un departamento de IT siente como yo puedo resolver este problema porque déjame conseguir una solución bandaid, déjame comprar esta herramienta off the shelf y usarla. Y luego con el tiempo se dieron cuenta que han añadido una herramienta más al arsenal y sin darse cuenta que no están mirando el bosque por los árboles. Así que las conversaciones de CIO siempre son interesantes y sobre cómo puedes compactar o reducir el número de herramientas que tienes a través de la empresa y tener una plataforma de observabilidad mirando a través de los departamentos, mirando a través de aplicaciones, infraestructura contenedores y qué no.

Krishna Yadappanavar (15:08):

Absolutamente. Así que quiero decir para añadir a eso ahora diferentes personas en la compañía también están mirando los mismos datos. Como DevOps desarrolladores, arquitectos están todos mirando los datos de observabilidad con respecto a infraestructura, contenerización aplicaciones y qué no. Usando los mismos logs. Los chicos de SecOps están intentando diseccionar los datos para buscar seguridad y amenazas. Mirando los datos similares viniendo de los logs o los traces. Incluso los chicos de DataOps están mirando como, Oye, qué tan buenas son mis operaciones de datos. Y ahora con el advenimiento de LLM, incluso los chicos de LLM Ops están mirando los datos similares para hacer su tipo de analítica. Así que hay otra consolidación que necesita pasar. Esa es una cosa que buscaría en una solución de observabilidad ideal. ¿Cómo traigo a todas las diferentes personas en una organización para que puedan aprovechar los datos del mismo llamado data lake.

Dinesh Chandrasekhar (16:05):

Verdaderamente el proverbial single pane of glass que todos hemos estado esforzándonos. Así que es una buena cosa. Así que quiero tocar una otra cosa que mencionaste brevemente mientras explicabas la respuesta anterior, que era sobre reducir MTTR, ¿verdad? Así que como un núcleo primario de observabilidad, se trata no solo de troubleshooting sino también de reducir el MTTR reducir ruido de alertas y esos tipos de métricas también. Así que definitivamente salva a SREs y IT Ops de tener que partir pelos y averiguar dónde está el problema y todo eso como un requisito fundamental clave para resolver esto. Necesitas acceso a eventos en tiempo real mientras están pasando. Si hay un log que se ingresó en una aplicación particular o un servidor particular sobre una actividad maliciosa o algo así, necesitas acceso a ese evento ahí mismo entonces y allí para que puedas entender dónde está esa anomalía, qué está pasando a través de tu infraestructura, por qué este pico particular en un hilo de memoria particular o lo que sea.

Así que necesitas averiguar eso y para que eso pase, necesitas la habilidad de ingestar todo esto en tiempo real también. Inmediatez de datos, que es un término favorito mío durante el último año he estado hablando de eso, y frescura de datos es de importancia prima aquí. Esto es de lo que estamos hablando, qué tan frescos son los datos, es qué tan rápido puedes resolver ese problema particular o tal vez incluso evitar algo que está a punto de pasar en este contexto particular de observabilidad, particularmente cuando estás hablando de cientos y miles de en servidores que estás monitoreando y todo eso, o dónde señalar diciendo, aquí está donde está el problema en términos de conseguir que los datos sean tan frescos como posible o no. ¿Es largamente dependiente de los mecanismos de ingestión? Porque hablaste sobre TEL y otros tipos de técnicas de instrumentación y todo eso también. Así que cómo más lo pensarías o lo mirarías desde esta perspectiva de qué tan rápido puedo obtener acceso a datos en tiempo real?

Krishna Yadappanavar (18:03):

Ok, otro gran aspecto del equipo observe, estás absolutamente en lo correcto, Danesh. Así que la dimensión clave donde los datos de observabilidad están siendo consumidos es qué tan rápido puedo tener los datos, el momento que los datos han salido de la fuente de los datos, ya sea tu aplicación o tus componentes de infraestructura o tu plataforma como componentes open source y cosas así. Así que para eso, si miras cómo la industria ha evolucionado en los últimos cinco a 10 años más o menos, los servicios de streaming en tiempo real, bases de datos en tiempo real han llegado. Si miras las soluciones de observabilidad tradicionales, quiero decir no pudieron aprovechar esa funcionalidad porque la tecnología era relativamente más vieja. Así que con el advenimiento del streaming en tiempo real y las bases de datos en tiempo real, puedes llegar al acceso de los datos tan rápido como sea posible. Así que esa es la medida de lo que se llama frescura de los datos desde el momento que ha salido de la aplicación hasta que es fácilmente consultable, eso es todo lo que importa.

Luego está ese aspecto de como, oye, tengo todos los datos. ¿Cómo compartimento esos datos? ¿Cómo encuentro los patrones relevantes que necesito para llegar a la causa raíz es el próximo set de problemas. Así que eso significa que debería ser capaz de transformar datos un dato al otro dato. Oye, estoy obteniendo serie de logs. ¿Puedo mirar rápido una métrica fuera de los logs? Estoy obteniendo una serie de spans. ¿Puedo mirar algún atributo dentro de ese span o un trace para analizar esos datos? Porque estos atributos son típicamente correlacionados y así es como el debugging pasa. Así que esa es la próxima dimensión. Y luego la tercera dimensión es la analítica avanzada. Encima de esos datos, ¿puedo traer algunos interesantes estadísticos o los large language models para analizar los datos para encontrar lo que se llama outliers en mi sistema?

¿Puedo encontrar las anomalías en mi sistema? Ok, ¿puedo mirar en el aspecto de estacionalidad de mis datos? ¿Puedo pronosticar mis datos basado en lo que he visto del pasado? El aspecto estacional de los datos? Así que todo esto es lo que llamo como el paquete de analítica avanzada. Así que cuando piensas en la solución general después de que la frescura de los datos es resuelta, necesitas pensar en los datos como una unidad de un ladrillo y luego cómo cada ladrillo puede ser ajustado y luego set de función de analítica. Y luego la cosa natural que necesitaremos es como, oye, he analizado esto una vez, ¿puedo automatizarlo? Eso se vuelve la extensión natural a la cosa entera. Así que es por eso que junto con el problema de las tres Cs, hemos visto a los clientes preguntando cómo puedo observar, analizar y automatizar mis datos de observabilidad.

Dinesh Chandrasekhar (20:57):

Muy genial. Muy genial. Y luego como parte de tu respuesta, también mencionaste la palabra mágica LLMs, large language models. Quiero decir estos días no puedes tener una conversación sin hablar sobre GenAI LLMs. Así que me alegro que lo mencionaras porque definitivamente podía preguntarte sobre esto, que es observabilidad de LLM. Parece que ese es un espacio emergente repentinamente dado que tenemos una proliferación de LLMs en todas partes y la gente está luchando con entender cómo están performando y así sucesivamente. Así que cuéntanos sobre eso. Parece que Kloudfuse también está construyendo algo en ese frente también, ¿verdad? Así que cuéntanos más sobre eso.

Krishna Yadappanavar (21:32):

Quiero decir, sí. Quiero decir fundamentalmente todo el, los modelos LLM están siendo desplegados en varios casos de uso, ¿verdad? Por falta de mejor palabra. El dinamismo de los datos cambia, especialmente en el mundo de observabilidad, los datos son muy dinámicos. Construir el modelo LLM correcto para hacer ciertas operaciones es siempre difícil. Así que hemos mirado el problema en dos formas. ¿Cómo puedo aprovechar ciertos modelos LLM encima de los datos de observabilidad existentes, que están siendo consumidos por todas las diferentes personas que hablé, ya sea DevOps o SecOps o DataOps chicos o los LLMOps chicos. Ese es el un aspecto de ello. Y hay el otro aspecto de, oye, estoy desarrollando una aplicación donde el LLM es un componente muy, muy crítico. ¿Cómo miro la observabilidad completa de una aplicación que está produciendo los datos, que se están alimentando en el LLM, y luego hay un montón de consumidores que están consumiendo esos datos de esos modelos LLM.

Así que estamos pensando de, de hecho, puedo decir que somos los primeros en pensar end-to-end qué es la verdadera observabilidad para todas las aplicaciones que son desarrolladas usando modelos LLM. Porque me he topado con un montón de soluciones solo mirando la observabilidad del modelo como drift y cosas así. Pero estamos mirando end-to-end. Ese es un aspecto muy interesante porque un montón de observabilidad de infraestructura aplicación va junto con la observabilidad del modelo y el resto de las cosas. Y luego último pero no menos importante, si vas y le preguntas a cualquier CIO o el CFO, el costo del LLM, como las soluciones actuales, el costo es otra dimensión clave. ¿Cómo mantienes ese costo o incluso provees cualquier analítica en las métricas de costo de los modelos LLM mismo es otro aspecto de ello. Así que tienes que mirar en todo: performance, falta de, llamémoslo un APM para aplicaciones LLM, y luego el costo. Así que estas son las dimensiones típicas en las que lo mirarías.

Dinesh Chandrasekhar

Muy genial, espacio emocionante y definitivamente estoy emocionado sobre aprender qué viene en ese espacio en los próximos meses. Así que muchas gracias, Krishna. Esta ha sido una conversación muy, muy maravillosa. Me encantó tenerte en nuestro show. Me encantó hablar sobre observabilidad. Voy a recordar tus tres Cs: Cardinalidad, Control y Costos. Creo que es una gran forma, gran mantra para ver observabilidad. Así que gracias por todos los insights. Aprecio que estuvieras aquí. Gracias.

Krishna Yadappanavar

Muchas gracias, Dinesh. Gracias por tenerme en tu web chat.