Cada factura de la nube cuenta una historia, pero leerla puede requerir traducir millones de elementos de docenas de proveedores de nube e IA en algo que un director financiero, un líder de ingeniería o un equipo de FinOps realmente pueda utilizar. Ese es el problema que resuelve nOps. La plataforma de la empresa administra más de 5 mil millones de dólares en gasto anual en la nube para cientos de clientes, convirtiendo datos sin procesar de facturación y uso en paneles en tiempo real donde las empresas pueden ver exactamente a dónde va su dinero, detallado por departamento, centro de costos o etiqueta personalizada.
Los clientes esperan que esa visibilidad sea inmediata. Cuando cambia una recomendación de compromiso, cuando el gasto aumenta de forma inesperada en una cuenta o cuando una nueva carga de trabajo de IA comienza a generar costos, los paneles deben reflejarlo en tiempo real. nOps ofrece vistas de paneles personalizables, y los datos detrás de ellos deben mantenerse actualizados y responsivos en la configuración única de cada cliente. Como socio de Built on Databricks, nOps reemplazó recientemente Apache Druid con Lakehouse//RT para impulsar esa capa en tiempo real, al tiempo que reduce los costos de infraestructura y consolida la arquitectura en una única plataforma gobernada.
Construcción de una capa en tiempo real para la próxima generación de clientes empresariales
Durante años, la capa de consultas en tiempo real detrás de los paneles de los clientes de nOps se ejecutó en Apache Druid. La empresa comenzó con un despliegue autohospedado y luego pasó a un servicio administrado de Druid. Pero a medida que la plataforma crecía y los clientes empresariales traían requisitos de informes cada vez más complejos, se amplió la brecha entre lo que el negocio necesitaba y lo que Druid podía ofrecer.
"Simplemente no podíamos obtener el rendimiento que necesitábamos", dijo Jordan Stein, Director de Ingeniería en nOps. "Y era muy difícil sacarle provecho". El desafío no era solo la velocidad. nOps permite a los clientes definir sus propias asignaciones, etiquetas y agrupaciones, por lo que los paneles de dos clientes nunca son iguales. Las consultas que impulsan esas vistas pueden ser muy complejas, algunas de hasta 30,000 líneas de SQL con coincidencia de cadenas en billones de filas. A medida que nOps consiguió cuentas empresariales más grandes con más departamentos, más centros de costos y requisitos de informes más detallados, las consultas se hicieron más largas y exigentes. Estos eran los clientes a los que nOps más quería servir, y la capa en tiempo real existente estaba frenando a la plataforma.
El equipo necesitaba una plataforma que pudiera manejar toda la complejidad de esas consultas sin requerir que nOps sacara sus datos de S3. Con aproximadamente 380 TB de datos de infraestructura en la nube en S3 impulsando sus tablas Delta, duplicarlos en una capa de servicio separada añadía costos, latencia y complejidad operativa que el equipo quería eliminar por completo.
Lakehouse//RT: Cero movimiento de datos, reversiones instantáneas
nOps ya estaba usando vistas de métricas de Databricks en producción y ejecutando su base de datos de aplicaciones en Lakebase cuando se lanzó Lakehouse//RT. El momento coincidió perfectamente con la búsqueda del equipo de un nuevo motor en tiempo real. "Este era exactamente el problema que intentábamos resolver", dijo Stein. "Desde el momento en que obtuvimos acceso, quedó claro que Lakehouse//RT era un reemplazo directo para nuestra capa de Druid".
El requisito más crítico era el cero movimiento de datos. nOps tiene aproximadamente 380 TB de datos en S3, y duplicarlos en una capa de servicio separada era costoso y operativamente doloroso. Lakehouse//RT consulta las mismas tablas Delta directamente, sin copias, sin canalizaciones de ingesta y sin almacenamiento secundario. "Cualquiera sabría que intentar mover más de 380 terabytes de datos a diferentes plataformas es una pesadilla y es costoso", dijo Stein. "Con Lakehouse//RT, no requirió ningún cambio en los datos subyacentes".
La migración también permitió reversiones instantáneas de versiones de tablas. En Druid, revertir la versión de una tabla significaba enviar un nuevo trabajo de ingesta y esperar hasta tres horas. Con Lakehouse//RT leyendo directamente de las tablas Delta, las reversiones ocurren de inmediato. "Ese es uno de los cambios más impactantes para nosotros", dijo Stein. "Los datos que ve el cliente son la misma tabla en la que acabamos de terminar de escribir. No tenemos que perseguir un duplicado de esos datos en otra ubicación".
Reducción de costos de más de 6 veces y una plataforma de datos unificada
El impacto financiero ha sido sustancial. La arquitectura anterior de nOps dependía de clústeres de Druid siempre activos. Con el escalado automático sin servidor de Lakehouse//RT, el equipo redujo el gasto en infraestructura en tiempo real a aproximadamente el 16% del costo anterior, es decir, más de 6 veces más económico. La migración también eliminó 40 TB de datos de servicio duplicados que se habían almacenado fuera de S3 en la capa de almacenamiento secundaria de Druid.
Más allá de los paneles, nOps también enruta sus agentes de IA internos y su arquitectura MCP (Model Context Protocol) a través de Lakehouse//RT, lo que ha mejorado significativamente los tiempos de respuesta y la calidad de la experiencia de chat conversacional para los clientes. "Hacer que los datos subyacentes sean los mismos entre lo que estamos escribiendo en el backend y lo que ve el cliente en el frontend es enorme", dijo Stein. "Hay mucho valor en mover estas arquitecturas codependientes a un solo lugar".
Como socio de Built on Databricks, la experiencia de nOps ilustra por qué Lakehouse//RT es muy adecuado para socios ISV que desarrollan aplicaciones con uso intensivo de datos. Las plataformas de observabilidad y gestión de costos en la nube manejan volúmenes masivos de datos, consultas complejas definidas por el cliente y la expectativa de respuesta en tiempo real. Lakehouse//RT permite a los ISV atender esas cargas de trabajo directamente desde el lakehouse sin mantener una base de datos en tiempo real separada, lo que reduce tanto los costos de infraestructura como la complejidad operativa. La estrecha colaboración que nOps tuvo con el equipo de producto de Databricks durante la beta aceleró aún más la migración. "Ese tipo de asociación es muy valiosa cuando tienes equipos que pueden impulsar la nueva tecnología y proporcionar comentarios valiosos", dijo Stein.
nOps reemplazó su capa de consultas en tiempo real administrada de Apache Druid con Databricks Lakehouse//RT, impulsada por el motor Reyden. Lakehouse//RT consulta directamente las mismas tablas Delta almacenadas en S3, eliminando la necesidad de una base de datos de servicio separada, la duplicación de datos y las canalizaciones de ingesta.