Actualización de estado de Elastic N.V.

Adelante. Buenos días a todos y bienvenidos.

Soy Alex Kurtzman, vicepresidente de Relaciones con Inversionistas aquí en Elastic. Gracias por acompañarnos hoy para profundizar en nuestra nueva oferta de métricas. Me acompañan Baha Azarmi, gerente general de Observability, y Santosh Krishnan, vicepresidente sénior de Soluciones de Seguridad y Observability. Para la agenda de hoy, Baha comenzará con una breve presentación, seguida de un video corto de un cliente; después abriremos el espacio para preguntas y respuestas. Primero, permítanme repasar rápidamente nuestro aviso legal. Nuestra presentación de hoy incluirá declaraciones prospectivas, que pueden incluir predicciones y expectativas sobre el mercado y la demanda de nuestros productos y soluciones, así como las capacidades previstas de nuestros productos y soluciones.

Estas declaraciones prospectivas se basan en factores que conocemos actualmente, se refieren únicamente a la fecha de esta presentación y están sujetas a riesgos e incertidumbres que podrían hacer que los resultados reales difieran sustancialmente. Renunciamos a cualquier obligación de actualizar o revisar estas declaraciones prospectivas, salvo que la ley lo exija. Consulten este aviso sobre riesgos e incertidumbres que se muestra aquí, así como los que se describen con mayor detalle en nuestros documentos presentados ante la Securities and Exchange Commission. Dicho esto, le cedo la palabra a Baha.

Gracias, Alex. Pasemos a la siguiente diapositiva. Si puedo. Muy bien. Hola a todos. Soy Baha. Soy el gerente general de Observability aquí en Elastic. Llevo 11 años en Elastic y hoy es un placer presentarles nuestra nueva oferta de métricas. Nuestra nueva oferta de métricas se lanzó casi al inicio de nuestro año fiscal, en junio. Con esta nueva oferta de métricas, entramos en este mercado con una solución que no solo cumple los requisitos de nuestros clientes, sino que también supera algunas de las mejores soluciones de métricas del mercado. En esta presentación verán cómo lo hicimos.

Pero, a grandes rasgos, rediseñamos la arquitectura de Elasticsearch para las métricas; también nos adaptamos a la situación de nuestros clientes y nos aseguramos de crear nuestra solución de métricas para lo que hacen hoy, en particular, trabajar con cargas de trabajo de IA. Así que hay 3 características para una solución de métricas. Primero, es extremadamente rápida. Si se entra en el mercado de métricas, hay que ser rápido; ese es uno de los principios rectores de una solución. Comparamos el rendimiento con soluciones de la competencia, como Prometheus y Mimir. Más adelante en esta presentación entraré en más detalle sobre las cifras. También nos aseguramos de que nuestros clientes no tengan que pasar de una solución a otra cuando tienen con nosotros sus registros, trazas y métricas. Deben permanecer en la misma plataforma. El almacén de datos debe ser el mismo.

Para ellos, es completamente transparente almacenar con nosotros todas esas señales cuando hacen observabilidad, así como consultar los datos en Elastic o usar las distintas experiencias que ofrecemos para observabilidad. Todo está en la misma plataforma. Por último, lo creamos para la IA. Con la IA, la forma de las cargas de trabajo ha cambiado: ahora hay más agentes que aplicaciones tradicionales, lo que genera muchas más señales, muchos más datos y muchas más métricas que antes. Así que diseñamos nuestra solución de métricas para que fuera lo más eficiente posible y pudiera manejar ese nuevo tipo de cargas de trabajo. Pero antes de entrar en más detalles sobre lo que hicimos, permítanme establecer el contexto para todos. Si no conocen las métricas, son la señal principal en observabilidad. Literalmente, son lo que despierta a los ingenieros a las 3:00 A.M.

por la mañana cuando hay un incidente, y lo que hace que se envíen alertas a las personas cuando hay algo que revisar. Cuando usan una solución de observabilidad, crean reglas. Esas reglas activan alertas y, el 99% del tiempo, se basan en métricas. Aquí hay un par de ejemplos en pantalla. Supongamos que tienen una aplicación, una aplicación web, y están observando el tráfico de esa aplicación. Por ejemplo, observarían la cantidad de solicitudes HTTP. Esta aplicación depende de una infraestructura, de una pila de aplicaciones. Hay distintas tecnologías involucradas y recursos asignados a esta aplicación. Así que observarían la utilización de recursos, como la CPU. También pueden observar aspectos como la latencia de las solicitudes que llegan a las API que exponen a través de esta aplicación. Muchas de esas características de su aplicación generan métricas.

Su aplicación y su infraestructura generan métricas. Una solución de observabilidad captura esas métricas; luego crean reglas que activan alertas y hacen que se envíen avisos a las personas. Lo que ha cambiado es que, si observan una aplicación tradicional, por ejemplo, una aplicación bancaria, y ustedes, como usuarios, acceden a su cuenta bancaria y revisan su estado de cuenta, se desplazan por él y hacen clic en un elemento. Todas esas son rutas y transacciones predefinidas dentro de esas aplicaciones bastante tradicionales. Tienen una interfaz, un back end, un almacén de datos, una base de datos, microservicios y despliegues en la nube. Todo eso lo incluyo en la categoría de aplicación tradicional. Así que no solo se conocen bien esas transacciones, sino que, además, como dije, generan trazas, registros y métricas. Por eso, se puede prever el volumen que generarán.

Pero con los agentes es muy diferente. La IA está provocando una verdadera explosión de métricas. Cuando digo IA, pueden pensar en los distintos tipos de cargas de trabajo o aspectos que necesitan observar, como las llamadas a LLM, los ciclos de GPU, las consultas RAG, los agentes y los entornos de ejecución. Todo eso genera un nuevo conjunto de señales de observabilidad que es necesario capturar. El desafío es que, como todos saben, cuando interactúan con un LLM, hay pasos de razonamiento, y esos pasos dependen de lo que solicitan. El proceso recurre a llamadas a herramientas. No necesariamente se conocen esas herramientas de antemano. Ahora hay agentes que llaman a sus aplicaciones tradicionales, probablemente expuestas mediante MCP, y la cantidad de turnos que tendrán con el agente es realmente impredecible. Eso crea una nueva paradoja para los clientes.

Primero, los clientes tienen que pensar: ¿cómo voy a manejar todos esos datos? Sabemos que hay soluciones que penalizan a los clientes y no les permiten conservar todos los datos. El problema es que entonces empiezan a tener puntos ciegos. Tienen que hacer concesiones respecto de la cantidad de datos que pueden conservar. Luego, cuando ocurre un incidente, no obtienen una visión completa de lo que pasó. Les resulta difícil entender cuál es la causa raíz. Nuevos desafíos con la IA. Cuando empezamos a pensar cómo llevaríamos al mercado esta nueva oferta de métricas, establecimos un par de principios rectores, que explicaré con más detalle en diapositivas posteriores.

Primero, introdujimos una nueva forma de almacenar métricas y también de administrarlas. Incluye funcionalidades que acumulan los datos automáticamente, reducen su resolución mediante muestreo o los comprimen. Segundo, queríamos asegurarnos de que quienes usan soluciones de métricas se sintieran familiarizados al llegar a Elastic y usar nuestra oferta de métricas. Prestamos especial atención a admitir estándares del mercado como PromQL, y lo veremos. Por último, de nuevo, lo creamos para la escala de la IA. Vieron que la IA genera más datos y nuevas cosas que observar; lo creamos para eso, con la eficiencia necesaria para manejar esas cargas de trabajo. Probablemente conocen Elastic por los registros. Nuestros clientes confían en nosotros para sus registros desordenados. Estamos más que dispuestos a recibir todos esos datos no estructurados.

En esencia, somos un motor de búsqueda, así que somos muy buenos con los datos estructurados y no estructurados. Los registros ingresan y llegan a un almacén de documentos. Extraemos esos campos y luego los ponemos a disposición para agregarlos. Podemos hacer búsquedas de texto completo sobre ellos. Esa es nuestra historia con los registros y la forma en que los gestionamos. Usamos un almacén de documentos. En el caso de las métricas, la situación es muy diferente porque tienen una estructura distinta a la de los registros. Son números y vienen con etiquetas. Por ejemplo, tienen un número que representa el uso de CPU. Tienen una marca de tiempo. Tienen dimensiones. Pertenece a este host, que está desplegado en este pod de Kubernetes, desplegado en esta región del mundo, en este proveedor de nube, etcétera. Hay muchas dimensiones diferentes. Para manejar las métricas, rediseñamos por completo la arquitectura de Elasticsearch.

Creamos un almacén columnar dentro de Elasticsearch porque las métricas plantean desafíos propios. Acabo de hablar de las dimensiones. Primero, las dimensiones son algo que resulta muy difícil de gestionar para las soluciones de métricas existentes en el mercado. Queríamos asegurarnos de no limitar la cardinalidad para nuestros clientes. Son términos que escucharán mucho cuando se habla de las soluciones de métricas disponibles. No queremos limitar la cardinalidad. Pueden tener tantas dimensiones como quieran. Luego decimos eso y nuestros usuarios preguntan: «De acuerdo, pero ¿qué implica al consultar?». Cuando tienen muchas dimensiones, empieza a ser difícil administrar todos esos datos en memoria.