Cada fatura de nuvem conta uma história, mas lê-la pode exigir a tradução de milhões de itens de linha de dezenas de provedores de nuvem e IA em algo que um CFO, um líder de engenharia ou uma equipe de FinOps possa realmente colocar em prática. Esse é o problema que o nOps resolve. A plataforma da empresa gerencia mais de US$ 5 bilhões em gastos anuais em nuvem para centenas de clientes, transformando dados brutos de faturamento e uso em painéis em tempo real onde as empresas podem ver exatamente para onde vai o dinheiro, detalhado por departamento, centro de custo ou tag personalizada.
Os clientes esperam que essa visibilidade seja imediata. Quando uma recomendação de compromisso muda, quando os gastos disparam em uma conta inesperada ou quando uma nova carga de trabalho de IA começa a gerar custos, os painéis precisam refletir isso em tempo real. A nOps oferece visualizações de painel personalizáveis, e os dados por trás delas precisam se manter atualizados e responsivos em toda a configuração exclusiva de cada cliente. Como parceira Built on Databricks, a nOps substituiu recentemente o Apache Druid pelo Lakehouse//RT para dar suporte a essa camada em tempo real, reduzindo os custos de infraestrutura e consolidando a arquitetura em uma única plataforma governada.
Construindo uma camada em tempo real para a próxima geração de clientes corporativos
Durante anos, a camada de consultas em tempo real por trás dos painéis de clientes da nOps rodava no Apache Druid. A empresa começou com uma implantação auto-hospedada e depois mudou para um serviço gerenciado do Druid. Mas à medida que a plataforma crescia e os clientes corporativos traziam requisitos de relatórios cada vez mais complexos, a lacuna entre o que o negócio precisava e o que o Druid podia entregar aumentou.
"Simplesmente não conseguíamos o desempenho de que precisávamos", disse Jordan Stein, Diretor de Engenharia da nOps. "E era muito difícil extrair valor disso." O desafio não era apenas a velocidade. A nOps permite que os clientes definam seus próprios mapeamentos, tags e agrupamentos, de modo que nenhum painel de cliente seja igual ao outro. As consultas que alimentam essas visualizações podem ser altamente complexas, algumas com até 30.000 linhas de SQL com correspondência de strings em trilhões de linhas. À medida que a nOps conquistava contas corporativas maiores com mais departamentos, mais centros de custo e requisitos de relatórios mais granulares, as consultas ficavam mais longas e exigentes. Esses eram os clientes que a nOps mais queria atender, e a camada em tempo real existente estava segurando a plataforma.
A equipe precisava de uma plataforma que pudesse lidar com toda a complexidade dessas consultas sem exigir que a nOps tirasse seus dados do S3. Com cerca de 380 TB de dados de infraestrutura em nuvem no S3 alimentando suas tabelas Delta, duplicá-los em uma camada de atendimento separada adicionava custos, latência e sobrecarga operacional que a equipe queria eliminar totalmente.
Lakehouse//RT: Zero movimentação de dados, reversões instantâneas
A nOps já estava usando as visualizações de métricas do Databricks em produção e executando seu banco de dados de aplicativos no Lakebase quando o Lakehouse//RT foi lançado. O momento coincidiu perfeitamente com a busca da equipe por um novo mecanismo em tempo real. "Esse era exatamente o problema que estávamos tentando resolver", disse Stein. "Desde o momento em que tivemos acesso, ficou claro que o Lakehouse//RT era um substituto direto para a nossa camada do Druid."
O requisito mais crítico era zero movimentação de dados. A nOps tem cerca de 380 TB de dados no S3, e duplicá-los em uma camada de atendimento separada era caro e trabalhoso operacionalmente. O Lakehouse//RT consulta as mesmas tabelas Delta diretamente, sem cópias, sem pipelines de ingestão e sem armazenamento secundário. "Qualquer um sabe que tentar mover mais de 380 terabytes de dados entre diferentes plataformas é um pesadelo e sai caro", disse Stein. "Com o Lakehouse//RT, não foi necessária nenhuma alteração nos dados subjacentes."
A migração também desbloqueou reversões instantâneas de versão de tabela. No Druid, reverter uma versão de tabela significava enviar um novo trabalho de ingestão e esperar até três horas. Com o Lakehouse//RT lendo diretamente das tabelas Delta, as reversões acontecem imediatamente. "Essa é uma das mudanças mais impactantes para nós", disse Stein. "Os dados que o cliente vê são a mesma tabela para a qual acabamos de escrever. Não precisamos correr atrás de uma duplicata desses dados em outro local."
Redução de custos de mais de 6x e uma plataforma de dados unificada
O impacto financeiro foi substancial. A arquitetura anterior da nOps contava com clusters do Druid sempre ativos. Com o auto scaling sem servidor do Lakehouse//RT, a equipe reduziu os gastos com infraestrutura em tempo real para cerca de 16% do custo anterior, ou seja, ficou mais de 6 vezes mais barata. A migração também eliminou 40 TB de dados de atendimento duplicados que haviam sido armazenados fora do S3 na camada de armazenamento secundário do Druid.
Além dos painéis, a nOps também direciona seus agentes de IA internos e a arquitetura MCP (Model Context Protocol) por meio do Lakehouse//RT, o que melhorou significativamente os tempos de resposta e a qualidade da experiência de chat conversacional para os clientes. "É incrível ter os dados subjacentes idênticos entre o que estamos gravando no backend e o que o cliente vê no frontend", disse Stein. "Há muito valor em colocar essas arquiteturas interdependentes em um só lugar."
Como parceira Built on Databricks, a experiência da nOps ilustra por que o Lakehouse//RT é ideal para parceiros ISV que criam aplicativos com uso intenso de dados. As plataformas de observabilidade e gerenciamento de custos de nuvem lidam com volumes massivos de dados, consultas complexas definidas pelo cliente e a expectativa de resposta em tempo real. O Lakehouse//RT permite que os ISVs atendam a essas cargas de trabalho diretamente do lakehouse sem manter um banco de dados em tempo real separado, reduzindo os custos de infraestrutura e a complexidade operacional. A estreita colaboração que a nOps teve com a equipe de produtos do Databricks durante a versão beta acelerou ainda mais a migração. "Esse tipo de parceria é muito valioso quando você tem equipes que podem impulsar a nova tecnologia e fornecer feedback valioso", disse Stein.
A nOps substituiu sua camada de consultas em tempo real do Apache Druid gerenciado pelo Databricks Lakehouse//RT, alimentado pelo mecanismo Reyden. O Lakehouse//RT consulta diretamente as mesmas tabelas Delta armazenadas no S3, eliminando a necessidade de um banco de dados de atendimento separado, duplicação de dados e pipelines de ingestão.