Smart Talk Episodio 7:Navegando por la cardinalidad, el control y los costos en la observabilidad

Hemos discutido la observabilidad y el espacio complementario de AIOps un par de veces en esta serie, pero esta vez profundizamos más pragmáticamente en el tema para comprender la mentalidad del comprador. ¿Qué debe buscar el CIO de una organización cuando busca en el mercado una solución de observabilidad? Únase a nosotros en este episodio mientras Dinesh Chandrasekhar, analista jefe y fundador de Stratola, habla con Krishna Yadappanavar, director ejecutivo de Kloudfuse. Krishna explica la observabilidad a través de la lente de tres factores:cardinalidad, control y costos.
Estas 3 C son clave para comprender y gestionar datos de observabilidad cada vez mayores. Estos factores no sólo son importantes para gestionar los datos sino también para aprovechar los datos y metadatos para análisis adicionales.
Un nuevo avance en el campo de la observabilidad es la observabilidad de modelos, especialmente los LLM que impulsan la IA generativa. Las 3 C también se aplican a este caso de uso emergente.

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

• El potencial de los datos de observabilidad
• Proliferación de herramientas
• Superar datos de observabilidad aislados
• Considerando los metadatos
• Visión general del coste

Invitado
Krishna Yadappanavar, director ejecutivo de Kloudfuse
Krishna Yadappanavar es cofundador y director ejecutivo de Kloudfuse, una plataforma de observabilidad unificada. Anteriormente cofundó SpringPath, consiguiendo una financiación de 94 millones de dólares y llevando a la empresa a una adquisición por parte de Cisco por 320 millones de dólares. Con más de 20 patentes, Krishna ha tenido un impacto significativo en las tecnologías de datos, virtualización y almacenamiento en Veritas, Commvault, EMC, VMware y Cisco. Fue coautor de VMFS de VMware y diseñó componentes críticos de la pila de virtualización de almacenamiento para ESX Server. Además, Krishna asesora e invierte en nuevas empresas emergentes en datos, virtualización, nube, seguridad e IA/ML, contribuyendo a la visión, la estrategia de producto, la ingeniería y los esfuerzos de comercialización.

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

Recursos
Smart Talk Episodio 6:AIOps y el futuro del monitoreo de TI
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:Canalizaciones de datos modernas y LLM
Smart Talk Episodio 2:El auge de las aplicaciones GenAI con datos en movimiento
Smart Talk Episodio 1:El panorama del ecosistema de datos en movimiento
Vea el mapa del ecosistema de datos en movimiento aquí
Obtenga más información sobre datos en movimiento en RTInsights aquí

Transcripción
Dinesh Chandrasekhar

Hola y bienvenido a este episodio de Smart Talk, una serie de liderazgo de Data in Motion. Y en este episodio tenemos un invitado especial, Krishna Yadappanavar. Es el director ejecutivo de Cloud Fuse. No es ajeno al ecosistema de startups. Es un emprendedor en serie. Ha creado un par de empresas antes de esto, por lo que le damos una calurosa bienvenida a Krishna para que tenga esta conversación sobre la observabilidad, que es, nuevamente, uno de los temas favoritos en esta serie. 

Krishna Yadappanavar

Gracias.

Dinesh Chandrasekhar

Entonces, Krishna, a modo de presentación, ¿por qué no nos cuentas sobre Kloudfuse y tu impulso para iniciar la empresa?

Krishna Yadappanavar (01:01):

Está bien, absolutamente. Gracias, Dinesh. Gracias por la cálida introducción. Hola gente, mi nombre es Krishna. Sí, he vivido en el Valle durante más de dos décadas y he trabajado con varias nuevas empresas y grandes empresas. El nombre de la fama es como VMware cuando era una startup temprana. Me uní y luego la vi crecer desde literalmente cerca de un millón de ERR a una empresa de 64 mil millones 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. Bien, a lo largo de este viaje lo que noté es que los datos son el secreto de todos los conocimientos, ya sea en el lado del análisis del producto o al proporcionar una solución como la virtualización o una solución como la copia de seguridad o la recuperación ante desastres. Después de haber creado mi startup, Springpath, que estaba en la hiperconvergencia, intentaba reunir la convergencia de almacenamiento, redes y seguridad en una caja que le vendí a Cisco.

Y después de pasar un tiempo en Cisco, estaba pensando ¿cuáles son las próximas grandes tendencias que vendrán? Esto fue a principios de 2020. Me encontré con un par de tendencias, como algunas de las tendencias relacionadas con cómo los datos con respecto a un desarrollador DevOps o SecOps están creciendo exponencialmente. ¿Cómo van a alterar el mercado las nuevas tendencias en los modelos de inteligencia artificial y LLM de aprendizaje automático en aquel entonces, los modelos LLM se encontraban en las primeras etapas? Y luego, cuando el cerebro humano comienza a pensar y reaccionar ante ciertos incidentes, es necesario que las máquinas actúen de manera similar. Estos fueron algunos de los problemas que encontramos y en la intersección de los tres, descubrí que resolver el problema no solo de la observabilidad, sino también de la observabilidad más el análisis y la automatización, además de los datos, que se centran en los desarrolladores y DevOps, es muy crítico. Eso llevó al comienzo de Kloudfuse:uno llevó al otro y ahora somos un equipo de alrededor de 40 personas.

Dinesh Chandrasekhar (03:16):

Bueno, felicidades 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. También trabajé en ese espacio durante bastante tiempo y el concepto de observabilidad ha evolucionado a lo largo de los años. Entonces, originalmente, hace 10 o 12 años, la gente estaba entusiasmada con hablar sobre monitoreo de infraestructura, monitoreo de red y todo eso, y luego, poco a poco, una cosa llevó a la otra y luego se agregaron capacidades de monitoreo de la nube y de contenedores. Y hoy tenemos esta noción de observabilidad que es bastante popular. La mayoría de las empresas que solían promocionar el seguimiento son ahora empresas de observabilidad. Y sé que empezó de nuevo en el espacio de la observabilidad con el deseo de crear una diferencia. ¿Cómo describirías esta evolución? ¿Qué era 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, me refiero a que, como desarrollador, escribo una aplicación monolítica que se ejecuta en máquinas físicas. Luego vi el advenimiento de la virtualización, ya sea como VMware o Hyper-V o las tecnologías de virtualización de código abierto y entró la contenedorización. Entonces, si nos fijamos en 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 se toma el producto cartesiano de esos atributos, entonces se vuelve realmente grande, en el orden de varios millones a miles de millones. Lo que llaman cardinalidad asociada a esa cardinalidad es el volumen de datos. A medida que aumenta el volumen de datos, la gente quiere transformar los datos A en datos B para obtener mejores análisis. Quieren automatizar ciertos flujos de trabajo además de los datos.

Quieren fragmentar los datos para poder brindarle mejores conocimientos. En resumen, a medida que el volumen de datos aumenta de la manera tradicional, oye, estaba monitoreando lo que se conoce como desaparición, que es el monitoreo tradicional. Luego estás mirando las incógnitas conocidas, que es el comienzo de la observabilidad y están las incógnitas completamente desconocidas en las que no sabes nada y te arrojan datos de varios terabytes a petabytes y tienes que analizar esos datos y llegar a la falta de una mejor palabra, dónde está exactamente el problema, cómo se correlaciona con el incidente, cuál es el análisis de la causa raíz, cuál es el análisis de impacto. Mientras los desarrolladores escriban código, esta complejidad y más y más servicios seguirán surgiendo. Esta complejidad irá aumentando cada vez más y, por lo tanto, este sigue siendo un espacio en evolución donde surgen nuevos desafíos.

Dinesh Chandrasekhar (06:14):

Fantástico. Entonces, la observabilidad es obviamente un problema difícil de resolver. Me encantaría explorar ¿por qué? Pero creo que también lo mencionaste un poco hace un momento, pero también tenemos un mercado abarrotado con una docena de proveedores que dicen:solucionamos esta parte de la observabilidad y ese tipo de observabilidad y todo eso, pero todavía hay una búsqueda de la solución ideal. Entonces, cada CIO con el que hablo siempre está buscando esta solución mágica que resuelva sus problemas. ¿Porqué es eso? ¿Existe una lente diferente a través de la cual hay que mirar para comprender por qué existe una necesidad diferente de conseguir esa solución ideal?

Krishna Yadappanavar (07:04):

Entonces, como me refería antes, déjame retroceder un poco, ¿verdad? ¿Qué es lo que busca el cliente cuando piensa en una solución de observación ideal? Empecemos por el problema. Clasifico este problema como las tres C:Cardinalidad, Control y Costo. Permítanme pasar al siguiente nivel de detalles. ¿Qué significan estas tres C? Cardinalidad, se trata de cómo tenemos ciertos datos, ya sea un punto métrico complicado o una línea de registro o un evento o un rastro o un lapso proveniente del rastreo de su distribuidor o el perfil de un perfil continuo, se adjunta con etiquetas o rótulos adicionales, a falta de una palabra mejor. Cuando se toma el producto cartesiano de los valores potenciales que pueden tomar esas etiquetas, crecerá muy, muy alto. Ahora cada punto de datos debe estar asociado con sus etiquetas.

Así que llamemos etiquetas a los metadatos. Y luego hay un dato. Diferentes esquemas tienen diferentes problemas. Algunos tienen muchos metadatos. Cuando vas al sitio de la matriz, cuando llegas a los registros y los tramos como el rastreo distribuido, son como datos pesados, 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 el pasado la gente pensaba:Oye, déjame enviar mis datos a un portal SaaS y luego el proveedor de SaaS administraría todos esos datos. Pero cuando hablo con el CTO, el CIO, el jefe de ingeniería, los desarrolladores, los arquitectos e incluso el CFO, piensan:déjenme tener el control de mis datos. ¿Qué quieren decir con eso? Se está produciendo una tendencia inversa:tengo tantos datos por varias razones, ya sea el costo del riesgo, los aspectos de seguridad o el volumen de los datos en sí.

No quieren enviar esos datos fuera de su VPC y esto tiene otro ángulo. Quieren incorporar todas las interfaces posibles que puedan imaginar, ya sea para un tipo de interfaz de observatorio tradicional, como la creación de paneles, alertas, SLO o cualquier función de análisis que pueda escribirse en un SQL tradicional o GraphQL o que puedan existir trabajos avanzados como Spark para ejecutar algunos análisis sobre los datos de observabilidad porque la observabilidad se ha convertido en ese pilar fundamental. Eso significa que tienen que ser dueños de los datos. Los datos no deben salir de la VPC. Cuando digo los datos, los datos que se ingieren, los datos que se consultan y los datos que se analizan, y por último pero no menos importante, está el costo. Si recurre a cualquier proveedor, ya sea un proveedor comercial de SaaS tradicional o un componente de código abierto, existen muchas soluciones de código abierto. El costo de la infraestructura, el costo del proveedor, 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 busca una organización tradicional que busca una solución ideal, una solución ideal de observabilidad

Dinesh Chandrasekhar (10:24):

Cardinalidad, control y costos. Creo que me encanta eso. Las tres C son una excelente manera de observar el espacio de observabilidad y cómo inferir qué es importante para los usuarios reales, etc. Hablando de costos, ya que lo tocamos, quiero hacerte esta pregunta también. Desde mi propia experiencia personal, cuando hablo con clientes que buscan una solución de observabilidad, lo que a menudo se quejan es:Oye, tengo al menos de ocho a 10 herramientas diferentes en cada departamento que tengo. Actualmente estoy analizando entre 30 y 40 herramientas en toda la organización. Ya estoy teniendo muchos costos para pagar estas licencias año tras año. “¿Por qué quiero una solución de observabilidad más?” es una respuesta que solía recibir, ¿verdad? Así que le haré la misma pregunta ahora que ha tocado el aspecto del costo. ¿Cómo abordar esa pregunta con un CIO y convencerlo o decirle por qué esto es mejor que tener 30 o 40 herramientas diferentes?

Krishna Yadappanavar (11:23):

Bien, gran pregunta. Entonces, para responder a esa pregunta, comencemos con el problema de por qué existe una proliferación de herramientas. Entonces, si nos fijamos en todo el ecosistema, tradicionalmente algunos proveedores, si tomo a los proveedores comerciales, fueron bastante buenos en ciertas corrientes. Si vas a los registros, puedes pensar en Splunk. Si piensas en métricas, piensas en Datadog. Luego dentro de Google y todos los FANG del mundo. Todo este movimiento de código abierto comenzó, especialmente con la llegada de Kubernetes, luego vinieron cosas como Prometheus, OpenTelemetry y todo eso.

Y existe todo este cambio que se está produciendo hacia la solución basada en código abierto. ¿Qué significa? Eso significa que los desarrolladores, los arquitectos y los chicos de DevOps quieren incorporar sus datos de observabilidad en un formato abierto. Es decir, incluso si elijo algún instrumento para instrumentar mi código o pongo a cualquier agente para recopilar mis datos, debería ser cien por ciento compatible con el código abierto. Por eso, cuando los proveedores comerciales también comenzaron a poner a sus agentes en código abierto, en el lado de las consultas, querían que toda la visualización, el panel de control, las alertas, todas estas capacidades fueran impulsadas por los lenguajes de consulta de código abierto. Es por eso que con la aparición de PromQL, LockQL, TraceQL, OpenTelemetry, ahora están probando otro lenguaje de consulta de código abierto.

 Ahora estás en este mundo donde tienes muchas opciones. Los clientes ya han elegido ciertos proveedores para cierta corriente.

Luego hay un movimiento de código abierto y luego diferentes equipos utilizan diferentes infraestructuras. Algunos se basan en Kubernetes, otros se basan en servidores sin servidor, otros se basan en ECS, Fargate y otras cosas. Eso es agregar otra dimensión y para lograr la velocidad y agilidad de toda la entrega del producto, CI/CD ha evolucionado en esta intersección para resolver los problemas muy rápidamente. Intentan buscar la solución precisa y, por tanto, terminan eligiendo la solución más precisa. Ahí es cuando, como solución de observabilidad ideal, si tuviera que comenzar mi pila de observabilidad para mi empresa, daría un paso atrás y diría, oye, si quiero reducir mi MTTR y MTTD, necesito recopilar todos los flujos finales de los datos de observabilidad. ¿Voy a n ? diferentes proveedores y elija n ¿Diferentes flujos, o voy a un lago de datos de observabilidad donde puedo juntar todos los flujos para que la correlación, las funciones avanzadas como la detección de valores atípicos, anomalías y causalidad sean relativamente más fáciles? Esa sería una solución ideal donde puede consolidar todo en un lago de datos donde puede preservar sus datos dentro de sus instalaciones.

Dinesh Chandrasekhar (14:18):

Fantástico. Y también me gustaría agregar que estoy de acuerdo en gran medida con el costo de la proliferación de herramientas porque los desarrolladores quieren crear sus propios productos y también han agregado muchas herramientas de código abierto a la combinación, pero también son compras a nivel de departamento. Entonces, un departamento de TI siente que puedo resolver este problema porque me permiten conseguir una solución curita, me permiten comprar esta herramienta disponible y usarla. Y luego, con el tiempo, se dieron cuenta de que habían agregado una herramienta más al arsenal y sin darse cuenta de que no estaban buscando árboles en el bosque. Por lo tanto, las conversaciones con el CIO siempre son interesantes sobre cómo se puede compactar o reducir la cantidad de herramientas que tiene en toda la empresa y tener una plataforma de observabilidad que abarque todos los departamentos, aplicaciones, contenedores de infraestructura y todo eso. 

Krishna Yadappanavar (15:08):

Absolutamente. Quiero añadir que ahora diferentes personas de la empresa también están analizando los mismos datos. Al igual que los desarrolladores de DevOps, todos los arquitectos analizan los datos de observabilidad con respecto a la infraestructura, las aplicaciones de contenedorización y todo eso. Usando los mismos registros. Los chicos de SecOps están intentando analizar los datos para buscar la seguridad y las amenazas. Mirando los datos similares provenientes de los registros o los rastros. Incluso los chicos de DataOps dicen:Oye, ¿qué tan buenas son mis operaciones de datos? Y ahora, con la llegada de LLM, incluso los chicos de LLM Ops están analizando datos similares para realizar su tipo de análisis. Así que es necesario que se produzca otra consolidación. Eso es algo que buscaría en una solución de observabilidad ideal. ¿Cómo puedo incorporar a todas las diferentes personas de una organización para que puedan aprovechar los datos del mismo llamado lago de datos?

Dinesh Chandrasekhar (16:05):

Verdaderamente el proverbial panel de vidrio único por el que todos hemos estado luchando. Entonces es algo bueno. Entonces quiero tocar otra cosa que mencionaste brevemente mientras explicabas la respuesta anterior, que trataba sobre la reducción del MTTR, ¿verdad? Entonces, como punto fundamental de la observabilidad, se trata no solo de solucionar problemas sino también de reducir el MTTR, reducir el ruido de alerta y ese tipo de métricas también. Por lo tanto, definitivamente evita que los SRE y los operadores de TI tengan que dividirse y descubrir dónde está el problema y todo eso como un requisito fundamental clave para resolver esto. Necesita acceso a eventos en tiempo real a medida que suceden. Si se ingresó un registro en una aplicación en particular o en un servidor en particular sobre una actividad maliciosa o algo así, necesita acceso a ese evento de inmediato para poder comprender dónde está esa anomalía, qué está sucediendo en su infraestructura, por qué este pico en particular en un hilo de memoria en particular o lo que sea.

Por lo tanto, es necesario descubrirlo y, para que eso suceda, también es necesario tener la capacidad de ingerir todo esto en tiempo real. La inmediatez de los datos, que es uno de mis términos favoritos durante el último año, he estado hablando de ello, y la frescura de los datos es de primordial importancia aquí. De esto es de lo que estamos hablando, de qué tan actualizados están los datos, de qué tan rápido se puede resolver ese problema en particular o tal vez incluso evitar algo que está a punto de suceder en este contexto particular de observabilidad, particularmente cuando se habla de cientos y miles de servidores que están monitoreando y todo eso, o dónde se señala diciendo, aquí es donde está el problema en términos de lograr que los datos estén lo más actualizados posible o no. ¿Depende en gran medida de los mecanismos de ingestión? Porque hablaste de TEL y otros tipos de técnicas de instrumentación y todo eso también. Entonces, ¿de qué otra manera lo pensarías o lo verías desde esta perspectiva de qué tan rápido puedo obtener acceso a datos en tiempo real?

Krishna Yadappanavar (18:03):

Bien, otro gran aspecto del equipo de observación. Tienes toda la razón, Danesh. Entonces, la dimensión clave donde se consumen los datos de observación es qué tan rápido puedo tener los datos, en el momento en que los datos salen de la fuente de datos, ya sea su aplicación o sus componentes de infraestructura o su plataforma, como componentes de código abierto y cosas así. Entonces, si nos fijamos en cómo ha evolucionado la industria en los últimos cinco a diez años, han aparecido los servicios de transmisión en tiempo real y las bases de datos en tiempo real. Si nos fijamos en las soluciones de observación tradicionales, quiero decir que no podían aprovechar esas funciones porque la tecnología era relativamente antigua. Entonces, con la llegada de la transmisión en tiempo real y las bases de datos en tiempo real, puede acceder a los datos lo más rápido posible. Esa es la medida de lo que se llama frescura de los datos desde el momento en que salen de la aplicación hasta que son fácilmente consultables, eso es todo lo que importa.

Luego está ese aspecto de, 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 siguiente conjunto de problemas. Eso significa que debería poder transformar datos de un dato en otros datos. Oye, recibo una serie de registros. ¿Puedo ver rápidamente una métrica de los registros? Obtengo una serie de tramos. ¿Puedo mirar algún atributo dentro de ese lapso o un rastro para analizar esos datos? Porque estos atributos suelen estar correlacionados y así es como se produce la depuración. Entonces esa es la siguiente dimensión. Y luego la tercera dimensión es la analítica avanzada. Además de esos datos, ¿puedo traer algunos modelos estadísticos interesantes o de lenguaje grande para analizar los datos y encontrar lo que se llama valores atípicos en mi sistema?

¿Puedo encontrar las anomalías en mi sistema? Bien, ¿puedo analizar el aspecto estacional de mis datos? ¿Puedo pronosticar mis datos en función de lo que he visto en el pasado? ¿El aspecto estacional de los datos? Todo esto es lo que yo llamo el paquete de análisis avanzado. Entonces, cuando piensa en la solución general después de resolver la actualización de los datos, debe pensar en los datos como una unidad de un bloque y luego en cómo se puede ajustar cada bloque y luego establecer la función de análisis. Y luego lo natural que necesitaremos es:"Oye, ya analicé esto una vez, ¿puedo automatizarlo?". Eso se convierte en la extensión natural de todo el asunto. Por eso, junto con el problema de las tres C, hemos visto a los clientes preguntar cómo puedo observar, analizar y automatizar mis datos de observación.

Dinesh Chandrasekhar (20:57):

Muy guay. Muy guay. Y luego, como parte de su respuesta, también mencionó la palabra mágica LLM, grandes modelos de lenguaje. Quiero decir, hoy en día no se puede tener una conversación sin hablar de los LLM de GenAI. Me alegra que lo hayas mencionado porque definitivamente podría preguntarte sobre esto, que es la observabilidad del LLM. Parece que se trata de un espacio emergente de repente, dado que tenemos una proliferación de LLM en todas partes y la gente tiene dificultades para comprender cómo se desempeñan, etc. Así que cuéntanos sobre eso. Parece que Kloufuse también está construyendo algo en ese frente, ¿verdad? Así que cuéntanos más al respecto.

Krishna Yadappanavar (21:32):

Quiero decir, sí. Me refiero fundamentalmente al conjunto, los modelos LLM se están implementando en varios casos de uso, ¿verdad? En cuanto a falta de una palabra mejor. El dinamismo de los datos cambia, especialmente en el mundo de la observabilidad, los datos son muy dinámicos. Siempre es difícil construir el modelo LLM adecuado para realizar determinadas operaciones. Así que hemos analizado el problema de dos maneras. ¿Cómo puedo aprovechar ciertos modelos LLM además de los datos de observabilidad existentes, que son consumidos por todas las diferentes personas de las que hablé, ya sean DevOps, SecOps, DataOps o LLMOps? Ese es un aspecto de esto. Y está el otro aspecto de que estoy desarrollando una aplicación en la que el LLM es un componente muy, muy crítico. ¿Cómo puedo observar la observabilidad completa de una aplicación que produce los datos, que se introducen en el LLM, y luego hay muchos consumidores que consumen esos datos de esos modelos de LLM?

Así que estamos pensando, de hecho, puedo decir que somos los primeros en pensar de principio a fin en cuál es la verdadera observabilidad de todas las aplicaciones que se desarrollan utilizando los modelos LLM. Porque me he encontrado con muchas soluciones simplemente observando la observabilidad del modelo, como la deriva y cosas así. Pero estamos mirando de principio a fin. Ese es un aspecto muy interesante porque gran parte de la observabilidad de las aplicaciones de infraestructura va junto con la observabilidad del modelo y el resto de las cosas. Y por último, pero no menos importante, si le preguntas a cualquier CIO o CFO, el costo del LLM, al igual que las soluciones actuales, el costo es otra dimensión clave. Otro aspecto es cómo mantener ese costo o incluso proporcionar análisis sobre las métricas de costos de los modelos LLM. Así que hay que analizar todo:el rendimiento, la falta de, llamémoslo APM para aplicaciones LLM, y luego el costo. Estas son las dimensiones típicas en las que lo mirarías.

Dinesh Chandrasekhar

Un espacio muy interesante y emocionante y definitivamente estoy emocionado de saber lo que vendrá en ese espacio en los próximos meses. Muchas gracias, Krishna. Esta ha sido una conversación muy, muy maravillosa. Me encantó tenerte en nuestro programa. Me encanta hablar de observabilidad. Voy a recordar tus tres C:Cardinalidad, Control y Costos. Creo que es una excelente manera, un gran mantra, de observar la observabilidad. Así que gracias por todas las ideas. Aprecio que estés aquí. Gracias.

Krishna Yadappanavar

Muchas gracias Dinesh. Gracias por invitarme a tu chat web.