Problema e Visão Geral da Solução

Já na primeira reunião, percebemos que o projeto estava muito relacionado com o conceito de Serverless e foi exatamente este caminho que construímos e apresentamos como solução.

Na época, a Dock tinha o desafio de construir APIs “do zero”, que seriam acessadas por seus clientes (outras empresas), que por sua vez fornecem serviços financeiros às pessoas físicas ou jurídicas – consumidores finais. Sendo assim, conforme o número de empresas contratando a Dock aumenta, a quantidade de consumidores finais atendidos na ponta e consumindo serviços da plataforma de APIs se multiplica rapidamente. Isto impacta diretamente no volume de transações que precisam ser suportadas por este sistema que, até então, não era previsto.

Nas primeiras conversas já fomos ouvindo as palavras chave que gostamos de ouvir: "escalabilidade", "baixo custo", "API Rest","integração com parceiros" e muitas outras. A ideia já foi se formando e, após muitos estudos e horas de trabalho, tínhamos um desenho de solução mais ou menos como esse aqui:

Detalhes

É claro que este desenho é simplificado, mas a ideia era mostrar uma visão macro de como funciona uma arquitetura Serverless. E precisava ser algo que se adequasse aos diversos casos de uso que eles estavam apresentando. Em uma arquitetura Serverless, a computação acontece utilizando serviços que abstraem completamente a gestão de servidores. No caso da Dock, isto envolveu principalmente o AWS Lambda, que nos permite executar código próprio sem conhecer a infraestrutura onde este código será executado, sendo essa infra totalmente gerenciada pela AWS. Nós fornecemos o código, a AWS se encarrega do resto.

O desenho final acabou sendo muito parecido, mas agora com muito mais APIs, funções, tabelas e todas as outras frentes necessárias para disponibilizar o serviço de BaaS da Dock. No meio do caminho, houve diversas situações desafiadoras, como por exemplo:

1. Refatoração de algumas funções que já haviam sido desenvolvidas antes da arquitetura Serverless ser adotada, para evitar problemas como cold start;
2. Migração de região, para se aproximar dos parceiros que estavam cada vez mais integrados;
3. Evolução do modelo de autenticação;
4. Utilização de fluxos assíncronos através de SQS e SNS.

O problema de cold start em especial foi bastante presente. Como os serviços haviam sido desenvolvidos inicialmente pensando em uma infraestrutura tradicional, não houve uma preocupação com o tempo de startup da aplicação. Quando vamos para um serviço de Function-as-a-Service como o AWS Lambda, nós perdemos o controle de quando a nossa aplicação vai ser iniciada ou terminada – isto fica a critério da AWS. Então pode acontecer um startup no momento em que o nosso usuário faz uma chamada e, caso a aplicação demore a ser inicializada, pode apresentar lentidão ou até timeouts para o usuário. Isto era ainda mais crítico para a Dock, por se tratarem de serviços responsáveis por transações financeiras – estes timeouts poderiam gerar inconsistências nas transações, o que é super crítico. Para evitar isto, alguns serviços foram refatorados usando linguagens que favorecem um startup rápido e também evitando frameworks pesados. Ajudou muito também quando a AWS lançou melhorias na arquitetura do AWS Lambda, que otimizaram o tempo de cold start quando a função roda dentro de uma VPC.

Aos poucos, todas as dificuldades foram resolvidas e conseguimos evoluir para entregar diversos benefícios para a Dock através desta solução. Atualmente, a escalabilidade do sistema é incrível, suportando o crescimento deles de zero transações por mês para mais de 230 milhões de transações mensais em pouco mais de 18 meses. Além disso, o modelo de custos faz todo sentido para o modelo de negócios da Dock, o que permite que eles escalem a operação sem se preocupar com uma mudança no padrão de custos necessária para suportá-la.

A gestão do ambiente também ficou extremamente simples, permitindo que eles foquem na evolução dos negócios e não na gestão de infraestrutura. Com mais de 400 funções em produção, usando Java, Node.js e Python, bem como outros serviços como Amazon API Gateway, Amazon DynamoDB, Amazon Simple Queue Service e Amazon Simple Notification Service, Amazon Certificate Manager, AWS Secrets Manager, Amazon S3 e Amazon SageMaker, entre outros, a Dock e a Enkel conseguiram construir um sistema que se apoia de forma bastante estrutural nas arquiteturas serverless AWS. E é muito satisfatório ver um gráfico como esses:



Perceber que mesmo passando de 1 milhão de chamados em uma hora, o tempo de resposta não sobe. Aliás, neste caso até desceu, batendo uma média de 350ms por execução. Para nós, é impossível ver um resultado como este e não nos orgulharmos do que criamos até agora.