Por que o PicPay criou sua IDP, o Moonlight?

Tem se tornado cada vez mais comum ouvirmos falar em plataformização, na revolução estratégica que as plataformas são capazes de trazer a uma empresa e aos clientes dela.

Mas e quando tratamos de clientes internos? Isso também é válido?

Vou contar um pouquinho do que acontece no PicPay, e o que nos levou a construir a nossa plataforma interna para pessoas desenvolvedoras, o Moonlight.

O PicPay vem nos últimos anos em um crescimento exponencial, passamos de 5 para mais de 60 milhões de usuários nos últimos 5 anos. As equipes têm liberdade para escolher as ferramentas, linguagem e recursos de desenvolvimento, mas quando começamos a escalar, começam os problemas.

Passamos de um time de 200 para mais de 1000 pessoas na área de engenharia, e começou a ficar cada vez mais complicado o gerenciamento dessas pessoas, permissões e padronização desses modelos de desenvolvimento.

Crescemos para cerca de 2400 repositórios, sem padronização e sem visibilidade de ownership.

O volume semanal de pull requests é de mais ou menos 2300, muita informação para gerenciar e um alto custo de CI/CD. Com isso também houve um aumento em larga escala de deploys, cerca de 1000 por semana.

Diante desse cenário e desse crescimento de números acelerados, surgiram algumas dores para área de engenharia, para as pessoas desenvolvedoras e para o PicPay como um todo:

• Não sabíamos quem eram os responsáveis pelos componentes: foi criado um catálogo em uma planilha Excel com Owners e BUs que evoluiu para o Grafana, mas era difícil mantermos a atualização, pois tudo ocorreria de forma muito dinâmica.
• Não existia um padrão para criação de um novo componente: eram realizados Forks de serviços para criação de novos serviços, o que exigia um grande esforço para refazer toda configuração desse novo serviço “copiado”.
• Não havia padronização de Deployment: diversos CI/CDs diferentes em áreas diferentes.
• A criação de Componentes de infraestrutura entra centralizada em alguns times: bastante burocracia e times inteiros trabalhando em operação para atender o volume de solicitações.
• Descentralização de solicitações de acessos: muitas solicitações de acessos para ferramentas e times diferentes.
• Arquivamento de repositórios: não havia uma política de arquivamento, nem todos os times trabalhavam da mesma forma, gerando muito "lixo".
• Dificuldade em manter a régua de qualidade: muitos serviços sem análise estática de código e sem indicadores de qualidade.

Diante desse cenário, percebemos que para obter informações sobre serviços, ter um blueprint de como as aplicações devem nascer, se tornou uma necessidade cada vez maior.

Foi então que nasceu um novo time, com a missão de prover uma experiência padronizada e automatizada aos times de desenvolvimento e gerar visibilidade dos processos internos de tecnologia do PicPay.

Com essa missão e um time multidisciplinar, começamos a pensar em como atingir o nosso objetivo, estudando diversas tecnologias e o que havia disponível no mercado. Foi quando tivemos o primeiro contato na literatura com a IDP, e tudo começou a fazer sentido…

Mas o que é uma IDP?

IDP — Internal Developer Plattform, é uma plataforma interna para pessoa desenvolvedora. Em times de desenvolvimento expressivos, é muito comum a falta de padronização de processos, de serviços, a falta de visibilidade de ownership, dificuldade de rastreamento e organização de ferramentas, de acessos e de documentação. Nesse contexto, a IDP vem para auxiliar as equipes de operações a estruturar sua configuração e permitir o autoatendimento da pessoa desenvolvedora, unificando todas as ferramentas, serviços e documentação de sua infraestrutura para criar um ambiente de desenvolvimento simplificado de ponta a ponta.

Percebemos que sim, precisávamos de uma IDP para organizar a casa, mas e agora? Partimos para o desenvolvimento interno? Temos conhecimento pra isso? Sim, temos!

Temos tempo? Não, não temos!

O que temos no mercado? Temos pouco. Algumas opções Open Source.

Quais as vantagens e desvantagens dessas opções?

Depois de bastante pesquisa e benchmarks optamos por usar o Backstage.

Backstage é um projeto de IDP criado internamente no Spotify e disponibilizado à comunidade com código aberto (open source).

Há alguns meses o projeto foi doado à CNCF (Cloud Native Computing Foundation).

Foi nossa escolha porque tem alta adesão da comunidade, empresas como Netflix, Zalando, Epic Games além do próprio Spotify utilizam.

Alguns pontos foram decisivos para decidirmos por essa solução:

• Alta adoção pela comunidade: > 103 public adopters (and growing)
• Roadmap longo;
• Atualizações constantes;
• Community Sessions a cada duas semanas.

Para o nosso cenário, naquele momento, foi a melhor opção! Ele não é nossa solução para tudo, mas atende ao propósito e as dores que focamos em resolver primeiro.

Dentro desse contexto então nasceu o Moonlight, a ferramenta IDP do PicPay, nossa implementação do Backstage, com o objetivo de resolver nossos problemas, trazendo a melhor experiência para os usuários.

Moonlight, do PicPay para o PicPay

A ideia do Moonlight está correlacionada ao termo “Moonshot”, um conceito que diz respeito a um pensamento voltado à inovação e a buscar soluções disruptivas dentro de uma realidade.

Como o nosso intuito, de promover melhoria contínuas, proporcionando uma experiência otimizada para a pessoa desenvolvedora.

Focamos na primeira versão do moonlight as principais dores que mapeamos e que poderiam ser solucionadas de forma mais imediata:

Catálogo de componentes

Catalogamos Microserviços, Scripts, SDKs, IaC, GitOps, trazendo no catálogo as informações gerais de cada componentes, informações de qualidade, métricas de accelerate, informações de observabilidade, de kubernetes, dependências, documentação e APIs.

A ideia é que o nosso catálogo seja o principal local de busca de qualquer componente desenvolvido pelo PicPay, que tenha a descrição da finalidade de cada componente, indique o time dono de cada componente, tenha documentação técnica de cada componente, informe quais recursos de infraestrutura são utilizados por cada componente e mostre as dependências entre componentes em forma de diagrama.

Templates

A ferramenta é focada em self-service, então as próprias skills e áreas podem criar seus próprios templates de MS ou de infraestrutura. O modelo de templates garante a criação automatizada da estrutura mínima básica para o funcionamento do componente: Criação do Repo no Github (com definição de permissões, branch principal e proteção de branch), Criação do repo da imagem no ECR, Criação de variáveis de ambiente do New Relic, Criação template de arquivos de documentação, Criação dos arquivos de docker file e docker compose, Adição do componente no catálogo de componentes.

Métricas

Montamos um ecossistema de métricas que permitem o acompanhamento da saúde do componente, com métricas de accelerate (CFR, deploy frequency, lead time), métricas e deploy e de APM, tanto por componente quanto por time, para que os gestores também tenham visibilidade do desempenho dos times. Além disso, acompanhamos o build das aplicações iOS através do XCMetrics e utilizamos o Google Analytics para análise de comportamento e adesão da ferramenta.

Ferramentas integradas

Nos preocupamos em integrar à aplicação as ferramentas mais utilizadas pelos nossos times de desenvolvimento e infraestrutura, New Relic, Sonar, Kubernates, Tekton, Harness, Pipelines de Terraform e Opsdash (controle de envs), para dar mais visibilidade ao processo de desenvolvimento como um todo. Trabalhamos também com pipelines de techdocs, para que todos os componentes tenham um padrão mínimo de documentação desde a sua criação.

Nossa IDP entrou em produção em 22/10/2021.

Em 8 meses temos em torno 1600 componentes catalogados, 355 componentes catalogados com métricas de accelerate, mais de 20 templates, 16613 deploys de componentes catalogados, 4900 sessões na aplicação, uma média de 260 usuários por semana e uma média de 18 componentes criados por semana através da plataforma.

Esses números são bem expressivos, e surge a questão: Como conseguimos escalar? É aí que entra o segredo do PicPay, o Build Checker.

Sobre como escalamos

O build checker é uma aplicação criada por nós que ajuda a padronizar regras de segurança e configurações, utilizando análise estática de repositório (pré-build), análise de pós build e regras customizáveis que precisam ser implementadas até uma data limite estabelecida, de acordo com a necessidade do PicPay.

Durante nosso processo de Pré-build, o Build Checker realiza todas as análises estáticas do repositório, validando formatos de schemas, campos ou textos dentro de arquivos que garantem os metadados que compõe o nosso IDP. Caso seja identificado algum problema nessa análise, o build é interrompido e os problemas encontrados são alertados.

Depois disso, a pipeline faz o build da imagem docker e o caminho da imagem é passado como argumento para o build checker com a flag de pós-build.

As validações de pós-build são comandos executados no bash da imagem, que geram outputs que são capturados e validados com o que foi configurado na regra.

Por exemplo: crio uma regra para verificar se a versão da linguagem de programação utilizada é 7.14.1, então o pós-build do build checker vai procurar essa informação nos outputs gerados e validar se estão na versão 7.14.1 da linguagem. Se não estiverem, o deploy é interrompido. Se estiverem dentro das regras, é feito o merge com a main para liberar o deploy.

Desta forma a pessoa desenvolvedora precisa adequar o código às regras definidas para criação de padrões, o que permite que escalemos de forma organizada e rápida.

A ideia é simplificar

Assim funciona o Moonlight, a IDP do PicPay.

A ideia é simplificar ao máximo a experiência das pessoas desenvolvedoras:

• Repositórios estruturados e padronizados;
• Criar um MS é tão simples quanto preencher um formulário;
• Informações de componentes padronizadas e completas;
• Métricas que contribuem para a evolução de produtos e times.

Não paramos por aqui, estamos trabalhando ativamente na evolução da plataforma para que num futuro próximo possamos criar dashboards personalizáveis com monitoria de infraestrutura, dar maior visibilidade de métricas para gestão, criar novos templates para criação de IaC, melhorar o gerenciamento de arquivamento e atualização dos repositórios, dar maior visibilidade das etapas de execução de CI/CD e escalar o mapeamento de dependências entre componentes.

É um trabalho evolutivo, e aos pouquinhos vamos transformando a vida das pessoas desenvolvedoras.