Itaú Unibanco – Escalando o uso de APIs com a AWS

Por Fabrício Henrique de Oliveira, Engenheiro de Integração e Líder do tema APIs no Itaú,
Danniel Sebastião Dias, Engenheiro de Integração Tech Lead no time de APIs no Itaú e
Guilherme Greco, Arquiteto de Soluções na AWS

O Itaú Unibanco S/A é o maior banco privado do Brasil, a maior instituição financeira da América Latina e uma das maiores do mundo. Segundo o ranking de 2021 da consultoria Interbrand, a marca Itaú é apontada como a mais valiosa do país, e eleita algumas vezes pelo Great Place to Work Institute (GPTW) uma das melhores empresas para se trabalhar no Brasil. Presente em mais de 20 países, o banco possui cerca de 5 mil agências e variados canais digitais para oferecer soluções financeiras que melhor atendam às necessidades dos clientes.

O blog post apresenta como o Itaú utiliza recursos da AWS para escalar o uso de APIs e habilitar serviços digitais de forma resiliente, escalável e segura.

Já faz algum tempo que o tema API deixou de ser apenas uma forma de comunicação entre aplicações para troca de dados. Com a digitalização dos negócios, o tema passou a ser uma das formas de ofertar soluções que atendam necessidades de pessoas e empresas em diferentes jornadas, por meio de produtos/serviços digitais. Nesse contexto, empresas de diversos tamanhos e seguimentos passam a definir estratégias para se conectar em ecossistemas digitais, expandir seu portifólio de soluções e agregar mais valor a seus clientes.

Definir e estruturar uma boa estratégia de APIs passou a ser fundamental para a efetividade dos negócios. No 4º trimestre de 2021, o Itaú teve 8,8 milhões de novos clientes e 63% das contratações de produtos efetivados por meio de canais digitais. Esses números vêm crescendo ao longo do tempo e as APIs tem papel fundamental nessa evolução, o que potencializa a necessidade de um processo maduro de construção, exposição e consumo de APIs.

Escalar o uso de APIs ao longo do tempo é um grande desafio para uma empresa como o Itaú, que trabalha com diversos produtos, serviços financeiros, diferentes linhas de negócio e possui milhões de clientes

Agilidade, reuso, flexibilidade, resiliência, escalabilidade e segurança são características fundamentais para alcançar bons resultados. Disponibilizar soluções que unam essas características não é uma tarefa trivial, principalmente se tratando da criticidade desse tipo negócio (gerenciar o dinheiro das pessoas).

O Itaú possui atualmente mais de 15 mil APIs de diferentes tipos, que foram disponibilizadas ao longo do tempo:

APIs privadas: Criadas para troca de dados entre aplicações internas, por exemplo, uma API de saldo que é consumida por diferentes canais digitais internos e por outras aplicações internas que necessitem da informação para compor outros serviços de negócio.

APIs restritas: Criadas para atender parceiros e clientes que consomem serviços do Itaú para agregar valor às suas jornadas. Por exemplo, a geração de boletos e QRCode para pagamentos, cartão white label, etc.

APIs regulatórias: Criadas para atender iniciativas originadas por órgãos reguladores. O design dessas APIs geralmente é pré-definido pelo órgão regulador, sem flexibilidade de customização. Por exemplo, as APIs do PIX e Open Finance que são expostas para consumidores que fazem parte desses ecossistemas.

APIs públicas: Criadas para fomentar a geração de ideias que tenham potencial de solucionar problemas e necessidades da sociedade. O objetivo é utilizar o modelo de inovação aberta, utilizando a criatividade da comunidade de desenvolvedores e empreendedores, dentre outros, para experimentar novas soluções. Recentemente o Itaú participou de um evento global chamado Global Open Finance, que foca em possibilitar a exposição de algumas APIs abertas em um ambiente sandbox, incentivando a criação de novas soluções.

Para atender as necessidades dos clientes, novos serviços são criados diariamente. Por isso, é preciso evitar que as áreas criem APIs de formas diferentes. Nesse contexto, é fundamental que haja uma estrutura que possibilite potencializar o reuso dos serviços, evitar que os consumidores sejam impactados no lançamento de novas versões e mitigar vulnerabilidades para aumentar a segurança. Para que isso seja possível, o Itaú criou um processo de governança que abrange todo o fluxo de criação, publicação e consumo de APIs. Porém, à medida que a quantidade de APIs aumenta, a complexidade para gerenciar os serviços também aumenta. Dessa forma, um modelo de governança centralizado passa a se tornar inviável ao longo do tempo, devido à falta de agilidade e flexibilidade para expor os serviços. Além do modelo de governança, a jornada de exposição também era centralizada, ou seja, para uma comunicação norte-sul (onde a origem da requisição é uma entidade externa a aplicação), todas as APIs eram expostas em uma plataforma de API Gateway centralizada e todas as requisições passavam por ela. Com o aumento na quantidade de serviços expostos, alguns problemas começaram a surgir como, ponto único de falha, alto esforço com gerenciamento dos recursos, falta de flexibilidade para realizar customizações e evoluções de acordo com a necessidade de cada negócio e conhecimento restrito em um único time, dentre outros fatores que dificultavam escalar o modelo.

Solução                                                                                                                     

Para conseguir escalar o uso de APIs de forma sustentada, foi criado o modelo de governança federada. O principal objetivo é dar autonomia e agilidade às áreas do banco por meio de um modelo de trabalho com papéis e responsabilidades compartilhados. Para viabilizar esse modelo, foi criado um novo papel chamado “API Owner”, no qual cada linha de negócio possui pontos focais responsáveis por algumas funções ao longo do ciclo de vida das APIs. Essas funções estão presentes em cada etapa da jornada, desde o design até o gerenciamento e suporte em ambiente produtivo. Dessa forma é possível manter a governança de todas as APIs, definindo e garantindo a aplicabilidade de padrões e boas práticas, porém, de uma forma descentralizada. Esse modelo de trabalho contribui para que os times tenham mais autonomia e agilidade, possibilitando o crescimento exponencial dos serviços expostos em forma de APIs, tanto para canais digitais internos, quanto para clientes e parceiros. Além disso, o modelo impulsiona a disseminação de conhecimento em toda a companhia, além de fomentar a geração de insights para disponibilização de features que contribuam para a melhoria contínua dos tech produtos que fazem parte da jornada de APIs por meio de inner source.

Para operacionalizar o modelo, toda API com potencial de reuso passa por um processo de design. Durante essa etapa, as APIs são modeladas utilizando DDD (Domain Driven Design) e criadas a partir do contrato “Contract First”, antes do desenvolvimento das funcionalidades e regras de negócio. Com o contrato definido, tanto o provedor quanto os consumidores do serviço podem iniciar o desenvolvimento da API de forma paralela, o que traz mais agilidade ao processo. Após definição, o contrato passa por um pipeline com validações automáticas que garantem a aplicação dos padrões de governança e a aprovação final é realizada pelos próprios API Owners. Em seguida, o contrato é versionado e publicado no Amazon API Gateway (para comunicação norte-sul) ou nos clusters de Service Mesh (para comunicação leste-oeste, onde o tráfego é interno no ambiente). As APIs são criadas utilizando REST ou gRPC, dependendo do contexto e finalidade. Nesse mesmo fluxo é realizada a exposição da documentação da API no portal do desenvolvedor, sendo que para APIs externas a documentação fica disponível para clientes e parceiros. O portal possibilita aos consumidores consultarem os serviços disponíveis, entender sua finalidade e experimentá-los em ambiente de teste. Esse modelo também é utilizado durante o processo de discovery para testar hipóteses e validar ideias antes do desenvolvimento das APIs (delivery). Por fim, as APIs são catalogadas em uma base central para disponibilizar informações exigidas por órgãos reguladores, extrair indicadores para auxiliar na tomada de decisão e ter uma visão geral de todos os serviços da companhia. Todo esse fluxo, é realizado de forma automática via auto serviço para que os desenvolvedores possam criar e publicar suas APIs com autonomia e agilidade.

Além do processo de publicação, foi necessário evoluir também a forma de expor as APIs aos consumidores, partindo de um modelo centralizado para um modelo distribuído. O modelo distribuído visa realizar a exposição dos serviços em diferentes Amazon API gateways ou clusters de Service Mesh em diferentes contas AWS. Os desenvolvedores passaram a customizar a forma com que os recursos eram provisionados e expostos na AWS, permitindo fazer o isolamento dos serviços para reduzir pontos únicos de falha, proporcionar mais resiliência e consequentemente reduzir impactos generalizado nos negócios. Além disso, houve melhora no SLA (service level agreement) dos serviços, trazendo mais facilidade para escalá-los com baixo esforço e alto percentual de disponibilidade. O modelo também proporcionou mais agilidade e flexibilidade para customizações na exposição dos serviços de acordo com as necessidades de cada negócio. Atividades que eram realizadas por um time centralizado, hoje é possível ser executadas pelos próprios APIs Owners, por exemplo, configuração e gerenciamento das formas de deploy (canary, blue green, etc.), configuração de tempo de resposta das APIs, quantidade de requisições (throttling), políticas de segurança especificas de cada área e definição de estratégias de monetização para cada serviço exposto.

Elevar ao máximo o nível de segurança é um dos principais direcionadores do Itaú. O modelo distribuído traz vários benefícios, porém, traz maior complexidade de gerenciamento, principalmente nos requisitos que envolvem segurança. Para que não haja impactos na fluidez do processo devido à “gates” de validação que garantam a aplicação das políticas internas, foram implementados “guardrails” nos recursos em todas as contas da organização, seguindo as boas práticas de arquitetura e segurança. Dessa forma, garantimos que as políticas internas sejam aplicadas, podendo remediar recursos que expõe algum serviço de forma indevida. Através de “guardrails”,  é possível garantir que todas APIs sigam regras mandatórias como, por exemplo, o uso de OAuth2 e/ou mTLS (mutual Transport Layer Security) para exposição de APIs externas. Para consumir qualquer API exposta, é necessário passar pelo fluxo de autenticação e autorização. Todos os consumidores precisam de credenciais para se autenticar e dos devidos acessos para serem autorizados a consumir qualquer funcionalidade de uma API.

Para elevar o nível de disponibilidade dos serviços, todo recurso disponibilizado na AWS necessita de mecanismos que garantam a observabilidade do ambiente. O modelo distribuído permite a criação de métricas, logs, traces e alarmes customizados baseados nos critérios definidos para cada API, proporcionando maior flexibilidade na entrega de novas features com resiliência. Seguindo esse cenário, é possível garantir que todos os recursos sigam boas práticas de observabilidade, sem exposição de informações sensíveis, possibilitando a atuação rápida pelos próprios donos das APIs na análise de problemas em momentos de crise.

A solução abaixo mostra como é o fluxo de criação e publicação de APIs na AWS para exposição dos serviços em diferentes Amazon API gateways e clusters de service mesh, distribuídos em contas AWS dedicadas para um produto ou aplicação. É através dessa arquitetura que o cenário de auto serviço é entregue aos desenvolvedores. O desenho mostra um exemplo do fluxo transacional, apresentando um cenário híbrido onde uma aplicação que está no ambiente on-premise consome uma APIs publicada na AWS. Essa API por sua vez, pode consumir outros serviços que estão no ambiente on-premisses, em outras contas AWS ou fora do ambiente Itaú (ex: serviços de parceiros).  Para controle de tráfego, contas específicas com respectivas VPCs são utilizadas, através responsabilidades distintas: 1/ Transit Account (comunicação entre on-premise e AWS) 2/ “Shared account” (comunicação interna e on-premise), 3/ “Outbound Account” (comunicação externa com parceiros ou Internet)

Jornada

Passos Api Public Flow:

1 – O desenvolvedor clona o repositório no GitLab que contém um template Terraform para provisionamento do Amazon API Gateway e demais recursos necessários para seu funcionamento. Faz as configurações necessárias de acordo com a estratégia de exposição da API e realiza o commit das alterações. O AWS CodePipeline e AWS CodeBuild são iniciados para realizar a publicação dos workloads na conta de desenvolvimento. Para provisionamento dos workloas em homologação e produção é necessária a promoção da versão para a branch “master”.

2 – Com o Amazon API Gateway provisionado, o próximo passo é realizar a criação do contrato da API (especificações OpenAPI)  , documentações e configurações necessárias para publicação no API Gateway e Developer portal.  Essas configurações são realizadas em um repositório de contrato no GitLab. Após o commit e aprovação do merge request na branch “development”, o pipeline (GitlabCI) é iniciado para realizar as validações de padrões e boas práticas de governança, build, versionamento do contrato da API e envio da documentação para o Developer portal. Após essas etapas, é gerado um novo pacote com a versão da API e é iniciado o pipeline através do AWS CodePipeline e AWS CodeBuild para deploy do contrato no Amazon API Gateway provisionado no passo 1.

3 – Através da execução do AWS Codebuild é realizado o deploy cross-account na conta de desenvolvimento.

4 e 5 – Após merge request para a branch “master” é iniciado o pipeline através do AWS CodePipeline e realizado o deploy cross-account pelo AWS Codebuild, nas contas de homologação e produção

Passos API Transaction Flow

1 – Um consumidor que está no on-premisses, acessa através do AWS Direct Connect, uma API privada exposta no Amazon API Gateway, através de VPC Endpoint.

2 – O VPC Endpoint privado do Amazon API Gateway é responsável por receber as requisições.  Através de headers (host ou ID), encaminha o tráfego para instâncias de Amazon API Gateway distribuídas em contas da mesma região

3 – O tráfego chega no Amazon API Gateway da conta produto, onde o backend e dados estão publicados

4 e 5 – Caso a requisição necessite alcançar algum outro serviço que está disponível na AWS, a requisição é encaminhada para uma conta compartilhada, que possui uma VPC com outros VPC Endpoints. Estes, também são responsáveis por fazer o roteamento para Amazon API Gateway distribuídos

6 – Caso seja uma requisição de saída para a Internet, ele é direcionado para uma VPC com firewalls responsáveis pela inspeção do tráfego e direcionamento para o serviço de destino.

Entenda mais sobre a jornada do Itaú na AWS através da sessão realizada no Re:Invent 2021

Sobre os autores

Fabrício Henrique de Oliveira é engenheiro de integração e líder do tema APIs no Itaú, possui mais de 13 anos de experiência na área de tecnologia. Ao longo de sua carreira o Fabrício tem atuado com automação de processos, tecnologias de integração e mais recentemente em tech products relacionados à soluções de APIs visando acelerar e escalar o uso de serviços digitais.

Danniel Sebastião Dias é engenheiro de integração e atua como Tech Lead no time de APIs no Itaú. Na sua carreira atua com foco em DevOps na área de Integração. Atualmente trabalha com a construção de modelos de governança e disponibilização de soluções corporativas para permitir e facilitar o uso de APIs.

Guilherme Greco é Arquiteto de Soluções na AWS. Com 19 anos de experiência em infraestrutura e arquitetura, Guilherme atuou em diversas implementações e migrações de soluções corporativas para nuvem.