NEI é o líder em e-commerce e marketplace B2B no Brasil. Através da nossa plataforma proprietária de venda digital no B2B oferecemos todos os suprimentos necessários para a operação de um negócio, como ferramentas, elétrica, produtos de limpeza, rolamentos, etc. Com mais de 250.000 produtos no catálogo, a NEI monetiza ambos os lados do marketplace e traz consigo atrativos modelos de negócio para venda, compra e anúncios de produtos e marcas. Atualmente, NEI.com.br tem 650.000 pageviews mensais, 60.000 fornecedores registrados e 250.000 compradores.
O Desafio:
Micro serviços são uma tendência mundial no design de soluções resilientes e de negócios de missão crítica.
A base da arquitetura de micros serviços é o desenvolvimento de um único aplicativo como conjunto de pequenos e independentes serviços executados em seu próprio processo, desenvolvidos e implantados de forma independente, diferentemente do padrão utilizado no passado, conhecido como monolítico.
Monolítico x Micro Serviço
Depois de passar por uma fusão, a NEI necessitou reescrever e criar micro serviços para atender suas necessidades. Aliado a necessidade de migração de plataforma, já que o antigo provedor (Heroku) não oferecia todas as capabilities oferecidas pela Amazon Web Services.
Além dos pontos mencionados, a NEI também inseriu uma camada de mensageria no ambiente, e para isso, foi preciso um serviço gerenciado para este item. Assim, toda comunicação entre os micros serviços são feitos através de mensageria.
Neste cenário, a arquitetura ideal, seria utilizar um cluster Kubernetes, gerenciado, junto com uma plataforma Apache Kafka (Mensageria) em nuvem, tornando a infraestrutura elástica, sendo totalmente aderente com os componentes existentes e de fácil migração.
Por que Amazon Web Services?
A NEI precisava subir o novo repositório, migrar as imagens existentes e adotar o padrão de mensageria entre seus micro serviços. Os seguintes requisitos são desejáveis:Utilizar um cluster de kubernetes gerenciado, para evitar overhead de administração;Utilizar o Apache Kafka, como serviço de mensageria;Utilizar serviços gerenciados de banco de dados (RDS);Mínima manutenção de infraestrutura;Capacidade de resposta às alterações na fonte de dados;Acesso seguro através de VPN para seus colaboradores;Diminuição de custos;
Essas considerações levaram a implantação da infraestrutura na AWS. Abaixo algumas decisões técnicas e estratégicas adotadas para viabilizar o projeto:Amazon S3 para o armazenamento de dados;Amazon Container Registry, para armazenamento das imagens dos micros serviçosAPI Gateway, para receber as requisições das api’s e redirecionamento de tráfego;Banco de dados relacional PostgreSQL gerenciado (RDS);
Com este conjunto de soluções a arquitetura dos novos serviços da Nei ficou como a seguir:
Resultado
Depois de 3 meses de trabalho, a NEI migrou sua antiga plataforma para a AWS, todos desenvolvedores estavam familiarizados com o novo processo de CI/CD, e com o desenvolvimento de micro serviços na nova arquitetura. Neste projeto configuramos serviços de autorização de usuários, baixa de produtos, carregamento de produtos, entre outros.
Os resultados impressionam nos seguintes recursos:Facilidade de subida de um novo micro serviço;Segurança, todos os componentes chave ficaram em redes privadas;Facilidade de gerenciamento de cluster, com a ferramenta eksctl, onde as alterações no nodegroup podem ser feitas sem downtime;Facilidade para fazer upgrade de cluster, via console ou através de eksctl;Kafka gerenciado, reduzindo praticamente a 0 a necessidade de intervenção técnica no ambiente;
Com os resultados obtidos, todos os novos micros serviços da NEI estão sendo utilizados na plataforma EKS. Todos seus produtos, clientes e pedidos estão transacionando na mesma plataforma. Durante o projeto, precisamos fazer um redesign da solução, pois, cada micro serviço possuía um pipeline para o CI/CD, notamos que poderíamos refatorar a solução para se tornar mais enxuta (cada micro serviço possuía um pipeline distinto). Para tanto, precisamos acertar os detalhes abaixo:Padronizar na nomenclatura de projetos no repositório de código;Criar secrets e configmaps no cluster EKS para armazenar dados sensíveis e configuração de ambiente;Padronizar tópicos do Kafka, para utilização de múltiplos ambientes (dev/qa/prd);Atualizar a versão do cluster para 1.16, pois algumas features de configmap só estariam disponíveis nesta versão.
