A Rabbot é uma empresa brasileira de tecnologia que desenvolve uma plataforma de inteligência operacional para a gestão de frotas pesadas. A companhia atende transportadoras e operações logísticas e emprega inteligência artificial para conectar as áreas de pátio, manutenção e compra de peças. Tem sede em São Paulo, no bairro de Pinheiros.
A plataforma organiza-se em três módulos. O de Disponibilidade oferece visão integrada da frota para o planejamento de rotas e o uso dos ativos; o de Manutenção acompanha e automatiza as etapas de conservação dos veículos; e o de Aquisição de Peças centraliza cotações em um marketplace que conecta a operação a fornecedores. A plataforma integra sistemas como ERP e TMS para reunir dados dispersos em um único ambiente. A Rabbot posiciona-se como uma camada de visibilidade sobre a operação de frota, com foco na redução de custos de manutenção e no aumento da disponibilidade dos ativos, e sua carteira de clientes inclui empresas como Gerdau, Coca-Cola Andina, Grupo Petrópolis e Tegma.
A plataforma da Rabbot era originalmente executada como uma aplicação monolítica sobre infraestrutura .NET e Windows. As implantações eram feitas de forma manual, sem pipeline de CI/CD, o que tornava as entregas lentas, infrequentes e dependentes da intervenção manual da equipe técnica. O dimensionamento de recursos seguia um modelo puramente reativo: a infraestrutura só era ajustada depois que os picos de demanda já afetavam a aplicação, em vez de escalar de forma proativa a partir de sinais reais de carga.
O problema central era a rigidez da arquitetura monolítica em .NET e Windows, que impedia o escalonamento independente dos componentes da aplicação e obrigava a equipe a implantar a aplicação inteira como uma única unidade para qualquer alteração, por menor que fosse. Combinada ao modelo de escalonamento reativo, essa rigidez fazia a plataforma oscilar entre o superprovisionamento, que elevava os custos, e o subprovisionamento durante os picos reais de demanda, que arriscava a degradação de desempenho, sem nenhum mecanismo automatizado e orientado à carga para equilibrar os dois cenários.
O quadro anterior somava, portanto, custos de infraestrutura elevados em relação à utilização real, uma vez que o ambiente monolítico em Windows exigia recursos permanentemente ativos e superdimensionados para acomodar os cenários de pico, e baixa visibilidade operacional sobre a saúde e o desempenho efetivos da plataforma, o que dificultava a identificação e o diagnóstico proativos de problemas.
A Nuvme conduziu a transformação de infraestrutura e de DevOps de ponta a ponta. A plataforma foi rearquitetada de um monólito .NET sobre Windows para uma arquitetura de microsserviços em .NET Core sobre Linux, executada no Amazon Elastic Kubernetes Service (Amazon EKS). A migração preservou a lógica da aplicação .NET e afastou as restrições do monólito em Windows, com a transição para .NET Core sobre Linux compatível com uma arquitetura conteinerizada baseada em Kubernetes.
Para substituir o modelo de escalonamento reativo por uma elasticidade proativa e orientada à carga, a Nuvme implementou o Karpenter no provisionamento dinâmico de nós sob demanda, combinado a instâncias Amazon EC2 Spot para computação de menor custo. Adotou ainda o KEDA (Kubernetes Event-Driven Autoscaling) para escalar as cargas de trabalho de forma automática, a partir de métricas reais orientadas a eventos, em vez de limiares estáticos, e introduziu o RabbitMQ como camada de mensageria para a comunicação assíncrona e desacoplada entre os microsserviços recém-separados.
O processo de entrega foi reconstruído. A Nuvme implementou um pipeline completo de CI/CD integrado a práticas de GitOps, o que habilitou implantações automatizadas, repetíveis e auditáveis em substituição ao processo manual anterior. Com a arquitetura de microsserviços, cada serviço passou a ser implantado de forma independente e frequente, o que reduziu o risco de cada implantação em relação ao modelo monolítico, no qual qualquer mudança exigia a implantação da aplicação inteira. Por fim, a Nuvme estabeleceu observabilidade sobre toda a plataforma, o que deu à equipe visibilidade em tempo real sobre a saúde da aplicação e da infraestrutura, antes indisponível.
A documentação do processo de GitOps, com a descrição de como as configurações são versionadas, como as implantações são executadas e como reverter mudanças quando necessário, foi entregue ao cliente por meio de um arquivo README no próprio repositório utilizado na operação diária.
Serviços AWS utilizados:
Ferramentas complementares aos serviços AWS:
A solução é estruturada sobre um cluster Amazon EKS, no qual a plataforma da Rabbot, rearquitetada em microsserviços .NET Core sobre Linux, é executada de forma conteinerizada. O provisionamento dos nós é dinâmico, conduzido pelo Karpenter, e apoia-se em instâncias Amazon EC2 Spot para reduzir o custo da computação. O escalonamento das cargas de trabalho é orientado a eventos por meio do KEDA, que ajusta a capacidade dos serviços a partir do volume real de mensagens processado, o que inclui a redução a zero durante os períodos ociosos, para eliminar o consumo desnecessário de recursos. A comunicação entre os microsserviços é assíncrona e desacoplada, com o RabbitMQ como camada de mensageria. A distribuição do tráfego de entrada é feita por Application Load Balancer, e a rede do cluster inclui NAT Gateway e Egress-Only Internet Gateway para o tráfego de saída, com os segredos da infraestrutura geridos pelo AWS Secrets Manager.
A infraestrutura é definida como código por meio do Terraform, que cobre o ambiente completo do Amazon EKS, a rede e a infraestrutura de apoio. O provisionamento adota os mesmos módulos padronizados de Terraform utilizados na base de clientes da Nuvme, que codificam boas práticas para rede, configuração do cluster e provisionamento de nós, o que mantém o ambiente versionado e reproduzível; qualquer alteração de infraestrutura percorre o mesmo fluxo baseado em Terraform, em vez de configuração manual por console.
O ciclo de implantação combina integração contínua e GitOps. O pipeline do GitHub Actions percorre os estágios de develop, staging e main, com a construção e a publicação da imagem do container. As implantações da aplicação são geridas por GitOps com o FluxCD, o que, somado à infraestrutura versionada em Terraform, confere à Rabbot um processo de implantação auditável e repetível nas camadas de infraestrutura e de aplicação.
Quanto à gestão de configuração e à aplicação de patches, a solução não emprega uma ferramenta tradicional de configuração no sentido clássico, uma vez que a aplicação é executada em containers no Amazon EKS. A configuração da aplicação é gerida por GitOps, com o FluxCD e os manifestos do Kubernetes, e a configuração da infraestrutura, por Terraform. Os nós do Amazon EKS, em grupos gerenciados, recebem os patches de sistema operacional de forma automatizada pela AWS: uma vez iniciada a atualização do grupo de nós pela equipe técnica, a aplicação do patch na imagem subjacente e a substituição dos nós ocorrem de forma automática.
A transformação conduzida pela Nuvme atuou sobre a rigidez arquitetural e o modelo de escalonamento reativo que limitavam a operação da Rabbot, com resultados observados na cadência de implantação, na elasticidade da infraestrutura e na resiliência da plataforma.
Na implantação, o cenário anterior, no qual o monólito exigia implantar a aplicação inteira como unidade única a cada mudança, deu lugar a um modelo em que cada microsserviço é implantado de forma independente e frequente, com uma cadência de entrega mais rápida e de menor risco por meio do pipeline de CI/CD e GitOps. O lead time de implantação foi reduzido em uma estimativa de 70% a 90% frente ao baseline anterior, resultado direto da passagem das implantações manuais e monolíticas para implantações automatizadas e independentes de cada serviço.
Na elasticidade, o escalonamento reativo foi substituído por um mecanismo proativo e orientado à carga, com o Karpenter no provisionamento dinâmico de nós, as instâncias Amazon EC2 Spot na redução de custo e o KEDA no escalonamento por eventos a partir do volume real de mensagens. A redução da capacidade a zero nos períodos ociosos elimina o consumo desnecessário de recursos, o que responde diretamente ao superprovisionamento permanente do ambiente monolítico anterior.
Na resiliência, a arquitetura de microsserviços isola as falhas em serviços individuais, em vez de comprometer o monólito inteiro, e reduz o raio de impacto de cada implantação frente ao modelo anterior de tudo ou nada. O tempo médio de recuperação (MTTR) foi reduzido em uma estimativa de 40% a 60% frente ao baseline anterior. Somou-se a esses ganhos o estabelecimento de observabilidade sobre toda a plataforma, com visibilidade em tempo real sobre a saúde da aplicação e da infraestrutura, o que supre a baixa visibilidade operacional identificada no cenário inicial.
No projeto da Rabbot, a Nuvme conduziu integralmente a “rearquitetura” da plataforma, de um monólito .NET sobre Windows para uma arquitetura de microsserviços em .NET Core sobre Linux, executada no Amazon Elastic Kubernetes Service. A solução substituiu o modelo de escalonamento reativo por uma elasticidade orientada a eventos, com o Karpenter, as instâncias Amazon EC2 Spot e o KEDA, e o processo de entrega manual por um pipeline de CI/CD integrado a práticas de GitOps. Os efeitos foram observados na redução estimada do lead time de implantação e do tempo médio de recuperação, na eliminação do consumo desnecessário de recursos pela redução de capacidade a zero nos períodos ociosos e no estabelecimento de observabilidade sobre toda a plataforma, antes indisponível. Para a Nuvme, projetos como este demonstram sua capacidade de conduzir a modernização de aplicações legadas para arquiteturas de microsserviços com escalonamento orientado a eventos na AWS.
