Kodiak: a nova tecnologia por trás do aplicativo do BB

Augusto César Gonçalves de Azevedo, pai da Catarina, com quase 15 anos na Tecnologia do BB, atuou com Segurança especificando e construindo soluções, atua com Canais Digitais desde o início de sua carreira, plataformas tecnológicas para os times de desenvolvimento de canais, nos últimos anos liderou a integração com GiftCards, o time de Componentes mobile e o time do Kodiak onde atuou como PO, hoje está a frente do time de Plataforma Mobile do BB.

Uma boa nota nas lojas de aplicativos é reflexo da qualidade do aplicativo e do valor percebido pelos clientes. Isso envolve muitos fatores, além de funcionalidades relevantes para o cliente e de uma boa experiência é importante manter tudo sempre funcionando. Já adianto que não é uma missão fácil.

Com a grande quantidade de coisas novas e ajustes que colocamos todas as semanas no app, algum bug pode acabar passando. São muitos times e desenvolvedores fazendo ajustes. No último levantamento eram mais de 400.

Além disso é importante dizer que o processo de atualização do aplicativo não é algo trivial. O primeiro desafio é juntar todas essas alterações numa versão do app. Depois garantir que todas essas mudanças estejam funcionando direitinho. Que nada do que foi alterado quebre algo que já está funcionando. Aí temos que passar pelo crivo das lojas (App Store e Play Store). E por fim precisamos que o cliente atualize o app em seu dispositivo para que as alterações tenham efeito – existe uma parcela significativa dos clientes que atualiza com pouquíssima frequência.

Buscando sempre oferecer o melhor aplicativo do mercado para os nossos clientes, em 2019, começamos a buscar novas soluções para lidar melhor com esse cenário.

Mas o que é esse tal de Kodiak?

Kodiak é uma solução no-code/ low–code totalmente desenvolvida internamente no BB. Dar velocidade para as entregas do mobile, garantindo segurança e qualidade, era o principal problema que ela buscava resolver.

Para resolver esse problema foi concebida uma arquitetura baseada em templates de tela que pudessem ser parametrizados de forma dinâmica, para organizar o fluxo de navegação e realizar o consumo de APIs.

De quebra, o fato de utilizarmos templates de tela, diminui o esforço de desenvolvimento bem como de padronização das interfaces, aplicação de componentes visuais e acessibilidade.

Mas e na prática, como isso tudo funciona?

Vamos explorar um pouco do Kodiak. E para isso, entender como funciona a mecânica dos templates já é meio caminho andado para entender como funciona essa plataforma.

Entendendo os Templates

Para facilitar a explicação vamos falar um pouco do processo de criação de um template até o seu uso dentro de aplicativo. A imagem a seguir ilustra algumas fases desse processo.

1 – Identificando o caso prático de aplicação

O primeiro passo para termos um template é identificar um cenário prático de uso. Esse passo é o mais importante. Não criamos templates baseados em necessidades hipotéticas. Uma vez que temos o caso em mãos, avaliamos os templates e existentes e exploramos outras abordagens para resolver o mesmo cenário. Identificado que a melhor abordagem é criar um template, buscamos outros casos possíveis de aplicação para deixá-lo o mais flexível possível e partimos para a especificação.

2 – Especificação do template

A especificação ainda é uma etapa de design e por isso conduzida pelo nosso time de UX. Nessa etapa são identificados os componentes da nossa biblioteca de componentes visuais – esse é outro ponto importante, só componentes da nossa biblioteca podem ser utilizados nos templates e telas do app. Também são definidos todos os tamanhos de fonte, espaçamento, cores e aplicação dos componentes na tela conforme o nosso Design Language System e o mais importante, as diretrizes de acessibilidade.

3 – Template disponível

Uma vez especificado o template é construído e disponibilizados na nossa Plataforma para ser utilizado na construção dos fluxos de tela. Recentemente passamos a disponibilizar também um componente do Figma que representa o template, facilitando assim o processo de design de novos serviços que utilizem o Kodiak. Aí é só identificar os templates que melhor se encaixam com a necessidade do produto sendo construído.

4 – Configuração para uso

Na hora de utilizar o template existem um “pulo do gato”. Não é necessário utilizar todos os componentes previstos no template, apenas os que fazem sentido para a tela em questão. Isso traz muita flexibilidade e diversas possibilidades de aplicação de um mesmo template. A imagem acima ilustra exatamente esse cenário em que apenas uma parte dos componentes previstos está sendo utilizada para instanciar a tela.

Chega de conversa fiada, quero saber das tecnologias

Vamos dar uma espiada embaixo do capô. Para facilitar, vamos usar esse diagrama abaixo, uma versão simplificada da arquitetura do sistema.

Falamos um pouco sobre a lógica de funcionamento dos templates, agora vamos ver um pouco da tecnologia que faz isso funcionar.

SDK do Kodiak

Nosso app é construído em React Native e naturalmente nossos templates também, principalmente pela facilidade de integração e domínio que temos da tecnologia. Esses templates, juntamente com o módulo que controla a instanciação das telas e a comunicação com o Engine (nosso backend), são empacotados em uma biblioteca que chamamos de SKD do Kodiak – usando de licença poética uma vez que o Kodiak não produz código, mas vamos chegar lá. Essa SKD é embarcada nos apps com os quais estamos integrados.

Engine, o nosso orquestrador

A cada navegação de tela no aplicativo o SDK se comunica com o Engine para descobrir qual a próxima tela a ser exibida. O Engine – que construído em JavaScript e roda em NodeJS – por sua vez recupera a configuração da tela, identifica as APIs a serem consumidas, realiza o consumo das APIs e retorna para o App um JSON contendo a identificação do template a ser instanciado e os dados que serão mostrados para o cliente. O Engine é o nosso orquestrador de telas e APIs.

Essa modelo de execução tem alguns ganhos interessantes:

– nossas APIs não precisam mais ficar diretamente expostas na internet;

– o fato de o App não interagir diretamente com as APIs dificulta a engenharia reversa;

– são retornados apenas os dados que serão utilizados na tela reduzindo o tráfego de desnecessário de dados;

– é possível monitorar de forma mais fácil e clara o que está acontecendo na jornada do cliente;

– o app fica mais leve;

– o mais importante de todos, a alteração nos fluxos não depende de carga do app e ocorre de forma instantânea.

Monitor, foco na disponibilidade e performance

Um dos pontos de ganho citados foi a monitoração. Esse é um tópico que vale a pena explorar um pouco mais.

“Todos Serviços” (a forma como chamamos os fluxos de tela que representam uma funcionalidade no app) implantado no Kodiak nasce monitorado por padrão. Como toda navegação de tela acaba gerando uma chamada para o nosso backend conseguimos observar essas interações.

Optamos por utilizar a stack Prometheus e Grafana para fornecer aos nossos desenvolvedores um painel em que ele consegue acompanhar seus fluxos de tela. Nesse painel são mostradas informações como:

– quantidade de exibições de tela;

– tempo de carregamento das telas (média e percentil 99, que é importante para evidenciar possíveis problemas que afetam apenas parte dos usuários);

– taxa de sucesso nos carregamentos das telas (hoje afetado principalmente por erros na interação com as APIs);

– quantidade de erros;

Todos esses dados são coletados por tela e por API consumida, o que possibilita um acompanhamento muito rico do ambiente como um todo.

Ok, entendi como funciona o runtime. Mas e o desenvolvimento?

Todo usuário que está chegando no Kodiak pela primeira vez vai passar pelo nosso Hotsite que contém algumas informações básicas e direciona para o nosso “Get Started”.

O Get Started é um tutorial com o passo a passo em que o objetivo é configurar o ambiente de desenvolvimento e sair com um pequeno fluxo de telas executando no App (nosso Hello World).

Launcher, gerente do ambiente de desenvolvimento

Mas não pense que a configuração do ambiente é um monte de instruções de instalação de diversas ferramentas. Aqui entra o Launcher na história, nosso instalador que deixa tudo prontinho e é compatível com Windows, Linux e Mac. Além de instalar o emulador Android e todas as ferramentas necessárias para executá-lo, ele também mantém um processo no computador do usuário. Esse processo é quem faz toda a comunicação da nossa interface web de desenvolvimento e gerenciamento com as ferramentas instaladas no computador do usuário. Também é o responsável por abrir o emulador, instalar e atualizar as versões do App para os desenvolvedores e automatizar/abstrair o que for possível para facilitar a vida do pessoal – #dx.

Uma vez que tudo esteja instalado e o dev esteja minimamente familiarizado com os nossos sistemas, oferecemos um material autoinstrucional em formato de vídeo aula, o “Kodiak 101: Do zero a produção”. Nesse treinamento, que consiste em cerca de 20 tópicos com aproximadamente 3,5h de vídeo, construímos um fluxo real de um produto, do início ao fim. O objetivo é habilitar nossos devs a fazerem suas entregas o quanto antes utilizando a Plataforma.

Launchpad, o poderoso chefão

Nos parágrafos anteriores, quando citei nossa “interface web de desenvolvimento e gerenciamento”, não chamei ela pelo nome. Muitos de vocês dever ter sacado que eu estava me referindo ao Launchpad (React) e seu backend, Launchpad API (JavaScript + NodeJS).

Esse é o cara que controla tudo. Ele prova a interface de desenvolvimento e parametrização dos fluxos, controle de versão, gestão de implantações e rollbacks, fluxos de aprovação, gestão dos aplicativos e ambientes de desenvolvimento, homologação e produção.

Desenvolvendo no Kodiak

Vamos olhar um pouco para o processo de desenvolvimento para ver se nos ajuda a entender a mecânica por baixo dos panos.

Para desenvolver algo no Kodiak o primeiro passo é ter o Serviço criado (que representa um fluxo de um produto). Na sequência é preciso selecionar uma versão de SDK (quanto mais novo mais funcionalidades e templates disponíveis).

Agora chegou a hora de adicionar o template de tela. Após selecionar o template o dev atribui um identificador para a tela e já pode seguir realizando a parametrização das APIs e componentes previstos no template. Tudo isso é feito em um formulário web e o resultado é a configuração da tela, salvo em um documento JSON na nossa base de dados.

Build e Deploy, implantando as alterações

Uma vez que todas as telas tenham sido configuradas (suas APIs, componentes e links de uma para a outra), é gerado um pacote (nosso build) contendo todas as configurações do fluxo. A esse pacote é atribuído um número de versão que será utilizado para identificar o pacote e para promovê-lo para os ambientes de homologação e produção.

No final das contas o fluxo de telas é um conjunto de documentos JSON (configurações) salvo em um banco de dados. Promover as alterações de um ambiente para o outro consistem em copiar esse conjunto de configurações de uma base de dados para outra.

E aqui tem um ponto importante que não falei ainda. O Engine não é um elemento único. Para cada aplicativo e ambiente de processamento (desenvolvimento, homologação e produção) existe uma instância do Engine rodando. Isso é muito importante para que não haja interferência de um ambiente no outro e para que o ambiente de runtime seja independente do ambiente de gerenciamento/ desenvolvimento.

De modo geral é assim que o Kodiak funciona.

Gerando valor para os clientes e para o negócio

Imagine identificar uma oportunidade de melhoria em um fluxo transacional e ter esse ajuste distribuído para 100% dos clientes em menos de duas horas? Estou falando do tempo entre a identificação da oportunidade de melhoria, a realização do ajuste e a implantação para todos os clientes nessa janela de tempo de duas horas.

Esse é um exemplo real que aconteceu recentemente no serviço de Recarga de Celular. Uma melhoria no fluxo de telas dobrou a taxa de conversão de um dos meios de pagamento instantaneamente.

Mais importante que entregar novidades é não quebrar o que está funcionando, principalmente se for o PIX. Por mais que tenhamos todo o cuidado e diversos processos implantados para minimizar o risco de bugs, uma hora vai acontecer. Com o Kodiak, além de fazer ajustes de forma muito rápida conseguimos desfazer as alterações de forma instantânea.

Esse é o tipo potencial que estamos destravando. Permitir que os times de produto entreguem soluções para os clientes de forma muito rápida. Avaliem os resultados e decidam como prosseguir.

Temos casos em que o fluxo completo foi entregue em menos de 10 dias. O que não seria viável em um processo tradicional de desenvolvimento mobile, contanto todas as etapas de qualidade que seguimos.

Além disso, por ser uma solução no-code/low-code, o Kodiak permite que desenvolvedores sem experiência em mobile realizem entregas no app, aumentando muito a autonomia dos times de produto.

É dessa forma com que estamos transformando o aplicativo do BB.