A Convertr é uma empresa brasileira de tecnologia com especialização em operações de atacado e varejo. A companhia atende marcas e lojistas que operam nos modelos de atacado, varejo e atacarejo, com presença expressiva entre negócios do setor de moda e vestuário. Mantém escritórios em São Paulo, em Navegantes e em Joinville, os dois últimos em Santa Catarina.
Seu principal produto é uma plataforma de e-commerce adaptável a diferentes modelos de operação, com recursos como compra por grade, grupos de clientes, desconto progressivo e integração em tempo real com os principais ERPs do mercado. À plataforma somam-se serviços de performance, entre eles gestão de tráfego pago, criativos, consultoria e CRM, além da frente educacional Convertr Educação. A empresa apresenta-se como especialista na união entre plataforma e performance para o e-commerce de atacado e varejo; segundo seus próprios dados, o ecossistema já movimentou mais de R$ 2 bilhões em vendas, e sua carteira reúne marcas como Aeropostale, Brascol, Klin e Hocks.
O modelo de negócio da Convertr é construído sobre a plataforma Magento, com o provisionamento de um ambiente de e-commerce individual para cada cliente. Antes da automação, a criação de um novo ambiente exigia um processo integralmente manual: o provisionamento de uma nova conta AWS dedicada, a configuração de uma instância Amazon Elastic Compute Cloud (Amazon EC2), de um banco de dados Amazon Relational Database Service (Amazon RDS), de registros de DNS no Amazon Route 53 e dos demais componentes de infraestrutura, tudo repetido de forma individual para cada nova loja. Com a entrada de novas lojas a cada semana, esse modelo tornou-se insustentável, e o provisionamento manual passou a ser um gargalo direto à capacidade de crescimento da empresa.
Além do provisionamento, a operação enfrentava um problema crítico de escalabilidade nos períodos de pico de demanda, como a Black Friday. Como o dimensionamento de recursos de Amazon EC2 e de Amazon RDS era feito de forma manual, a equipe técnica precisava permanecer de sobreaviso durante a madrugada nesses períodos, com monitoramento do tráfego em tempo real e escalonamento manual dos recursos para evitar indisponibilidade nos ambientes dos clientes, o que representava alto risco operacional e desgaste da equipe.
A ausência de automação afetava também a frequência de implantação. As atualizações da aplicação e as novas versões eram implantadas com baixíssima frequência, uma vez que cada implantação precisava ser executada manualmente em cada ambiente de cliente, em um processo lento, repetitivo e sujeito a erro humano. O problema central era, portanto, a ausência completa de automação em três frentes do ciclo de vida da infraestrutura: o provisionamento de novos ambientes e contas para cada cliente, o escalonamento de recursos de computação diante de picos de demanda e a execução das implantações de atualização em produção. Essa combinação tornava a operação inteiramente dependente de intervenção manual em cada etapa do ciclo, o que limitava a capacidade de crescimento do negócio e a resiliência operacional.
A Nuvme foi responsável por toda a transformação de DevOps e de infraestrutura, com a única exceção da reescrita da aplicação para a conteinerização, conduzida pela equipe de desenvolvimento do próprio cliente. A atuação da Nuvme abrangeu o desenho e a implementação do Dockerfile da aplicação conteinerizada, a arquitetura e a migração da infraestrutura para o Amazon Elastic Kubernetes Service (Amazon EKS), a construção da estratégia de banco de dados multi-tenant em Amazon Aurora, a implementação do pipeline de implantação em modelo GitOps com o FluxCD e o desenvolvimento da automação de provisionamento de novas lojas com o AWS CloudFormation e o AWS Lambda. Em síntese, a Nuvme respondeu de ponta a ponta pela camada de infraestrutura, automação e implantação.
A solução atacou as três frentes descritas no cenário inicial. Para o provisionamento, a Nuvme padronizou a infraestrutura por meio de módulos reutilizáveis de Terraform, que codificam boas práticas para as camadas de rede, computação e banco de dados e asseguram consistência e repetibilidade independentemente do porte ou da complexidade do cliente. No caso específico da Convertr, essa repetibilidade foi levada adiante: modelos de AWS CloudFormation orquestrados por AWS Lambda automatizam o fluxo completo de provisionamento de cada nova loja, o que eliminou a configuração manual e pontual de infraestrutura.
Para o escalonamento, a migração para o Amazon EKS, com o Karpenter no provisionamento dinâmico de nós, substituiu o dimensionamento manual de recursos e o sobreaviso noturno da equipe por um mecanismo automático de resposta à demanda. Para a implantação, a Nuvme adotou práticas de GitOps com o FluxCD, com as configurações de implantação versionadas em repositórios privados, o que tornou cada implantação auditável, consistente e reproduzível entre ambientes. A separação entre os ambientes de staging e de produção é gerida por uma estratégia baseada em branches: as mudanças integradas a cada branch acionam o FluxCD, que reconcilia o ambiente correspondente com a imagem atualizada.
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.
Ferramentas complementares aos serviços AWS:
A solução é estruturada sobre um cluster Amazon EKS, com a aplicação Magento conteinerizada por meio de Docker e executada em nós de trabalho em Amazon EC2. O provisionamento desses nós é dinâmico, conduzido pelo Karpenter, que ajusta a capacidade de computação conforme a carga e substitui o escalonamento manual do modelo anterior. A distribuição do tráfego de entrada é feita por Application Load Balancer, e a entrega de conteúdo, por Amazon CloudFront, com a resolução de DNS a cargo do Amazon Route 53. A camada de dados adota o Amazon Aurora em estratégia multi-tenant, que atende aos ambientes dos clientes. A rede do cluster inclui NAT Gateway e Egress-Only Internet Gateway para o tráfego de saída, e os segredos da infraestrutura são geridos pelo AWS Secrets Manager.
A infraestrutura é definida como código em dois planos complementares. O Terraform é a ferramenta principal e cobre o Amazon EKS, a rede, o Amazon Aurora e a infraestrutura central, por meio de módulos reutilizáveis que padronizam as camadas de rede, computação e banco de dados. O AWS CloudFormation é empregado especificamente no fluxo de provisionamento automatizado de novas lojas: modelos de CloudFormation orquestrados por AWS Lambda executam a criação completa do ambiente de cada nova loja, o que dispensa a configuração manual e pontual.
O ciclo de implantação combina integração contínua e GitOps. O pipeline do Bitbucket Pipelines constrói a imagem do container da aplicação e a publica no Amazon Elastic Container Registry (Amazon ECR). A separação entre os ambientes de staging e de produção é gerida por uma estratégia baseada em branches: quando uma mudança é integrada a uma branch, o FluxCD reconcilia o ambiente correspondente com a imagem atualizada, de modo que cada ambiente reflita o estado definido por sua branch no repositório de GitOps. As configurações de implantação são versionadas em repositórios privados, o que assegura implantações auditáveis e reproduzíveis.
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 as três frentes que limitavam a operação da Convertr, com resultados observados em provisionamento, escalabilidade e implantação.
No provisionamento, a criação de um novo ambiente deixou de ser um processo manual e individual e passou a ser executada de forma automatizada pelos modelos de AWS CloudFormation orquestrados por AWS Lambda, o que eliminou a configuração pontual de infraestrutura a cada nova loja. Esse ganho responde diretamente ao gargalo de crescimento descrito no cenário inicial, em que a entrada semanal de novas lojas multiplicava o esforço operacional de forma linear.
Na implantação, o cenário anterior de atualizações muito infrequentes, decorrentes da complexidade e do esforço manual de atualizar cada ambiente, deu lugar a uma operação de baixa fricção após a adoção do pipeline em GitOps com o FluxCD, com implantações frequentes e confiáveis em todos os ambientes, sem intervenção manual. O lead time de implantação foi reduzido em uma estimativa de 70% a 90% frente ao processo manual anterior, resultado direto da automação por GitOps que substituiu as etapas manuais de provisionamento e configuração de cada implantação.
Na escalabilidade e na resiliência, a arquitetura padronizada e com escalonamento automático em Amazon EKS, com o Karpenter no provisionamento dinâmico de nós, substituiu o dimensionamento manual e o sobreaviso noturno da equipe nos períodos de pico. O tempo médio de recuperação (MTTR) foi reduzido em uma estimativa de 50% a 70% frente ao baseline anterior. O resultado mais direto foi a ausência de indisponibilidade durante a Black Friday sob a nova arquitetura, em contraste com o risco recorrente de indisponibilidade do modelo anterior de escalonamento manual.
No projeto da Convertr, a Nuvme conduziu a transformação de DevOps e de infraestrutura de ponta a ponta, da conteinerização em Amazon Elastic Kubernetes Service ao pipeline de implantação em GitOps com o FluxCD e à automação de provisionamento de novas lojas com o AWS CloudFormation e o AWS Lambda. A solução substituiu a intervenção manual que limitava as três frentes do ciclo de vida da infraestrutura, o provisionamento de ambientes, o escalonamento de recursos e a implantação de atualizações, por um modelo padronizado, automatizado e reproduzível. Os efeitos foram observados na redução estimada do lead time de implantação e do tempo médio de recuperação, e na ausência de indisponibilidade durante a Black Friday, período que, no modelo anterior, exigia sobreaviso noturno da equipe e concentrava o maior risco operacional. Para a Nuvme, projetos como este demonstram sua capacidade de desenhar e operar arquiteturas de infraestrutura automatizada em ambientes multi-tenant de alta demanda.
