Para começar, gostaria de falar sobre a sigla IDP .
Há alguns anos, quando comecei a trabalhar em tempo integral na “área de infraestrutura”, falávamos da Plataforma de Desenvolvimento Interno e isso se refere à infraestrutura e ao conjunto de ferramentas que automatizam e facilitam o desenvolvimento, implantação e operação de os serviços e recursos subjacentes, tem como foco a automatização e integração de todas as camadas que uma equipe de desenvolvimento de produto precisa, incluindo componentes CI/CD, IaC, orquestração de contêineres, observabilidade, etc.
Com o passar dos anos começamos a falar em Internal Developer Portal , que é uma evolução de uma Plataforma Interna de Desenvolvedores.
De acordo com o Gartner, “Até 2026, 80% das grandes organizações de engenharia de software estabelecerão equipes de engenharia de plataforma como fornecedores internos de serviços, componentes e ferramentas reutilizáveis para entrega de aplicativos. “A engenharia de plataforma acabará por resolver o problema central da cooperação entre desenvolvedores e operadores de software.”
Com o Internal Developer P ortal começamos a ter uma abordagem de produto no que diz respeito à plataforma, pode ou não incluir uma UI e facilita tarefas de autoatendimento com fluxos de operação desenhados como um produto e baseados nas necessidades internas de desenvolvimento e segurança que a empresa precisa.
Para não te aborrecer, gostaria que mantivesse os seguintes conceitos:
Self-service
Padronização
Segurança
Reduza a carga cognitiva
Plataforma como produto
Porque um deslocado interno
Terminada a breve introdução, vamos falar sobre o porquê.
Akua e como é de conhecimento público é “A plataforma de processamento de adquirência para todos os meios de pagamento na América Latina” e desenvolver serviços neste contexto requer cuidados especiais em segurança sem perder velocidade no desenvolvimento e implantação e ter autonomia para a operação/gerenciamento de serviços e recursos associados .
Neste contexto formamos a equipa de Plataforma em Akua para desenvolver o IDP, com um desafio agressivo mas motivador pela frente, desenvolvendo o IDP desde o início para que a equipa de desenvolvimento de produto possa implantar e gerir microsserviços e os recursos associados, tudo sem perder de vista dos conceitos que mencionei anteriormente, Autoatendimento, Padronização, Segurança, Redução de carga cognitiva, Plataforma como produto .
Foi um capricho? Não, conheço Juanjo há muito tempo e sabemos por experiência compartilhada que ter um PDI em uma empresa que precisa ser compatível com PCI, seguindo os mais altos níveis de segurança com alta disponibilidade e escalabilidade é um benefício muito valioso.
Na Akua poderíamos muito bem ter criado tudo manualmente, sem seguir padrões, mas é pão para hoje e fome para amanhã, vamos pensar que por algum motivo a indústria criou o conceito de IaC, não apenas por capricho, é um necessidade que surgiu quase naturalmente pelas implicações e desafios na gestão de infra-estruturas.
Quando um deslocado interno
Eu antecipei algo, mas fizemos isso desde o minuto zero e foi desafiador, muito desafiador pensar nisso:
Quais ferramentas IaC usaremos?
O que vamos usar para CI/CD?
Como podemos garantir que o nosso PDI não se torne um monstro e seja simples e fácil de gerir e escalar?
Onde serão executados os serviços da Akua?
Como estamos seguros por padrão?
E pode surgir uma pergunta pairando no ar: por que desde tão cedo?
Akua precisa ter uma velocidade de desenvolvimento padronizada e segura e mantê-la ao longo do tempo, e que sem um PDI é muito complicado de conseguir ou não é possível, você poderia “sair rápido” sem ter um PDI, mas garanto que mais cedo depois tudo vira um caos, para o produto e para o gerenciamento e manutenção da infraestrutura e software.
Como
Vamos abordar o último ponto, o como.
Não existem receitas, desculpe, mas se você veio procurar uma, esta publicação não é para você 😂
O que vou contar é o que nosso PDI oferece até o momento.
Mas antes de falar sobre o que ele oferece, vou contar o que usamos para oferecer o que oferecemos:
Como ferramenta IaC usamos Pulumi com Typescript.
Para CI/CD usamos Gitlab com executores privados para interagir com nosso provedor de nuvem.
Falando em provedor de nuvem, usamos AWS (Amazon Web Services)
Para configurar aplicações usamos Helm e desenvolvemos um gráfico que todos os microsserviços utilizam.
Onde nossos aplicativos são executados? em Kubernetes
Para observabilidade, usamos NewRelic
Ok luispi, e depois?
Anteriormente falei sobre carga cognitiva e o desejo de que nosso PDI permaneça simples e sustentável ao longo do tempo.
Pois bem, para atingir esse objetivo, desenvolvemos uma biblioteca interna (como mencionei com Pulumi e Typescript) que contém a lógica de negócio e segurança para adicionar, excluir e modificar os recursos da plataforma.
Para evitar que nossa equipe de desenvolvedores de produtos tenha que aprender uma ferramenta IaC, além da equipe da Plataforma querer ter a liberdade de mudar de rumo se precisarmos, o gerenciamento é feito a partir do Porto (https://www.getport .io/), onde cada equipe responsável pela aplicação pode criar, atualizar e excluir recursos com um formulário simples, não acredita? Deixo-te um gif
Quando a aplicação é sincronizada, nos bastidores executamos um executor Gitlab privado na AWS e contando com nossa ferramenta IaC (Pulumi) validamos o estado do que queremos implantar com o que existe na nuvem.
Abaixo deste “fluxo simples” estão muitas horas de design e desenvolvimento que tivemos e temos com a equipe da Plataforma, na data de redação deste post do nosso IDP isso pode ser gerenciado:
Como mencionei microsserviços no Kubernetes e isso inclui: implantação, conta de serviço, serviço, entrada, conjunto com estado, cron job, HPA, light cache (?)
SQS
redes sociais
S3
DynamoDB
Aurora RDS
Função IAM, grupo de segurança, segredo e ECR para o aplicativo/microsserviço
Vários ambientes
Inquilino único e multilocatário
Todos estes recursos tendo em conta a otimização de custos e a segurança.
Antes de continuar quero falar sobre os dois últimos itens da lista, Múltiplos ambientes, Único e multi locatário .
Vários ambientes
Quando falamos em múltiplos ambientes queremos dizer que uma aplicação pode rodar em diferentes ambientes no ciclo de vida até chegar à produção.
A abordagem e solução que demos do nosso PDI em Akua é abstrair a criação de recursos ambiente por ambiente, fomos para um conceito mais abstrato onde criamos ou modelamos quais recursos o serviço precisará para resolver um problema de negócio e então poder selecionar Em qual ambiente deseja sincronizar os recursos previamente definidos, podendo escolher entre um ambiente de teste e produtivo.
Abaixo está um pequeno gif:
Locatário único e multilocatário
A nossa Plataforma e o nosso portal são desenhados e desenvolvidos para suportar single/multi locatário, e não apenas ao nível do software do produto, mas também em toda a pilha tecnológica que a nossa plataforma possui, e com isto quero dizer:
Cargas de trabalho de aplicativos
Recursos do nosso provedor de nuvem
Observabilidade (rastreamento, registros, métricas)
etc.
E essa funcionalidade foi desenvolvida respeitando um dos mantras que deve ser seguido na hora de criar uma DPI Reduzir a carga cognitiva , por quê? Nossa equipe de tecnologia de produto pode configurar se o aplicativo será executado em locatários 1..n e ao implantá-lo pode selecionar o ambiente e o locatário, o resto cabe ao nosso IDP entender como, quando e onde configurar todos os recursos subjacentes 😎 .
Conclusões
Ao longo da publicação tentamos abordar de forma mais ou menos abstrata tudo o que envolve um PDI, desde o que significam as siglas até como uma equipe da Plataforma e um PDI podem impactar o negócio da sua empresa, no nosso caso em Akua 🫶 🏼.
Algumas coisas que gostaria de resumir o que um PDI pode lhe oferecer são:
💸 Redução de custos: Ao otimizar a infraestrutura e automatizar processos, as organizações podem obter economias significativas em custos operacionais e de manutenção.
⚙️ Maior agilidade e rapidez na entrega: A implementação de uma plataforma robusta e flexível permite acelerar o time to market de novas aplicações e funcionalidades, proporcionando uma vantagem competitiva num mercado em constante evolução.
📈 Melhor escalabilidade e disponibilidade: A arquitetura baseada em microsserviços e orquestração de containers permite escalar os recursos da plataforma de forma eficiente, garantindo alta disponibilidade e desempenho.
🛡 Melhor segurança e conformidade regulatória: A aplicação de práticas de segurança e o uso de ferramentas avançadas permitem proteger dados confidenciais e cumprir os padrões de segurança e privacidade.
As decisões são unilaterais? Claro que não, para construir um PDI se as necessidades dos “clientes” não forem ouvidas, tudo pode ser feito morro acima.
Há um longo caminho a percorrer, mas temos muito orgulho do que construímos, estamos construindo e vamos construir no PDI.
Até a próxima 👋🏼
Comments