Jupiter fecha uma lacuna de 20% a 40% na visibilidade dos gastos de infraestrutura com a DoiT

O DataHub é a parte do Cloud Intelligence criada exatamente para essa lacuna. Ele pega dados de custo de fora dos provedores de nuvem e os coloca no mesmo lugar que a fatura da nuvem. Os dados chegam por API ou upload de CSV, com dimensões e métricas definidas pelo cliente, de modo que a fatura de um fornecedor pequeno demais para justificar uma integração nativa se torna uma fonte que a plataforma trata como qualquer outra: disponível para relatórios, orçamentos, alertas e previsões.

A capacidade já existia, mas o que a Jupiter ganhou foi alguém para construir junto.

Satyam Gupta, junto com os Forward Deployed Engineers (FDE) da DoiT, partiu da forma como as faturas realmente chegam, e não da referência da API. Ele converteu um PDF real da Jupiter para o formato do DataHub, fez a ingestão e construiu os relatórios e alertas por cima, para que o time pudesse ver o resultado pronto antes de se comprometer. Os Forward Deployed Engineers da DoiT entraram em cena onde o trabalho ia além da configuração, enquanto a Jupiter testava a solução e definia como os dados deveriam ser lidos, e o time de Satyam automatizou o fluxo com base nesse feedback.

"Na integração do DataHub, o time da DoiT foi extremamente hands-on, a ponto de montar o primeiro script e pipeline de ingestão para nós.", compartilhou Kyle.

O que eles entregaram se encaixa nos hábitos do time financeiro. As faturas chegam a uma pasta do Google Drive, o pipeline faz o parsing e as carrega no Cloud Intelligence ao lado do faturamento dos provedores de nuvem. A Jupiter fez pequenos ajustes e colocou tudo em produção.

A Jupiter poderia ter acompanhado os fornecedores faltantes por conta própria, mas isso deixaria os dados de custo em dois lugares — e uma previsão só pode rodar sobre um. 60% na DoiT e o resto em outro lugar não é uma base sobre a qual dá para planejar. Kyle já havia usado outras plataformas de FinOps, e é aí que ele traça o contraste.

"A DoiT realmente conseguiu preencher a lacuna que eu não vi em algumas das plataformas de FinOps que usei no passado." Kyle Espinola, Head de Engenharia de Plataforma, Jupiter

A Jupiter é um agregador de exchanges descentralizadas na Solana. O trabalho de um agregador é encontrar a melhor rota para uma operação em meio à liquidez fragmentada, e a Jupiter fornece a inteligência de roteamento e a infraestrutura de leitura para isso. Ela não faz custódia de fundos nem intermedia operações. Hoje, várias verticais financeiras rodam sobre essa base, e uma série de aquisições no último ano adicionou mais algumas. Cada uma chegou com sua própria infraestrutura — e é assim que uma empresa construída principalmente sobre a AWS também carrega workloads no Cloudflare Workers, no Google Cloud e em bare metal.

Manter tudo isso funcionando é o trabalho da engenharia de plataforma. Kyle Espinola lidera esse grupo, responsável por Site Reliability Engineering (SRE), infraestrutura, automação de deploy e FinOps, e publica os golden paths que todos os outros times seguem para colocar um serviço no ar e mantê-lo saudável. Sua ambição para a plataforma acompanha a ambição do produto: o super app que a Jupiter está construindo deve ser uma única plataforma por baixo, e não várias costuradas umas às outras.

A Jupiter alimenta o DataHub com 26 fornecedores externos — entre eles seus provedores de RPC, ClickHouse e Cloudflare — ao lado do faturamento de AWS e Google Cloud. A fatia que Kyle já descreveu como mais de 30% não reportada agora está no mesmo sistema que todo o resto.

"Passar de 60% para 100% em um único sistema destrava muita coisa, e o DataHub é uma ótima ferramenta, flexível, que realmente nos permite preencher as lacunas e aproveitar todos os relatórios.", diz Kyle.

O número de cobertura não é o retorno inteiro. Previsões e análises de uso histórico rodam sobre o catálogo completo de fornecedores, e não apenas sobre a fatia da nuvem — e é sobre isso que a Jupiter planeja. Orçamentos e alertas alcançam fornecedores que não tinham monitoramento nenhum, então uma fatura que dá um salto é sinalizada na hora, em vez de descoberta depois. A catalogação que Kyle descreveu — lembrar de registrar uma fatura antes que o número se perca — agora é trabalho do pipeline, não de uma pessoa.

A cobertura era o pré-requisito. A próxima pergunta é o lucro.

"Temos uma visibilidade muito clara da receita que um produto gera, mas, para entender o lucro, você precisa conhecer o custo. E uma grande parte do nosso custo de produto está nos gastos com infraestrutura.", compartilhou Kyle.

As alocações vão mapear esses gastos por linha de produto entre os fornecedores, e o Kubernetes Intelligence, que será ativado neste trimestre, vai detalhar o ambiente compartilhado do Elastic Kubernetes Service (EKS) por namespace. DoiT e AWS estão trabalhando na consolidação em paralelo, garantindo acordos contratuais e créditos de migração para levar os workloads adquiridos para a AWS.