Nossa plataforma gerencia onde e como os serviços são implantados através de repositórios GitOps. Mas e a aplicação em si — o código, o build, o contêiner? Até agora, cada equipe configurava seu próprio Dockerfile, escrevia seu próprio pipeline de CI e elaborava sua própria estratégia de tagueamento de imagens. O resultado era previsível: 10 times, 10 workflows de CI diferentes, 10 abordagens diferentes de build de contêiner e zero consistência.

A convenção de Repositórios de Aplicação muda isso. Quando um novo serviço é scaffoldado via Backstage, ele entrega um repositório completo e opinativo com código fonte, Dockerfile, pipeline de CI e uma pasta .k8s — dando à equipe da aplicação autonomia sobre a configuração de sua carga de trabalho enquanto mantém a plataforma no controle do modelo de implantação.

Documentação é ignorada. Runbooks ficam desatualizados. Páginas de wiki acumulam instruções conflitantes de três autores diferentes. Quando o "jeito certo" de criar um serviço existe apenas em documentação, cada novo serviço é uma chance de desviar da convenção.

Os templates do Backstage Scaffolder mudam essa equação. Em vez de documentar o caminho correto e torcer para que os engenheiros sigam, codificamos o caminho correto em um formulário que produz saída correta todas as vezes. Este post é sobre como nossa cadeia de templates funciona, por que a ordem de dependência importa, e o que acontece quando você clica em Create.

Nomear coisas é famosamente o problema mais difícil da ciência da computação. É também, silenciosamente, um dos mais caros. Quando quatro equipes diferentes nomeiam seus namespaces de quatro formas diferentes, o custo aparece em incidentes que demoram mais para diagnosticar, em onboardings que viram sessões de conhecimento tribal, e em um time de plataforma que gasta suas semanas traduzindo entre sistemas ao invés de construir.

Este post é sobre como uma única convenção de nomenclatura — três segmentos, uma chave — unificou Kubernetes, ArgoCD, Backstage e Crossplane. E por que o retorno sobre investimento foi medido em dias economizados por semana.

Todo time de plataforma chega ao mesmo ponto de inflexão. A fila de tickets cresce mais rápido do que o time. Engenheiros esperam dias por um namespace, um banco de dados ou uma aplicação ArgoCD — coisas que deveriam levar minutos. A equipe de plataforma se torna o gargalo de cada time que tenta entregar.

Chegamos nesse limite. Este post é sobre como saímos dele.