Adoção de serverless na Empiricus

Quando uma solução de tecnologia começa a apresentar problemas, surge a vontade, ou a necessidade, de refatorar, reconstruir, remodelar. Mas como refatorar o código existente, aumentando a qualidade do produto e ainda implementar melhorias arquiteturais e assim diminuir o custo?

No caso da equipe de publicações, responsável pela área de assinantes da Empiricus e por uma camada de APIs usada pelos nossos aplicativos, a saída foi o uso das soluções serverless da AWS, como o AWS Lambda, o API Gateway e o DynamoDB.

Hoje, a Empiricus é uma grande usuária das ferramentas disponibilizadas pela AWS. Iniciamos nosso movimento em direção à cloud em 2015, quando houve a migração do site institucional e dos sites destinados a landing pages e sales letters (cartas de venda). Nestes últimos 6 anos, nós buscamos melhorar nossos processos técnicos extraindo o melhor das ferramentas disponíveis, a fim de atender com excelência a crescente demanda dos nossos usuários.

Em 2018, havia um desafio: a nova área de assinantes estava funcionando há quase um ano, mas as alterações não aconteciam na velocidade esperada. Haviam também dificuldades relacionadas ao monitoramento da aplicação, implementação de mudanças, escalabilidade e qualidade. Isso consumia uma boa parte do tempo da equipe, não permitindo que atuássemos com agilidade nas melhorias de negócio solicitadas. Precisávamos de uma saída, e o uso de ferramentas serverless foi uma escolha eficaz.

Começamos com um projeto destinado a centralizar a validação de direitos de acesso aos clientes. A solução usava apenas AWS Lambda e DynamoDB, mas desde a implantação mostrou que era uma decisão acertada.

A nova arquitetura resolveu alguns problemas de desempenho que a solução antiga apresentava, mas também serviu para provar um ponto importante: era possível usar, de um jeito simples, alguns dos serviços gerenciados da AWS e obter um bom desempenho a preço mais baixo do que usando instâncias EC2. Os principais benefícios foram:

• escalabilidade conforme o uso, sem configurações extras;
• ciclo de implementação e publicação de alterações mais rápido;
• desacoplamento da funcionalidade, podendo ser reutilizada.

Um efeito interessante da mudança foi a percepção, para a liderança, de que havia uma maior rapidez na implementação de soluções simples, e que era muito positiva a quebra de um projeto muito grande em aplicações menores e especializadas, todas entregues como APIs consumidas, principalmente, por frontends SPA (Single Page Application).

Mas, voltando um pouco antes no tempo, após a aplicação que centralizava os acessos mostrar o potencial de uso das ferramentas serverless, surgiu um novo desafio: reimplementar uma solução maior usando essas mesmas ferramentas, e em uma das partes críticas da área de assinantes: a área de notificações.

Os serviços usados para isso foram:

• API Gateway e AWS Lambda, com a programação e a configuração dos serviços na AWS implementada usando o framework AWS Chalice, que permite usar Python em todo o processo, de desenvolvimento a implantação (deploy);
• SQS para controle de coordenação de processos assíncronos;
• MongoDB para armazenamento dos dados;
• Uma função extra no AWS Lambda para validação dos dados do usuário

A implementação apresentou vários desafios, tais como: entender como fazer as funções conversarem, como coordenar a execução dos vários processos, e como trabalhar com um framework que, à época, tinha pouca documentação.

Após aproximadamente 2 meses de trabalho, com duas pessoas atuando no projeto, estava pronta a nova versão do sistema de notificações. Os principais pontos de melhora percebidos:

• Diminuição no tempo de processamento e publicação de novas notificações, muitas vezes o processo caindo de quase 1 hora para alguns minutos.
• Redução em aproximadamente 60% do custo de operação. A versão anterior da aplicação custava aproximadamente 60 a 90 dólares por mês (duas instâncias de aplicação mais uma instância para o serviço de filas) passou a custar em média de 2 a 5 dólares (conforme uso).

O processo de desenvolvimento foi um pouco mais desafiador do que o esperado, porque estávamos aprendendo como as coisas funcionavam durante a implementação, principalmente as configurações dos serviços na AWS. Mas isso nos ensinou, também, a entender as peculiaridades e impactos na aplicação, por exemplo:

• O API Gateway tem um timeout que não era configurável; com isso, os serviços web-faced deveriam terminar rapidamente. Isso nos levou a quebrar algumas funções e coordenar o funcionamento com filas.
• O AWS Lambda só consegue acessar recursos dentro da VPC se tiver configurações que iniciem as funções dentro da mesma VPC, e seguindo as regras de Security Groups.

No final a implementação estava estruturada sobre essa arquitetura.

Arquitetura serverless da aplicação de notificações

Depois da implementação desse projeto de maior porte, ficou provado que era possível implementar soluções mais complexas. Aos poucos migramos outras partes da aplicação para este tipo de arquitetura, e também começamos a usar outros serviços como:

• Cloudfront para cache frontend;
• Kinesis Firehose para entrega de eventos para o time de BI;
• AWS Cloudwatch para monitoramento de erros, armazenamento de logs e cálculo de métricas personalizadas;
• Elasticache para armazenamento de dados e caching de dados das aplicações.

Hoje praticamente todos os serviços da equipe são implementados com Lambda, SQS, DynamoDB e API Gateway. Para nossos projetos, essa solução se provou ótima, e mudou até o modo como planejamos a arquitetura e os cronogramas das aplicações, nos estimulando a usar iterações curtas e focadas em poucas funcionalidades.