Você está fazendo engenharia de plataforma de maneira errada. Provavelmente.

Então você está convencido e seu chefe também concorda. Vocês dois leram os relatórios mais recentes de DevOps e State of Platform Engineering; você visitou a KubeCon e falou sobre isso com metade dos fornecedores de lá. Você até participou de uma mesa redonda executiva sobre o assunto com outros profissionais do seu setor. A decisão é finalmente oficial: você está iniciando sua jornada de engenharia de plataforma. Parabéns! A terra prometida de métricas DORA aprimoradas, autoatendimento para desenvolvedores e tempo de lançamento no mercado mais rápido está chegando. Certo?

Pode ser, mas você precisará evitar alguns erros cruciais e antipadrões nos quais muitas equipes de plataforma caíram. A primeira e mais comum: começar construindo primeiro o frontend de sua plataforma de desenvolvedor interna (IDP), em vez de focar no backend. Muitas equipes simplesmente pegam seu pipeline de CI/CD atual e colocam um portal de desenvolvedor em cima dele. Bam, pronto! A engenharia da sua plataforma teve um começo fantástico. Certo?

Não tão rápido. Há uma série de problemas com essa abordagem que prioriza o portal e Aaron Erickson, que construiu o PDI na Salesforce, destaca o mais óbvio: “Construir um PDI é como construir uma casa. Você nunca começaria pela porta da frente ou pelas janelas, mas sim pela fundação. Depois você adiciona as paredes e só no final a porta e as janelas. Construir um PDI começando com um portal é como construir uma casa começando com a porta da frente e as janelas.”

O outro grande desafio ao qual essa abordagem leva é que, à medida que sua iniciativa de engenharia de plataforma amadurece e cresce em escopo, você precisará cada vez mais de lógica para ser incorporada ao seu IDP. Se você não fez as coisas corretamente desde o início, como começar pelo back-end da sua plataforma, você se verá tentando inserir a lógica no seu front-end. Se há algo que aprendemos com a construção de arquiteturas de microsserviços nos últimos mais de 10 anos, é que construir lógica de negócios em seu frontend é um grande problema e viola o princípio de responsabilidade única, onde um módulo “deve ser responsável por um , e apenas um, ator. Isso expõe sua lógica de negócios, criando vulnerabilidades de aplicativos e tornando seu front-end pesado e lento.

É por isso que toda plataforma de desenvolvedor interna precisa de um back-end adequado e por que, como equipe de plataforma, você quer ter certeza de começar projetando e construindo isso antes de se preocupar com qualquer outra coisa.

Então, como você projeta um back-end? Você essencialmente tem duas opções.

Opção 1: back-end baseado em pipeline (CI/CD+IaC)

Isso é o que muitas equipes que começam com engenharia de plataforma costumam adotar. Geralmente é um legado de antigas equipes de DevOps e infraestrutura, combinando pipelines de CI/CD com configurações de infraestrutura como código (IaC).

Em sua forma básica, o usuário (o desenvolvedor da aplicação) trabalha ambiente por ambiente, definindo configurações de aplicação e infraestrutura com arquivos de configuração individuais para cada ambiente. Os pipelines de CI/CD executam as alterações nesses arquivos a cada git-push. Em configurações mais avançadas, os desenvolvedores podem descrever as alterações de uma forma mais abstrata e essas solicitações são então transformadas por meio de pipelines aninhados em execuções de pipeline individuais.

Prós e contras

A vantagem aqui é muito clara: a maioria das equipes ainda está acostumada com esse tipo de conjunto de ferramentas e processos. Isso também significa que o conjunto de talentos do setor para construir e manter sistemas baseados em pipeline é relativamente grande.

A desvantagem é que os pipelines são um sistema start-stop que não foi projetado para ter lógica avançada incorporada. Portanto, um argumento semelhante se aplica à abordagem frontend-first que discutimos anteriormente. Embora lógicas simples, como progressão ambiental e aprovações, sejam adequadas para sistemas de pipeline, qualquer coisa que vá além disso — por exemplo, desenvolvedores interagindo com sua infraestrutura — não será bem dimensionada.

Digamos, por exemplo, que um desenvolvedor solicite um bucket AWS S3 para sua carga de trabalho. Naturalmente, você desejaria que seu IDP criasse buckets configurados individualmente para cada ambiente, executasse verificações de políticas e injetasse segredos em tempo de execução no contêiner antes da implantação. Para fazer isso, um back-end baseado em pipeline se tornará exponencialmente mais complexo e rapidamente se tornará difícil de manter.

O resultado é que os back-ends do pipeline geralmente são mantidos em um mínimo de lógica de negócios, pois qualquer coisa mais avançada se tornaria muito extensa e complicada. Isso leva a configurações de plataforma inadequadas que não gerenciam todo o ciclo de vida de um aplicativo e não promovem a padronização em toda a sua organização. Eles também são difíceis de auditar e consumir (sem API primeiro, sem múltiplas interfaces, etc.)

Opção 2: back-end baseado em gráfico (orquestradores de plataforma)

Um orquestrador de plataforma é um backend de plataforma que fica no sistema pós-CI. Ele lê uma solicitação declarativa e abstrata (por exemplo, um desenvolvedor deseja que um banco de dados Postgres para sua carga de trabalho seja implantado no teste). Ele interpreta o contexto da solicitação (ambiente = teste neste caso) e combina-o com as regras definidas pela equipe da plataforma. Em seguida, ele gera um gráfico de recursos executável que pode ser implantado diretamente pelo orquestrador ou por uma solução de CD existente (sincronizada com o cluster pelo ArgoCD).

As abordagens baseadas em gráficos são muito versáteis e permitem lógica avançada. Se o desenvolvedor solicitar uma nova dependência (como adicionar um cache Redis à carga de trabalho), o gráfico será estendido automaticamente. Se a equipe da plataforma atualizar o Redis de Vx para Vx+1, o gráfico será reconstruído automaticamente e a versão mais recente será usada na próxima implantação.

Esta abordagem arquitetónica permite que as equipas de plataforma utilizem a mesma definição de um tipo de recurso para cada ambiente. Seguindo o exemplo, todos os recursos do tipo “Postgres” no contexto “staging” são configurados exatamente da mesma forma, são gerenciados pelo ciclo de vida e quaisquer desvios de configuração são automaticamente revertidos para o padrão. Os orquestradores de plataforma também devem ter funcionalidade de pipeline de implantação para gerenciar a progressão do ambiente e outras automações.

Prós e contras

Back-ends baseados em gráficos atendem a todos os requisitos de um bom projeto arquitetônico. Eles convertem solicitações abstratas do desenvolvedor em arquivos de configuração executáveis ​​que seguem caminhos e regras claras. Isso impulsiona automaticamente a padronização desde o projeto, em todos os fluxos de trabalho e equipes. Eles priorizam a API e possuem múltiplas interfaces (CLI, UI, baseadas em código, como Score). Eles vêm com controle de acesso baseado em função e logon único, e permitem assinaturas automáticas, injeções secretas, verificações de políticas, etc., tornando um IDP verdadeiramente pronto para a empresa.

Por outro lado, são novos e exigem uma mudança de mentalidade, especialmente por parte das equipes de infraestrutura existentes que estão acostumadas a pensar em pipelines. Além disso, back-ends baseados em gráficos só fazem sentido em escala. Se você tiver uma equipe menor (menos de 50 desenvolvedores), talvez seja melhor usar uma abordagem mais simples de pipeline para seu back-end.

Conclusão

O Gartner espera que 80% de todas as empresas tenham uma iniciativa de engenharia de plataforma até 2026. É ótimo ver tantas equipes entendendo o potencial das plataformas internas de desenvolvedores. Mas você precisa fazer isso direito, ou a iniciativa de sua plataforma pode acabar criando mais problemas do que soluções.

Se você tiver dúvidas ou quiser saber mais sobre nosso programa Plataforma Mínima Viável, entre em contato com nossos arquitetos de plataforma.

A postagem Você está fazendo engenharia de plataforma errada. Provavelmente. apareceu primeiro em The New Stack.